What Happened To My Frontend?

Let me take out my flat cap and grab my cane, because I’m about to ramble like the sad, old man I’ve become.

After having a kid I relate to this GIF on a much too personal level.

My grandfather worked with computers, so I was lucky enough to always have a PC when I was growing up throughout the 1990’s. I was obsessed with “surfing” the web (though on a 33.6k modem it was more like a sad, slow paddle in the shallow end of a public pool). I was fascinated by the idea of being able to share something with the world, so my grandfather showed me some basic HTML and I got to building my very first website (circa 1996): a single page where I stuffed every Dragon Ball Z GIF that I had obsessively collected from across the net. GIFs from the games, GIFs from the show, GIFs from the (then) unreleased Dragon Ball GT (which wouldn’t make its way to North America until 2003). My website took minutes to load fully, and I’m fairly certain the target audience was exclusively me.

If you tried to tell a frontend engineer nowadays that back in the 90’s & 00’s a bunch of us were using SSH clients to move our HTML, CSS, and JS files directly to our production server, you would watch as their soul physically sprang from their body in a swift, violent reaction. CI/CD & sophisticated build tooling wouldn't become popular until the 2010s, and only larger companies were generally using some form of source control (you would, of course, keep a “master” copy on your local machine for redundancy). You didn’t have eighteen different config files to control how pretty your code was, or force you to order your dependency imports to some arbitrary standard. It was just you, your server, some HTML templates, and a handful of CSS & JS for a sprinkle of style and interactivity.

Finally, I can start working on my project.

But the needs of the web changed; people wanted more than pages with text and images and links between them. We created layers of abstraction over low-level DOM APIs to make it easier to build complex applications. Flash showed us the power of multimedia on the web (while simultaneously encouraging design abuse and breaking the fundamental principles of web interaction). We told people to build monolithic applications, and then we said monoliths don't scale and we should use microservices instead (ignoring the fact that 99% of those apps had no actual need to scale). We went from rendering everything on the server to rendering everything on the client — this was supposed to create snappy, fluid web applications, but it turns out making requests to ten different APIs over a slow network connection created an objectively worse UX. Then we had isopmorphic rendering (for rendering both on the server and client), and now we have JavaScript frameworks that say "hey, let us worry about the rendering, and you just worry about centering this div".

I worked at a couple of startups that definitely read this book.

So how did we get here? Is it a case of over-engineering our solutions? Sure, using a fully-featured framework to render some static pages is kind of like driving your car into a wall to hammer in a nail, yet you’ll still find this happening all over the web (this site included). But I think it’s more that the expectations of UX have grown by orders of magnitude in a relatively short time. Frontend development isn’t linear, user behaviour is ambiguous and web technologies weren’t designed to handle things like application state. Now we have frameworks creating abstractions on top of abstractions to transform a hammer into a screwdriver, and we’ve become so far removed from the traditional document system that it’s easy to lose sight of what problems we were even trying to solve in the first place.

So many letter & geometric logos, so little time.

Now that I’ve started working with React Server Components, I can’t help but to reminisce on these simpler times. Don’t get me wrong, I love RSC and I believe they solve an important challenge/gap in the ecosystem, but with these new directives/hooks/APIs & needing to understand their caveats and how they interplay with one another, it’s hard to know if I even enjoy working with this anymore. I feel terrible for new frontend devs who need to navigate this current environment — an impossible garbage-dump of frameworks, libraries, and outdated documentation to sift through, and a few dozen people yelling at each other for choosing the wrong scent of the what’s ultimately the same soap. I also understand the challenges of today are not the same challenges I faced when building my Dragon Ball Z page in 1996. Maybe I’ll rebuild this site with HTMX, or get back into C (which hasn’t changed meaningfully since the Reagan administration*). Or maybe I’ll just occasionally groan about it on this blog and keep on, business as usual.

* I feel like most C devs have no sense of humour, so this footnote is to clarify that I am aware the language standard has actually changed since the Reagan administration.