But where is all that complexity going? Most websites and web apps I encounter are no better than they were 10 years ago. Sure, they look better, but that's largely orthogonal. There's maybe a bit more interactivity but it's still basic CRUD most of the time. They break the same, sometimes even more.
It seems like chasing marginal improvements in dev and user experience leads to complexity which begets even more complexity.
Not all the fault of node.js
I felt that way about front end end work when I got a FT job working on a React system about 5 years ago but now I don’t feel overwhelmed at all.
The way people talk about it is intimidating though. The average person who wants to make a modern blog should probably host it in Azure or AWS object storage with a generator like Hugo or Pelican. Hugo in particular is zero bullshit if you don’t need to customize it, it is just a simple binary that doesn’t require you to learn anything about go or how people resolve dependencies in go or go build systems. I picked Pelican because it is written in Python and I know I can make it do whatever I want. When I send people to
https://jamstack.org/generators/
It is like waving a red flag in front of a bull in terms of eliciting the reaction of feeling overwhelmed.
What that complexity is really buying is desktop-class web applications like Figma, Notion, and the like, and massively reducing the engineering costs of building products like those to the point where it’s way cheaper and easier to build a rich, complex web app that can run for anyone anywhere than it is to build desktop or mobile software with the platform-holders’ own APIs.
If you’re not doing one of those and are just doing a light crud app, then you probably want to use one of those desktop-class web apps like AirTable.
And if you want to make a static website, then we have some much better tooling you can opt into to make managing it and building it out faster, but it’s far from essential.
So a good chunk of this emerging complexity tries to improve web developer productivity (at the cost of stack complexity and fragility). It's the infamous indirection treadmill, laser focused on a single thing: overall productivity and fast delivery of the final product by low skilled employees.
Now the fact that it looks and feels almost like a new flavor of JSP is another matter. I think the HATEOAS model was tried tested and true and just needed a bit more refinement rather than the total overhaul that SPAs+JSON APIs brought in.
the internal product is _full employment_ along with a healthy dash of _intellectual pleasure_, though much of the latter is in rediscovery of principles and approaches which regularly recur as the pendulum swings. But pride of ownership and invention is strong human drive.
Were seeing bun's first party typescript support pave the way forward to remove the need/weight of bundlers and transpilers
Were also seeing Next.js (for better or worse) pave the way for SSR support in a way that comes naturally for React Devs.
Jamstack is a fading niche, specifically Gatsby (still useful for content sites, but Next.js can fill this role too)
Headless CMS will always be useful for content and is not a JS/SPA exclusive thing.
Serverless adapters is also very niche.
Also SPA's are here to stay, whether people want to accept this fact or not, there is functionality that is only enabled by an SPA architecture.
158 NPM packages already, and the page load requests are insane.
Two reasons I'm doing this monstrosity of an implementation anyway:
1. Resume-driven-development, on a personal/indie project.
2. Using the framework's interactive SSR just to make it harder for freeloaders (AI company scrapers, copy&paste developers) to copy the information or the implementation tricks.
[*] Except for a little flexbox "responsive" flowing, corner rounding (without kludges), and some fade transitions, none of which are necessary.
Then I was in an interview, where some junior openly sneered at me, for not using a recent popular RDD framework for it.
Part of the problem, even for highly experienced people, is that even the good jobs usually have "technical interview" gatekeeping that's not very enlightened.
(Yes, no matter what framework or stack you're using, I've probably done related things before, and I can pick it up quickly. No, a Leetcode hazing won't tell you how I think, nor what I can do, and it just seems like you're jerking off.)
I mostly do backend and ops. Usually, I never generate backend code with llms, I mostly use them to generate test cases and small helper functions, but each time I try to do complex stuff, even with low domain specific knowledge, llms do not help. Rubber ducking is my most recent use (thanks to a comment here) and is fine, making them still useful _enough_.
However, this week I had to do some front-end. I tried llms, once again thinking it would hurt me more than help me, but I was wrong. It can generate 100 good lines of good front-end (granted, mostly htmx) in 3 or 4 iterations. Useful, working stuff, not shit I have to spend hours debugging. I was helped by the fact that I already had an architecture and data models (worked on that yesterday), and it just had to generate forms and containers without real algorithm inside (well, and a FSM but I wrote it by myself, it was easier than try to explain it to a LLM. And it's fun to write).
[edit] forgot my point: I don't think front-end is really more complex than it was in 2014. It is more tedious, and use more tools, but also more streamlined and straightforward. My story about how llm fare is also about that: it seems really good at generating boilerplate/streamlined code, and front-end is mostly that. Also now I understand devs who say that llms took 50%+ of their workload, when before today I thought they were lying or not realising the lost time from using them.
I certainly don't appreciate the cognitive load a lot of my daily stuff takes. It used to be simpler, more direct, and more satisfying.
With each new wave of technology, things improve, even if they look the same on the outside. For example, today’s huge online stores weren’t possible 10 or 15 years ago. Innovations, like better system design and separating different parts of a website’s function, made this possible. New frontend tools pushed content systems to be more focused on APIs, leading to headless CMS platforms (Contentful, Strapi, etc).
I believe the next big change will be about using less energy when browsing the web. This could lead to new tools, hosting technologies, or apps. While websites might still look similar, the experience will keep getting better in small, meaningful ways. Another cycle of improvement is just around the corner.
(2) I want roll my eyes at the bit about "dopamine". It's true, but in the same sense that "adenylate cyclase is activated" and "proteins get phosorylated" and "genes are expressed" and so forth. Your brain is a complex system and anything it does involves the coordination of many kinds of neurons. Scientists know a lot more about it than you or I and there is vastly more that they don't know about it. Probably every kind of neurotransmitter is involved when you see something on social media and repeat it.
(3) I remember Amazon being pretty big in 2000. I'll grant that you can provide people with a richer experience with front-end tech but I don't see SPA being needed to make a store with more items or that handles more users. I remember circa 2011 that many of the web designers in my town who were really good at making Ruby on Rails app seemed to think they couldn't sell that kind of system to customers and they struggled mightily with AngularJS and other frameworks. They regained their footing with React. (Has a bit of that "worse is better" feel like C. I want to like Vue but I can draw whatever I want the way I want to draw it with React.) What appeals to me about heavy front ends is really new stuff like
I mean being able to deliver 3-d content to desktop and mobile and jump into an immersive world is really cool and makes my brain feel good.
(4) Are you talking about energy use on the front end, back end or on the huge spiderweb of wires, fiber optic cables, amplifiers and such between them?
Anyways, tech doesn't have to be your hobby. You don't have to be aware of anything outside your company. You company could've bet on SPAs about a decade ago and you could still be on the set of solutions surrounding that, unaware that SSR even exists. That's the level of stress which you are contractually obligated to, and nothing more.
It's a shame, because the actual web platform as defined by browser APIs has gotten hugely better just in the last few years. We rarely see any of those improvements taken advantage of in the wild though. It's a huge, huge bummer.
It becomes a little bit easier with Next.js 15 tho
If you can't wait or don't want to figure out the black box magix,I offer https://achromatic.dev which is basically all RSC, server actions and based on shadcn/ui.
In web front-end, the same pattern crops up repeatedly. Two examples:
* Elm[1]: It's brutally functional and limited by purity, but it works
* htmx[2]: It's grug-brained[3] and limited by that, but it works
I'll let others enumerate web frameworks. On desktop, software for uxn and Varvara[4] by Hundred Rabbits fits the same pattern:
* 64k of RAM and limited to 4 colors, but it works
* Created when Xcode was painful to install on a boat over pre-Starlink satellite internet
Who knew rage-quitting could be so productive? ¯\_(ツ)_/¯
[2]: https://htmx.org/
[3]: Said to be by the HTMX creator: https://grugbrain.dev/
Thankfully it's slowed down somewhat since then, with the frontend industry mostly standardized around Next.js for big apps, Vite for sites that don't need much serverside rendering, or Astro for simple blogs.
As for whether there are results to show for it... well, now you have some pretty cool web apps like Figma, ClickUp, Felt, OpenSolar, Photopea, Codesandbox, etc. that actually use interactive clientside Javascript to its potential. That would've been more difficult with a server-only stack that renders and sends HTML over the wire, or with manual AJAX fetches. Is it possible? Yes, just harder to reason about -- and importantly -- harder to divide up across multiple developers or teams.
What Jamstacks (Javascript, API, Markup) are really good at is allowing a cleaner separation of concerns, where one team can work on the backend API and another can work on the user-facing frontend and a third can work on editorial content, all without stepping on each other's toes (but with frequent communications and collaboration).
Are they misused sometimes? Yes, often, I think. A lot of sites don't really need to be in Next.js or a Jamstack at all. Wordpress would've worked fine. Wix would've worked fine. Anything would've worked fine. But our industry chases trends, beginners are taught what's fashionable, and then when they're no longer beginners, they try to improve the tooling, eventually some of it gets good enough to start a new trend, and the cycle starts anew...
------
<Long rambling anecdote>
On a personal note, I think a part of it also might be the nostalgia of days past that weren't really all that simple. Maybe we just forget how complicated it used to be?
I started web dev back in the 90s, hand-coding HTML on a 28.8k modem before Javascript and CSS were invented.
My first full-time permanent job was as a full-stack PHP dev, where I had to manage not just the HTML and the PHP templates but also the bare Linux VM under it (this was before EC2 became really popular, so we still rented shared metal from a data center) and everything above it. I had to learn and implement every OS package, every daemon from redis to varnish to monit, every row in every database (we used MySQL for most things, Postgis for geo stuff, Filemaker for other things), every interop script with other parts of the business (sometimes in AppleScript, sometimes C#, sometimes a Bash script, sometimes some Excel macro), every SSL cert and DNS and SPF setting, every PHP and Varnish and Apache option, every MySQL and Redis clustering/slaving/failover setup... long before ever touching the HTML.
Then on the frontend side, we had to hand-code every basic JS interaction from the cart total calculator to every AJAX fetch from the database, all while screaming at the then-primitive CSS and trying to massage it to work correctly across Firefox, Chrome, IE, Safari and all of their rendering quirks and and CSS and CORS bugs, while juggling more complicated functionality across several versions of jQuery and a horrible matrix of JS features supported or not by different browsers, all while phones were beginning to become more and more important but best practices and standard UIs weren't fully developed yet.
I don't think there was anything simple about that stack. Every single layer of it had like a hundred different failure modes, all of which compounded exponentially with every other layer, and there were a lot of layers. When something went wrong, it was always my job to figure out where in that maze things went wrong. There wasn't really such a thing as a frontend or backend dev yet, you were just a web designer, and everything from the graphics to the code to the server was your responsibility, whether it's a GIF alpha transparency or SVG rendering issue or a cache invalidation bug.
Fast forward a decade or two, now the web landscape is very different, but a `npx create-next/astro/vite-app` will get you a functional local website in under a minute. Two or three clicks will deploy it to Vercel or Netlify in seconds. Databases can be similarly configured and deployed within a few seconds, if you need one. I can make an interactive dashboard in half an hour, polish it for another, and have it ready for users in half a day. That sort of productivity was never possible in the old days. Part of it is the growth of managed higher-abstraction services (i.e. they took the legacy clouds and built value-added abstractions over them to create things like Vercel, Netlify or even just DigitalOcean and Heroku), but the JS framework race did yield some useful (if messy) outputs too.
You can still make websites the old way if you prefer. But coming from Perl, PHP, and Visual Basic, I taught myself Javascript and React over the course of a few weeks. Once I got over the initial learning curve, it was an incredible improvement over the old ways, at least for frontend work. Once you start being able to compose pages out of real components, serverside templates and string replacements and such will never be enough again. Typescript moves the error-checking from runtime to write-time, vastly simplifying the debugging process. Modern IDEs are an incredibly powerful tool compared to the old text editors and basic syntax highlighting. Hot reload and built-in preview servers make any changes go live by the time you can cmd-tab back to the browser.
The developer experience now is sooooooo much nicer than it used to be, if you know how to use the tooling.
The UX, not so much... but that's because most of the industry thinks of the user as the unwitting victim to be productized and milked, not as the customer :( That's not really the fault of the frameworks, but company business priorities.
</anecdote>
Seriously now, using Preact and vanilla JS without any build steps is something that more people should try out. Even bundling seems redundant in these days of multi-request HTTP connections.
