Try tailwind. Very amenable to LLM generation since it's effectively a micro language, and being colocated with the document elements, it doesn't need a big context to zip together.
> On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility. You only have those things if you choose to use them. I've been building websites for 25 years. I use the same core technologies today that I did when I started. Sure, I make use of modern improvements to the languages themselves, but I have never permanently adopted any of the "hot new trends" and feel I am better - or at least saner - for it. No, your marketing or e-commerce website almost certainly doesn't need a JS bundling toolchain. It almost certainly doesn't need a CSS preprocessor or even a CSS boilerplate/framework. It almost certainly doesn't need an enterprise-class PHP framework; or a dependency manager; or a CI/CD pipeline.
> build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images Build pipelines are purely a technical decision. Bundlers are purely a technical decision (TBH, a non-brainer if you decide to have a build pipeline, but it's not an organizational helper). Those help one do some things, not several people to organize. I'm still waiting for any person to claim they made CSS maintainable by adopting a framework. It's an almost purely organizational decision with no upsides at all. PWAs are a product decision, not technical or organizational. The same applies to Core Web Vitals, SEO, layout shifts and srcset, those are all product decisions. You can escape the technical and organizational decisions. You can't escape the product ones.
I used to think the same about server-side rendering until I more closely looked at React SSR. I think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background.
If you static render, it won't be an interactive application. With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with. It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.
> It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data. Then your JS bundle is broken. Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS. If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault. You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.
Static rendering has nothing to do with interactivity in a web app. I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable.
> On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… LLMs are successful in webdev because of unnecessary frameworks being piled on top of each other more in the name of job security than technical necessity.
Those things exist because of eachother. If you’re not using a reactive framework, you probably have no need for a bundler and if you’re not using a bundler, you probably have no need for a build pipeline.
Yes! I've been having a great time prompting "vanilla JavaScript, no react" and building neat things that use browser APIs exclusively (including modern stuff like web audio APIs and Web Components and WASM) because I don't need to learn a bunch of boilerplate stuff first anymore. Feels like coding in the 200xs and I'm enjoying every minute of it.
Tailwind CSS has also been super useful. A vocabulary for style colocated with the elements works far better than an ever growing list of continuously overidden rules.
Going in 2026, the frontend has many good options, but AI is not one of them. We have many typesafe (no, not TypeScript!) options with rock solid dev tooling, and fast compilers. AI is just a badaid, its not the road you want to travel.
Before I clicked on this I was optimistic and thought this was going to be about how we've turned a corner and the web stack pendulum is now swinging back to the easier days before frontend frameworks.
Strong agree. The modern web world is clearly better but we traded a whole lot of complexity for a little bit of benefit (and frequently regressed on speed). The microservices and javascript framework wars were the dark ages.
Really like using alpine with a classical JS server rendered stack too. Most crud apps don’t need a spa app and now you are working out of one code base again. Codex chews through this kind of code
yeah, I think that too - for me the -Ofun comes from HTMX https://htmx.org and the HARC stack https://harcstack.org so I can server side code in a my preferred programming language hint: not JS (with a helping of LLM on the side)
With server-side rendering you don't need a frontend framework at all, is my point. You also don't need a css tool chain at all, irrespective of whether or not you render on the frontend
please, developers are making terrible slop way before AI, look at the javascript infested frameworks in use on the web. they make NO sense. they are not making things simpler