Ask HN: Why did Frontend development explode in complexity?

Some scattered thoughts:

Just today, I built a complex order editing form in vanilla Javascript with AJAX. It's over 900 lines of Javascript where half of the code is state management boilerplate, painstakingly ensuring the correct effects are run when the user changes an order line's quantity or picks another product. We currently can't use libraries with our stack, so it was necessary to write it like this, but it made me yearn for the frameworks.

The frontend landscape isn't more complex than it needs to be, it's as complex as we need it to be. We take many things for granted in our modern stack. Sure, Javascript has come very far in many areas, but it also lacks many things that are regularly needed and the tooling covers for that. Things like state management, functional composition of layout and form validation are things that Javascript simply doesn't (and probably shouldn't) provide, and that's why we have libraries/frameworks for those.

I see many people bashing on Redux in the comments section. Redux can be overkill if you're writing a single-page (like, actually one page) website, but as soon as you need to manage user credentials and state that needs to be persisted across many pages (think shopping cart), Redux becomes indispensable for me. Sure, you can use something like useReducer, but it doesn't really compare once you add redux-toolkit to the equation.

I agree with the general sentiment about the npm ecosystem. Like with anything else, taking "don't reinvent the wheel" to the extreme causes chaos because the entire world is not a monorepo and we have to rely not breaking one another (which fails often). My rule of thumb for whether I should reach for an npm package is "can I write this correctly and with tests in an afternoon?". Things like arbitrary-precision decimals fail that test, but many others simply go into utils.js.

To summarize my thoughts and make myself a bit more coherent: The frontend tooling is as complex as we need it to be. Evaluate what you need and build your stack with that. Don't join any cargo cults, both for and against framework use.

A host of reasons but it's my opinion that the calculus of what you can develop for what resources simply workout, and that math trumps the regrettable bloat that a portion of the population notices.

You can look at the complicated tooling of '23, the increasingly niche roles ("React state management expert"), the bundle sizes, the expanse of the browser spec and wonder how this trend is sustained, but there's a flip side to all of this: it's easier today than ever to develop well-utilized, sophisticated software with a team. That last part is important- since teams build most of the well-trafficked web applications out there it will be the limiting factor in economic equations. And all this specialization and bloat is conducive to concurrency (see Conway's law [0]).

I'm reminded of an Economist article I read that asserted that better engineering often doesn't solve a traffic problem since the pain of traffic will approach the threshold of what people will tolerate. People who don't drive because of traffic start driving until the commute is nearly the exact same.

[0] https://en.wikipedia.org/wiki/Conway%27s_law

There are a lot of great answers here, I'll just point out one thing that I think is important.

It feels like a lot of the complexity around frontend development comes from managing and maintaining state, particularly between different components. State management is easy when you just have a single JS script embedded in HTML. But when you decide you want a structure that is more class-like where you can reuse components, it's suddenly incredibly difficult to share state between components and ensure changes (no matter the source) are propagated reliably and are also properly reflected in the DOM. You have this whole other layer in HTML that is awkwardly and haphazardly bound to the JS side which just makes things so much more complicated to the point where React makes its own DOM instead.

At first, only devils used JavaScript. Then jQuery/AJAX/Web2.0 made it permissible for it to be used for good. Then Apple killed Flash. Clients and employers still demanded fancy web sites that weren't just hypertext and images. Browsers still only supported JavaScript. Node and npm enabled front-end devs to build and share. All the tiny problems that front-end devs used to deal with, like minor browser incompatibilities, were papered over with layers and layers of abstractions until they naturally ended up with frameworks like React/Vue/Angular. Then the cart came before the horse, and there has only been incremental progress since then because JavaScript is still JavaScript, and the ecosystem is too big to escape.

Anyone who tries to avoid the complexity of the existing front-end tooling soon finds themselves reinventing many many wheels.

> We keep adding tech and tools and experiences - if you asked users - aren't improving all that much.

Nowadays, when a provider adds an "experience" resulting only in no improvement, I feel actually quite happy. The general rule seems to be (not so slowly) migrating to activelly deteriorate functionality.

Past week my bank changed their UI to show a cute animation of a hand shaking some cash in a transaction confirmation screen. And, in the process, they've removed the button to immediatelly logout after the transfer is completed -- something I used to do frequently.

It's infuriating.