The web came back to the server

In 2012 the web work I noticed still started with a page. The server built the HTML, the browser showed it, and jQuery handled whatever had to move. If you wanted something fancier you reached for Backbone, wrote a lot of glue code by hand, and hoped nobody asked you to change the data model later.

AngularJS was the first thing that felt different to me. Two-way binding, a bit of magic in the HTML, and suddenly a form updated itself. It got slow once the page grew, and the digest cycle was a mystery to me for longer than I’d like to admit, but it worked, and it got a lot of people thinking in components before that word was everywhere.

Then React showed up in 2013 and I remember plenty of complaints about it. HTML inside JavaScript, and a virtual DOM that sounded like a gimmick. The idea grew on me. Once you’d written a component that just re-rendered when its data changed, going back to updating the DOM by hand felt like a chore.

The tooling years

2015 is the year the language itself caught up. ES2015 gave us let, arrow functions, classes, modules, promises and template strings, all the stuff that makes JavaScript feel like a normal language today. Browsers didn’t support most of it yet, so everybody ran Babel, and because you were already compiling you might as well bundle too. That’s how webpack ended up in so many projects. A config file I struggled to understand and a dist folder full of hashes.

I’m not going to pretend it was fun. This was the “JavaScript fatigue” period, a new framework every week and a starter kit for each one. Angular 2 came out in 2016 as a total rewrite, which upset anyone sitting on a big AngularJS app. Vue had been around since 2014 and was turning into the friendly option: drop it into a page with a script tag and it just worked. Next.js also started in 2016, and at first it was mostly “React with server rendering and file based routing”, which turned out to be exactly what people wanted.

TypeScript was there the whole time (it’s from 2012), but for years it was the thing Angular people used. Somewhere around 2018 or 2019 it stopped being a debate. I started expecting a tsconfig in new projects.

Components and build tools

Hooks landed in React in early 2019, and function components became much easier to use for stateful UI. Around the same time Svelte 3 came out with the opposite idea: instead of shipping a framework runtime to do the diffing, compile the component down to plain DOM updates. I still think that’s the cleverer idea, even if React won on numbers.

Tailwind is the one I resisted the longest. It took off around 2020, and class soup in the markup looked wrong to me. It still looks a bit wrong, and I use it anyway, because not having to name things is worth more than I expected. (This site is plain CSS, by the way, on purpose. The Windows look needed real bevels.)

Vite, also 2020, fixed the thing everyone had been putting up with. The dev server started almost instantly, because it served native ES modules to the browser instead of bundling everything on each save. Once you’d felt that, going back to watching a bundler think for half a minute was not an option.

Back to the server

Here’s the part that still makes me smile. Around the end of 2020 the React team started showing off Server Components, and by 2023 the Next.js App Router shipped them as the default. The pitch was to keep more component code on the server and send less JavaScript to the browser. Which is, roughly, what we were doing in 2012 with a template and a bit of jQuery. The difference is the mental model stays the same on both sides now, and the interactive bits are still real components rather than a script bolted on. This site runs on the App Router too, although a fake desktop with draggable windows is not a great example of shipping less JavaScript.

The islands crowd (Astro is the obvious example) got to a similar place from the other direction. Render everything static and hydrate only the small pieces that need to react. Partial hydration was a niche idea around 2019 and by 2022 it was just how those tools worked.

I like that the server is useful again without giving up components. We needed the single page app years to work out what a component even was, and the tooling that came out of them is what makes the current setup possible.

2025 and the agents

The biggest change of the last two years is that I mostly don’t type the markup any more. I describe a screen, an agent writes the component, I look at it in the browser and say what’s wrong. The frameworks still matter (I find agents more useful with familiar frameworks), but the day to day feeling of frontend work has changed more since 2024 than in the ten years before it.

I spend more time looking at the result in a browser now. The first version comes quickly; deciding whether it works still takes care.