HN: "Why did Frontend development explode in complexity?"
Answers:
0) It's not ONE thing--it's a combination for forces/trends/factors...
1) The underlying technologies have become more complex (at least CSS and JavaScript have, but much less so w.r.t. HTML). For example: Flex layout, Grid layout, calc(), variables, etc., in CSS. Async/await, destructuring assignment, import(), optional chaining, spread operator, yield, ...more in JavaScript.
2) Customers and Users 'see' something that looks complex (whether inherently or accidentally), using Web technologies, so they are increasingly conditioned to expect that any application (regardless of complexity) can be build/delivered using Web technologies. A few examples, off the top of my head: https://www.figma.com/ https://docs.google.com/ https://www.onshape.com/en/
3) HTML is--egregiously--impoverished! Quick, when was that last time you saw a non-trivial LOB application (or even most CRUD applications) that did NOT need some sort of data-grid style presentation? Well, luckily we have the HTML5 data grid control for that...oh wait, F** me! And then there's less common needs, like a 'tree control'. Or more common needs like: a robust dialog control (with proper focus mgmt., etc.). To PROPERLY implement (documented, rigorously tested, styleable, i18n support, accessibility support, DOM attributess, JS API exposure, and on and on) just one of those is weeks, even months of work. Sure, if you're only creating something for your own project, you can take short-cuts. But how much effort--and complexity--has been foisted, collectively, on Web application Developers, because the BROWSERS don't have a complete control set??? Arguably, the HTML control set is not much richer (except in styling) than what one could do on a 327X terminal; which is 1960s-vintage technology!
HN "Follow up question : Is that complexity necessary or artificially inflated?"
3) Short answer: YES.
Long answer: as the technologies mature (whether the built-in troika of HTML/CSS/JS; or the add-on stacks), and as Developers become more experienced at delivering applications with 'Web stacks', what I've experienced is that some of the accidental complexity is decreasing. But certainly FOMO and RDD, and similar self-serving imperatives are a factor in having artificial complexity. For example now that 'legacy' browsers are no longer a concern/constraint for many projects, the complexity of Babel, and Webpack are often no longer needed. Or, at worst, can be replaced by more: modern, simpler, and generally performant tools.
Example: https://vitejs.dev/guide/why.html
Also consider the madness which is the global namespace + cascade approach of CSS to selecting where/how styles get applied. There are (? were) benefits to this approach when CSS was exclusively being used for a relatively small number of styles that needed to be applied, consistently, to a large number of pages (i.e., via a rel link to a SHARED stylesheet). But those days are LONG gone! There have been numerous attempts to address that madness, traditionally via naming conventions, for example: https://en.bem.info/methodology/naming-convention/ https://www.keycdn.com/blog/oocss
But those approches are (IMO) tedious; and experience has shown they are not scalable, on multiple axes (application complexity, project longevity, team size, experience level diversity).
So Developers added tooling, such as SaSS, to attempt to overcome the weaknesses of CSS for large/complex projects. That's been at least a partial success. BUT, at the cost of additional complexity in the tooling and build chain. Maybe even having to have an additional language run-time for some tooling like that!
Just having two 'newish' features of CSS: variables, and the calc() operator can potentially reduce a lot of the traditional usage of things like SaSS. In some cases, the need for tools like that goes away completely! That's a win, for reducing artifical complexity.
Another example is the strict scoping of style selectors in Vue's single file components:
https://vuejs.org/api/sfc-css-features.html#scoped-css
Just that one feature alone, completely eliminates the traditional CSS madness, but without the weakness of the conventions (like BEM and O-OCSS), and with minimal (and pre-configured/included) tooling.
CLOSING THOUGHTS: state management is still very complex; at least for non-trivial, and at least moderately interactive applications. In my experience (and I was designing, and implementing, complex GUIs _long_ before the Web was a thing), at least some of that state management is necessary (inherent), for those non-trivial & interaqctive applications. The best we can do is to research and investigate, and try-out various approaches to minimizing the _accidental_ complexity that our state management approach/library/etc. adds to the inherent complexity.
I'm somewhat adverse to making recommndations on specific technologies, but I'd suggest that Developers who are contemplating a Web applicatiion with demanding state managment needs take a look at the following state managment library:
https://tanstack.com/query/v4/docs/react/overview
Comment: it addresses a LOT of the pain points that many Web Developers/Projects encounter. Moreover, I've had some very positive experience with the predecessor project to this one (i.e., React Query). N.B. If you're going to be using: Vue, Svelte, or Solid.js (i.e., NOT React), then make sure to click on the drop-down menu in the UL corner of that page!