There are three main points I want to add to the conversation.
1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically.
2. The grass isn’t greener on the other side. I see a lot of people complaining about the needless complexity of the frontend stack but I don’t think they’ve worked in a modern backend engineering or data engineering project. Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example. Feels a lot like frontend in terms of accidental complexity. So I’d argue that this is less of a frontend problem and more of an industry wide thing (cynically, it might be a ZIRP thing)
3. With that said there certainly is needless accidental complexity in frontend and I am convinced content marketing is 100% to blame. An easy way to hire engineers is to create an open source project and write a blog post convincing people to use it. This is good for the company and good for the careers of the engineers who worked on it, but can cause people to needlessly complicate their tech stack if they can’t cut through the noise.
Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date.
Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that it comes for free or because of incompetence (though that too of course). And a lot of the times it looks almost as if software engineers do it on purpose, sometimes very creatively at that.
Where is this coming from? Is it because we want our work to look important?
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.
1. UI development is hard to do well. Throughout my career I've seen complexity explosions in C++/Win32, C#/WPF, and JS UIs so this isn't a new phenomenon
2. It's always easy to develop the correct UI in hindsight once all the requirements are known. When starting out it's hard to know what will be needed or not and this leads to overly complex solutions
3. The browser as a platform has historically been painful to use due to a lack of good standard library
4. JS in particular has a low barrier to entry, so a lot of folks start there and learn as they go. This leads to picking the wrong tool for the job due to lack of experience
The web was made for publishing text, not making rich apps. But it turned out to be exceptionally good for publishing SaaS. So we continued to pigggy back on it. Working directly with the DOM is too verbose, hence nobody wants to touch it.
2- Service oriented architecture
When mobiles became a thing around 2008, normal MVC apps with some AJAX would not cut, because mobile phones needed their own UI. Hence REST based approach became more popular. Things like React and Angular (or Backbone and Knockout) filled that void.
3- UI is an evented runtime
I think of UI as a small Kafka because it needs to handle events (from the user, from the browser window, from OS etc). This makes managing state tricky. To manage this complexity, the community comes up with libraries like Redux. This creates a gap for developers working at a smaller scale. With a small app, you might not run into issues arising due to event management, you might not run into race conditions. But since big companies use a particular library, small companies start using it too. This adds to the bloat.
Is there a fix ?
I think so. But it will include developers thinking outside the browser (or maybe the browser starts thinking outside the DOM?). Libraries like Hyperview and DearImgUI exist and are being used in production. Games are a good example. A game engine can render a complex scene with 100s of moving entities at consumer grade hardware. At the same time websites suffer when rendering large list views.
At the end, FE is a political landscape. A large majority of developers and companies are happy with the current state of tooling. Unless an influential figure pushes for a better UI standard, we will continue to write React.
Jevon's Paradox, originally written about the use of coal, noted that as it become more efficient to use a resource, the end result was generally not that less of that resource was used, but in fact more.
I think the same thing has happened in frontend development: Tools which were written to make development easier have not had the effect of making it easier to do frontend development, but have made it possible for outside factors (product managers, customers etc) to demand ever more from frontend devs.
I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority.
Programmers love shiny new things and most managers aren't technically competent enough to lease them...
Frontend development is mostly done by people who are into visual things and less into logic.
Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance.
This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing.
After some time frontend developers will find some new framework with a better landing page and move on to that.
And the cycle repeats.
It is media that changed quite a lot - spectrum of devices that we need to show our UI on.
We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1/96 x 1/96 of inch.
Such fix allowed us to use UI designs nailed down to pixels grids. That was time of flourishing WYSIWYG UI editors. Alice, designing her UI in Delphi (or VB) editor, can be sure that Bob will see it in the same way. Her cool 16px icons and bitmap fonts will make Bob and friends happy.
When we needed some "extremely cool" stuff at that time we were providing bitmapped skins. Remember WinAmp (https://skins.webamp.org/)?
Time is passing by and we have now huge variety of devices with different pixel densities (96ppi, 192ppi, 300+ ppi) and pixel grid sizes - from watches to wall sized TVs. But we still want to show the UI on all of them in reasonable manner.
The solution is to change paradigm an so to use a) vectors for UI definitions and b) flexible/adjustable UI definitions that are detached from pixel grids.
Web, as a UI platform, desperately needed vector UI with flexible layouts as the very same web page needs to be presented on all platforms|devices in reasonable manner. And so it was the first one that departed from fixed layouts.
So UI design have changed from simple 2D painting (physical brushes and canvas, paint.exe ... Delphi/VB/Glade IDEs) to procedural and rule (layout, style) definitions.
We speak now in quite different UI language and that's what was changed really.
I think you need to make distinction between website and web application. The latter came later and is by definition a lot more complex, I assume this is mainly where the premise originates from.
But having gone through building websites with frames, tables, png's for box shadows and border radius, jQuery and php based web apps, and having spend many days making my grunt/gulp/webpack config work and supporting IE, I can with great certainty say things have never been easier than they are now.
Now, is it necessary [to build webapps]; Yes. Usability expectations have gone up, the level of details and polishing has gone up, more interactivity, and more sophisticated visual elements. Webapp now do things native applications could not do back in the day.
Recently, however, for fun I've been tinking with TypeScript and Vue and I have to say, it all seems way easier than how we did it back in the day. CSS seems far more reliable, HTML now has sane ways to lay things out, Typescript/Javascript has evolved wonderfully, and these modern frameworks that isolate components from each other and bundle code, style and layout together are almost a pleasure to use. Sure, there are some concepts you have to learn, and there's so much magic happening behind the scenes it's terrifying. But I'm building stuff I would have spent days on in a matter of hours now and I have no idea what I'm doing.
What I'm noticing now though is that now that frontend development has become a lot more about coding and a lot less about knowing arcana, frontend coders seem to be going through growing pains that are a lot like backend coders have already gone through. For example, it's funny to me to see discussions about how to handle components needing to access shared data. Should you pass the down down through the component hierarchy or have a single global data object that components can interact with, and I'm thinking, next stop, a dependency injection framework. I'm not sure I'm actually right about that, since I've only just played around a little bit. I'd be interested if others would agree with that assessment.
Now that I'm 2 months in, I still don't see the complexity, actually, if anything, React makes stuff so much _simpler_ due to its leaning heavily towards FP (to me, the class-based approach of React seems more complicated than the hook-based, for example, deciding what `this` points to at any given time in Javascript is no small feat - with functions/closures, you don't have this problem). There is depth for sure, handling all the possible errors and edge cases requires care and attention, just like in the BE.
To me the only shock so far was how low level all the stuff is, I mean come on, we had Delphi in the past millenium already, creating a form with a text field and connecting it to a field in a data structure was a solved problem back then... a "one liner" if you will, now you have to independently manage the state and handle events for each field? Come on, there must be a higher level library that solves this!
This isn't unique to web development. The same thing happened with C++ and Boost, for example, where gradually the language and standard library evolved to include functionality that previously required 3rd party libraries.
But I think far more work and money has been invested in web development than other areas, hence creating a bigger mess.
My impression is that the actual user experience of most web sites, including the big ones like Amazon, has improved very little over the last decade, so it feels like all the effort put into web technologies has, so far at least, not produced a lot of value.
Their complexity is so big, that even great programmers have a hard time creating browsers from scratch. The latest example of this is probably Ladybird[0]. Andreas Kling and others have worked on it for years("Just under 1000 days for a bunch of hackers to build a new JavaScript engine"[1]) and they know it will require way more time to just catch up the Chrome[2].
A year ago I started to build SkyAlt[3], which doesn't have anything to do with the web. It's not just a browser, but also an IDE where you can create apps with few lines of code or just drag and drop stuff on canvas. It's written in C and it's only 25K LOC. Compiling takes a few seconds and binary is under 1MB. There are tons of features that need to be built, but I like its simplicity(relative to the web).
[0] https://github.com/SerenityOS/serenity/tree/master/Ladybird
[1] https://twitter.com/awesomekling/status/1596783757125898243
[2] https://twitter.com/awesomekling/status/1595387284035145729
2006-2009 server side frameworks were in vogue but most were slow and sometimes memory intensive. In the pursuit of creating highly interactive experiences that also scale many of us were optimizing website architectures around cached components of varying vintage and write frequency.
By 2009 we were solving for performance + scale + interactivity challenges using client side rendering for highly interactive components. During that period I can remember doing isomorphic rendering of mustache templates in server side Ruby and client side Javascript.
2010-ish Node was starting to gain traction and lots of attention went to Javascript. I think post-2010 many were pushing web app architectures to more client side business logic as web browsers became more and more capable. Backbone.js, SproutCore (now Ember.js), Knockout.js and others were on the scene by then and I think most other frameworks are inspired or derivative approaches meant to solve for their shortcomings.
2014-ish I think everyone was pushing responsive web. Apps got fatter and needed CDNs now more than ever. Websockets start to gain maturity. Cloud-services really start to gain traction beyond EC2 type deployments.
2015-2016 is the inflection point where client side frameworks start to get stupid complex, i.e. I can no longer read the source code of a web page easily, simple read only sites have a loading screen and/or need to download 1MB+ for reading a basic page.
It exploded with complexity because frontend complexity exploded. Simple. Absolutely no people expected an "API call" from a frontend application 20 years ago, now people expect loading indicators on buttons (that make API calls) after pressing them.
Just have a look at the comments on the recent Standard Notes / React Native post. https://news.ycombinator.com/item?id=34197613
Really, the browser side stuff is the real PITA. It's a hacked together piece of shit written by people who were too clever by half. And it's designed to be used/driven by less-than-skilled individuals.
But in the end one big problem is there aren't a lot of ways to model a UI effectively. One given screen can have multiple states and behaviors that are state dependent, and the tools really aren't there. How do you specify "animation like x/y/z" on a screen?
There are tools for designers, but they're don't really work when handing that off to development. What I've seen is people printing out prototype screens and annotating everything, but that's obviously janky.
It's possible that building a website as a wholistic product (ala Ruby on Rails) is inherently less complex because it eliminates an artificial boundary. We see backend teams struggling to build APIs and frontend teams struggling to consume those APIs. Many of the technical problems, communication overhead, and complexity seem to lie at this API boundary. Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I'm looking at things like HTMX and phoenix live view as a potential solution.
But the other reason is that we don't have stable tools and the right abstractions to build a UI/UX for dummies so there is lot of reinvention.
Because nobody built a good UX/UI for dummies that hides this vast complexity?
- the core if the web has been, is, and will forever remain a system of displaying static text with a couple of images. You as much as look at it funny, and it needs to re-layout and re-render the entire screen
- there's no standard library to speak of
- there are no standard widgets and controls to speak of (https://open-ui.org/ is twenty years too late)
- there are no easily accessible ways of handling state
- almost every single API that the web provides is either underngineered, or overengineered, or badly designed, or all of them together
- the web rarely provides a comprehensive and/or a generic solution or an API. It's a hodgepodge of one-off hacks often needed to cover deficiences in other hodgepodge hacks
So, to make the web even remotely app-like, you need to solve for all these issues, and that's before you even start writing a single line of app logic.
And on top of that you have language evolution and people wanting to use features of tomorrow today.
I am sure, there'll be quite a few who'd argue that this is necessary complexity, but my take on this definitely is the latter - artificially inflated
But it's not only the web. Same happened to Java in the 2000s and is currently happening to Android. Any mainstream Java job is more configuration of Spring containers with a bit of code glue sprinkled in-between than "proper programming". As for Android, just follow a couple of Android forums where plenty of people complain about such complexity and frameworks changing "by the minute"
Aritifically inflated :)
I have many more years of experience programming now yet I could not make the same program nearly as quickly. Fire up Xcode and then fumble with storyboards or SwiftUI or IBOutlets? Start writing functional React components on a Bootstrap grid with some live reload script injected into the browser?
Modern frontend tools enable improvements like accessibility, internationalization, cross-platform compatibility, touch screen support, etc. But they have really extinguished my excitement to build anything beyond the command line.
The web is an incredible distribution channel. With decent engineering, anyone can make an app that has access to an enormous marketplace with very little capital costs.
The past 20 years of software have been dominated by this distribution model so it's easy to take for granted, but compared to pre-web distribution that involved manufacturing and much larger differences in user platform, it makes sense that the world is trying to squeeze as much software as possible into this model.
With that comes complexity.
If something doesn't work out there is yet another react-centered solution to your problem. Server side react can probably fix it. Tailwinds can fix that other thing.
These websites must, obviously, be hosted on kubernetes clusters. They must also be behind three or more load balancers.
Never attempt to cache anything. Redux is managing state and state can't be cached.
I realize you didn't say "React" in your question.
redis has to be installed, even if not used.
Back when I started, the go to front end wasn't a web app either. It was some GUI on windows which involved pretty much the same level of complexity as we have today on current web apps. So maybe the question isn't really "why did front end development explode in complexity?" But really "why do we expect front end development to be simple when asking for complex UX?"
Because we don't have just 1 or 2 desktop web browser mostly rendering text anymore.
We've got 3 or 4 major browsers that most managers want to support all, even though one has over 50% user adoption, and could be installed within 2 mins if not due to IT administrators locking everything in and shipping almost nothing to browse the web.
Each of those "major browsers" with their own same but not the same implementation for mobile, across many different sizes from tiny low rez screen to worry about to phablet/tablet factors, that can rotate of course, so landscape and portrait please, packing videos, photos, and scalable graphics often within the same visible area.
One would think that's enough headache to deal with, but fonts aren't treated equals, and remain proprietary so text won't be the same across windows, linux, OSX and android. No. You may pick one system font that is called the same so should be the same, but it isn't actually the same, at least last time i checked it wasn't.
Oh, and the highest speed consumer bandwidth out there is something like 400Mb/seconds, and the lowest might well be a under 100kb. Both want the best possible, so full HD clip and MB pixels pictures for one, and low def steaming and scaled down pics for the other. And throw something in between to make the average bandwidth users also happy.
Oh, and since we got the cloud and aws is "cheap" demand super quick agile delivery of course. Co pilot and soon gpt codex will make it no-excuse to be late on those over optimistic estimates.
Is it more complex than single-device programming? Perhaps, but the modern browsers represent a nearly universal platform with very low per-user complexity.
1. more and more complex UI. Things that used to be done in a native app are now in a browser, this has good and bad parts.
2. a lot of show off from the developers side going for overly engineered solutions. Nobody likes HTML+CSS and JavaScript anymore, if there is no cool framework with tons of tooling and dependencies than they are not happy. (yes, I know, flak incoming)
Other reasons are the complexity of dependency chains, the lack of security mindset by having hundreds of dependencies looking for a left-pad, the complexity coming from the testing of these overengineered and overly complex solutions, the move towards hybrid front end-back end management of state, rendering etc. There is also the overstretching of the frontend development role, now a fe dev needs to not just write the equivalent of HTML+CSS+JS but also containers, devops, CI/CD, all that jazz.
Backend developers are much more likely to pass leetcode and algorithm questions and have decades and decades of material and languages to draw from. We don't use 1st generation stuff to build anymore.
Once 'frontend' (i.e. browser dev) has close to that much time to cook we'll have a lot better experience with typed language support native in browsers and/or a proper green threads.
I mean, just look at everything that came out of the past ~10 years alone: Coffeescript then Typescript, LESS, SASS, most bundlers, push notifications, webworkers hot reloading, websockets, webrtc, SSE, free/default-on certs, all the component frameworks like bootstrap, tailwind, material ui etc...
While browsers have been around for a while, the ability to use the browser as a full-featured UI is pretty recent and most people working in this area seem to be pretty young.
1. user requests page
2. program generates page
3. user clicks on something.
4. * entire page is regenerated *
Javascript was terribly incompatible across browsers, so it was avoided. Then in 2004 or so, jQuery made it seem easy and desirable to do more than just regenerate the whole page when a user took an action. This introduced all the complexity you see today. React is just the apotheosis of a long sequence of tools whose purpose was to reduce the complexity introduced by jQuery (and "Ajax").
One way to look at it.
It's not the UI is very complex , or that there are ton of frameworks with different maturity levels.
It's because the browser and thus html/CSS was made for documents.
If we made a "browser" made for apps, where we didn't need to transpile to js, and didn't need to cater for incompatible browser versions, but could concentrate on what really matters we wouldt have such a big problem
1. Lack of skills. Front-end has evolved from web design. If people like to criticize software engineering as “not real engineering” then front-end is the farthest thing from engineering that exists in software engineering. One can see this in the programming languages, the code reuse (libraries, packages, etc), the tools and the attitude.
2. Too much ambition. At the same time I don’t think I’ve ever seen a community so driven by reaching their goals at any cost. Once apps kneecapped web sites the community had a major identity crisis which they solved not by doubling but by tripling down on HTML, CSS, JS and the like. Standards, common sense, performance, usability, privacy be damned. Because of point 1, the solutions they built were also just good enough to not completely fall apart. This is also why everything’s being rewritten in the web.
2. Too much money. Unfortunately companies like Google and Facebook made an immense amount of money ruining privacy for everyone and they could do this faster, better and out of sight with web apps. They poured money into web technologies like their lives depended on it (because they did) and in the end managed to squeeze a round peg into a square hole: the fundamentally mediocre web managed to displace more worthy technologies and entrenched itself.
Every few years some poor soul realises the reality of their professional existence and writes a blog post or comment asking something along the lines of “Why is front-end so terrible?”. But there’s too much money in the status quo, so they either get gaslighted, or subtly dismissed and the cycle repeats anew.
And that reality is that you can polish a turd. With enough manpower, motivation and money you can really make it shine. But underneath, it still stinks and people will figure it out. :-)
Note: I got out of front-end in the 00s and then out of back-end a year later. Since then I’ve watched this never-ending train-wreck with amusement and amazement, but also sadness when realising how many real apps are replaced by soulless Electron shells.
The UIs also have become more complex. In early web apps, you submitted a form and got feedback only after submission. The expectations for modern web apps are much higher. Everything has to be evaluated as soon as possible, possibly while the user is entering it. Responses should show up immediately, so there is a lot of caching in the frontend. It all adds up.
Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere.
I don't envy young programmers these days, the amount of stuff to wade through is just mindblowing.
The browsers became more capable (as someone said in another comment, they are effectively shooting for operating systems now), and more ambitious projects became possible. Consider such web apps as:
- Google Maps
- Google Docs
- Google Meet
- Youtube
- Adobe Photoshop online
- Figma (or Penpot)
- Miro (or Mural)
- Excalidraw (or diagrams.net, or lucid charts)
- Slack (or Discord)
- ...etc
This entirely depends on the product. You need the complexity for some products; and not for others.
1) Plain HTML/CSS, built using desktop tools like FrontPage/Dreamweaver
2) Server-side scripts (CGI/ASP/ColdFusion) to dynamically generate HTML/CSS. Javascript or VBScript for "Dynamic HTML".
3) Javascript wins, VBScript dies. Javascript idiosyncratic between browsers. Flash fills niche for dynamic client UX that generally works on most browsers.
4) iPhone happens. Safari won't support flash. Devices that do support flash or a subset have terrible battery life.
5) Javascript has matured. jQuery patches remaining cross-browser issues.
6) Server-side frameworks like ASP.NET, Ruby, PHP, NodeJS mature.
7) JS further matures. cross-browser without jQuery feasible, but binding to JSON is still clunky. Frameworks like Angular, Vue help with databinding and other common problems developing JS/CSS/HTML clients.
8) If you solve enough problems, you end up with a framework to build a complete client, transpiled from various languages (TypeScript, SASS/LESS, some markup). Angular, Vue, React, and other SPA frameworks evolve further.
9) Some UX/SEO/perf issues with SPA approach. SPA frameworks evolve to support server-side rendering.
10) Static sites generated by frameworks reduce the need for server at runtime. Build the site and host on cheap CDNs
...and this is where we are now. As someone more used to ASP.NET + Vue/Angular, I'm still having a hard time transitioning to server-side rendering, WebPack, etc. It just feels like too much ceremony and too many dependencies. I think the industry is waiting for some solution that is low-dependency, widely adopted, open. I haven't found my perfect platform yet, but feel it looks like this: Put a few files in source control and very easily spin up sites that look ok by default but are easy to customize. It supports building sortable/filterable grids,lists, and forms against some server API (REST/GraphQL/etc) with minimal code and and simplifies auth. It also has a rich ecosystem of components.
And developers don't need all of these browser features every time; much less for the same project. But from a framework POV those features need to be there. Because, as a framework developer you cater to a relatively wide developer profiles.
So far we've talked about browser APIs and how a framework seems to lend support to them. Building web apps are a whole different affair. When concepts such as optimization, and, page-load speed kick in you'd definitely think of tools that abstract away the common chore of such optimizations. Again these optimizations have their own set of options, and, hence complexity.
So today the whole affair may seem complex. But really its not artificial. There was a need and hence a solution. To anyone relatively new to web development all this might seem complex. And at some level, even we humans also unjustly decide we need to have some features because "others are also doing it". This also increases complexity in maintaining those solutions.
Bottom line is, it is a relative illusion, and, it just echoes the state of modern browsers, and, modern web development trying to be vogue.
Also, ask yourself what the difference in UX is between serving templates vs. something like React. Are you not getting something in return?
There may be some artificial inflation but think about websites from 10 years ago.
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.
... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc..
Long story / ramble:
A simple static website can be as simple as a bit of HTML with CSS.
But when you introduce workflows and users it isn't long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don't roll your own)
So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I'm a fan FYI)
And then you want the website work as a progressive web app, so you need a service worker. More complicated.
You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated.
Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages.
And we're not even talking about the technical issues, like not all browsers supporting certain API's or certain styles. Or updates to package X breaking package Y, needing a package patch.
Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.
Another reason is that the languages and tooling to do these things are always easy to start and painful to master, leading to too many sort-of capable people dreaming about how to do it better.
I’ve heard mithril.js recommended before but I’ve yet to try it. I have experience with Angular, React, and a bit of Ember and the amount of code and “magic” involved is absurd.
- Fast Fashion for web sites. Users are kinda like kids in a toy store, always jumping to the newest & coolest & shiniest things. OR - at least the suits making the calls are far-too-often convinced that they need the newest & coolest & shiniest web site, to compete for users.
- One-upmanship among young male web developers, who always want to be working with newer / cooler / yet-more-complex technology than the next guy. And how very convenient that newer, cooler, and more complex technology tends to pay far better, whether it's needed or not.
What interests me is why are so many people perturbed by this. If I look through my bookmarks, pretty much everything could be server side rendered without any need for JS. It’s all stuff like HN or news sites. I wonder if the OP and others who have asked this before see the same thing: the consumer internet sites they most visit don’t need complex JS. But that doesn’t describe all sites. There are plenty that do require a lot of complexity.
* It is not that native GUI libraries like Qt or SDL or GTK are super easy. GUI are event driven and composed and need to be in sync with the user wishes and as such have a programming model that is different from a top to down execution of instructions.
* The biggest challenge with the current state of front end development though is that there are no standards and no stability on a YoY basis. What I learned to do with PHP in 2005 is still valid. I can still use those tricks and whip something useful. What I learned to do with tables in mysql 3.x is still useful with mysql 8.x. However the world of Javascript frameworks is one of shifting sand.
What I learned with Javascript framework X.1 will be obsoleted by X.2 and will be obsoleted by X.3. No guarantees for time investment is challenge #1. angular 1.x -> 2.x, Vue 2.x -> 3.x are some examples that come to mind. Think of all the wasted effort. That is the killer. Humans are good at making peace with whatever crap is thrown at them. I do not think technology is the reason here. It has more to do with hype cycles and trying to catch developer's attention in a competitive market with new buzzwords.
* There is a lack of simple tools like what visual basic used to do. Sure, everything is async and we are in an event driven world but frameworks could have provided a common core to enable simple use cases. bootstrap library is a case in point. I can get decent results with bootstrap without knowing the intricacies of css. However I am hard pressed to find a suitable Javascript framework.
The complexity will stay and get bigger, we need to a way to control it and be able handle it.
The first step is to abstract frontend development (be it web, mobile, desktop or even VR) into concepts then introduce a system to build apps with these concepts.
Totally unnecessary in 99% of cases. There are outliers where this front-end/back-end state division madness makes sense (i.e. gigantic apps managed by gigantic teams), but most web properties are not this big.
To be clear - the division of state between client & server is where almost everyone is struggling. State management is usually the hardest part of any complex app. When you have 2 piles of it to worry about, you make life much harder.
In my view, the happy-path solution has been out there for a while. Frameworks that utilize a web socket (or similar bi-directional messaging abstraction) to directly relay user events & DOM updates. This can eliminate nearly 100% of client-side state. If you keep the logical representation of all clients' views server-side, you will have a much easier time keeping things synchronized (because there will be nothing to sync except the session cookie).
I started this journey with Blazor (server-side), which really helped to solidify the concept and its pros/cons. Now, I have a custom framework that achieves approximately the same outcome, but with much better alignment to my problem domain & requirements. I add my middleware and work directly with HttpContext these days. Life is so much easier when you don't have to deal with layers upon layers of opinionated indirections.
People like to play. (Remember blink tag? Scrolling marquee?)
What you're seeing in the JS Frontend space is (in my considered opinion) a combination of the effect of:
1) Lots of people learning to program by messing around with JS, and
2) Folks willing to pay people to mess around with JS.
So you have a volcano of creativity combined with a tidal wave of money...
The results were inevitable.
> Follow up question : Is that complexity necessary or artificially inflated?
No, and yes. It's not necessary (for the vast majority of sites) so it's definitely (IMO) artificially inflated.
The good news is that you can end-run all the introduced complexity by using e.g. Elm lang ( https://elm-lang.org/ ), or just sticking to simple "plain vanilla" JS systems. The only reason to use something other than Elm is if you enjoy some other particular system (I hear good things about "htmx" https://htmx.org/ )
Question 2: both?
I started my "career" with an internship job where i had to write deploy some cakephp+sencha extJS with windows server 2004 and IIS (~2013/2014).
The frontend part were "easy" but tedious, it was tables upon tables, a bit of jquery just because, absolutely hideous css (i think at the end i added bootstrap twitter classes on Sencha extJS). the "backend" was handled a bit like today, with a bit of backend work in the "View" part of the MVC (because Sencha ExtJS). Hard to find bugs induced in this "backend" work, because the only tooling you had were the old devtools, the only documentation you had with the official one (and a bit of SO/blogs, but not that much), and since typescript didn't exist, you had a lot of weird type/casts bugs.
I recently started a new job were i also have to do some short interfaces for my step functions, served by lambda (mostly). I had to learn react and typescript from scratch, and thought i wouldn't be productive in months. I was productive after a week, and after a month could confidently say i'm fluent with React router and props, and passable with typescript (Complex union type threw me off for more time than i like to admit). I still don't know if i understand ExtJS :/
By the way: the documentation isn't that much better now, with all the shitty blogs and stuff like "tutorialpoint" on google frontpage, but you can search code patterns through github and gitlab, and this help immensely.
1) npm encouraged small, "single responsibility" packages/libraries
2) developers are encouraged to never "reinvent the wheel", leading to them to pull in these libraries without considering the tradeoffs
In other engineering disciplines people are taught to consider tradeoffs more than in software engineering.
The tradeoffs of depending on npm packages are:
1) You don't need to reinvent the wheel, i.e. you can build very feature-rich applications at high velocities
2) Tracking, researching, integration, maintaining, and (for longer lived projects) migrating from package-A to package-B can cost way more time and energy than you'd initially think
3) Almost all packages are open source, so maintained in an ad hoc way by the contributors to the project. Even the biggest, most cohesive, well planned projects under the umbrella of tech megacorps sometimes fall into stagnation and maintenance hell. "react-scripts", which underpins the de facto standard way to bootstrap react apps "create react app", hasn't had a patch version released since Facebook pivoted to the Metaverse.
Answer to follow-up:
No, you can absolutely write modern, feature-rich front-end applications without any dependencies. You'll spend significantly more time writing lower level code allowing you to render your data into some kind of view, manage form inputs, app state and routing, but if you're disciplined and determined it's totally possible to do.
That said, using a framework because other companies are using frameworks is definitely an unnecessary layer of complexity, and most websites don't need to be using React or the like.
Regarding UIs and Designs: companies want their sites to look nice and so they hire designers who may or may not be trained to design for the web. Print design and web design are very different disciplines. You can end up with really strange and poorly performing sites when a design doesn't match up with the reality of browser rendering.
Regarding sites that have huge payloads: this is almost always a product of management/marketing input, and payloads end up ballooning when someone says "can we just add an X pixel" or "can we try this one new piece of tracking software." Is the complexity there necessary? Probably not, but when multiple stakeholders have say, this is probably going to happen.
In the past, we didn't have complex UIs, we did, but we dealt with them differently. For example, in the era of forms and limited Ajax, keeping the DOM synced with the state took a lot of work.
The complexity we see today results from different ideas of how to deal with that _synchronicity_.
Keep in mind that there's no way to do it natively; the only way to do it is to manually keep the state in sync. The complexity we see today results from the abstractions people have created to accomplish that, e.g., jQuery, Sammy, Backbone, Knockout, Angular, Ember, React, Vue, Svelte, etc.
Enterprise and FAANG required optimizations for different reasons, scale, collaboration, distribution, etc. Programmers wanted to use paradigms to represent things and apply optimizations on the web, and JavaScript wasn't enough. So, they created CoffeeScript, Flow, TypeScript, ReasonML, etc. These tools became popular in the FAANG, wrote posts about them, then people of all industries adopted them.
To use all these cool tools, people created bundlers—each with its configurations, patterns, and philosophies—gulp, Rollup, Webpack, etc.
At this point, the web skyrocketed in complexity from the days of HTML, CSS, and JavaScript when one of the complex tasks was to make rounded corners with images and cool layouts with tables. Of course, you can still build complex UI without these tools and use JavaScript alone, but you will end up abstracting your patterns and paradigms into reusable bits.
Additionally, some developers attempt to use as little JavaScript as possible; one great example of a complex UI trying that is https://sourcehut.org.
He sees the browser and javascript as a step back to technology that was developed in the 1970s.
The dom+javascript just isn't as powerful and so every attempt to improve shows some defect that a good plurality doesn't like and then they redo everything over again.
We're basing everything on a language that was originally functional but was disguised as an OOP language because some executives thought JAVA was the next big thing. We're forcing a document object model to be a human interface model.
We're stuck in this local maxima of power and functionality and all these attempts won't work because they're incremental. We need a quantum leap about what we think the human interface of the internet should be - and it shouldn't be the browser.
It is possible to make beautiful, simple frontend systems today using React and a handful of k8s microservices, just the man who does it is invisible. It is possible to keep integration cost practically free, but these men who keep it are sought with fire. It is possible to use our tools just how they were designed to be used, avoiding bad and worst patterns, but only few of us mastered our tools.
You just need to hire one engineer if you are not and engineer and you didn't walk their shoes for decade and hope for the best of luck. The Javascript and React are not strict tools at all, so they will allow a lot of people to fool you into thinking they are too good.
I'd assume that 80% of the available packages are completely unnecessary, i.e. "I need to set a cookie ... let's download this NPM package" or "I need to make two AJAX requests in order to fetch some JSON ... there are two more NPM packages"
I'm writing happily spaghetti code, use PHP, SQLite, Vanilla JS, HTML5, server-send-events, cron jobs and bash scripts to create fast and useful web applications.
Last note from today: I saw a tutorial on YouTube how to auto-generate a .m3u playlist for a folder containing hundreds of MP3. It involved of course downloading NPM packages, create a NodeJS cli script etc.
My 3-second solution was this (built in tools coming with almost every OS)
#!/bin/bash ls -1 *.mp3 > playlist.m3u
Everybody seems to care of hardware efficiency, because it's very measurable. For example, if CPU is overloaded, an extra virtual or dedicated machine costs a lot, or a daily script works 10 hours and may result in serious troubles -- everybody gets bothered.
But if you add complexity and devs must work a month instead of 1 week on a simple task -- this passes under the radar, because devs unlike CPUs are busy 100% time always. That projects start to take longer, probably gets attention, but many just considered hiring an extra guy.
This probably lead many to consider heavy and complex projects, like Airflow, worthy -- because the costs were not considered seriously, and apart them, the selling point (configuration with some clicks, and launching a task by a click), was in a favorable false dichotomy.
Anyone who tries to avoid the complexity of the existing front-end tooling soon finds themselves reinventing many many wheels.
Also there's the whole fractal of tool chains, transpilers, frameworks, libraries and design patterns that exploded out of people manipulating DOM strings to do something to a webform and feeling yucky about it.
I'm certain any developer from that era has a story about writing tools to make their own life easier. Prototype and jQuery were popular as they abstracted a lot of the obnoxious stuff you had to do over and over again.
And the story goes on from there. The complexity is a story of trying to simplify for the developer, and then trying fix the costs of the overhead from those simplifications.
As for your second question. It's not necessary of course, but if you don't use these frameworks and tools, sooner or later (I think) you're going to be engineering a solution yourself.
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.
1. The most popular front-end frameworks (e.g. React and Angular) are created by large orgs which naturally leads to extensive codebases as they’ll need to have many use cases.
2. Every new and shiny front-end framework is good for job security since having it on a resume makes you more hireable. I suspect it’s also why some developers practically force startups to switch their front-end codebase to the next shiny framework - resume padding.
As a solo dev I wasted a few years using (and hating) these new frameworks for my Django projects because it’s what everyone was recommending.
Then it hit me when I realized that they were meant for large dedicated front-end teams to increase their productivity. If you’re a solo developer, they actually hurt your productivity.
That’s why I’m so happy with htmx. I can get my sanity back!
UIs always have been complex btw. A lot of different states, and keeping backend and frontend in sync is hard too. So many edge cases need to be considered, orders of magnitude more than in the backend. The UI is also your first line of defense against unexpected user input.
Summarized: (1) app distribution has shifted to the web, (2) UIs are complex
Honestly, it's more of the speed of design that drove the complexity. Everyone had some specific niche that they picked up and due to the volume of demand for web development there was bound to be many different approaches tried.
Eventually, that's going to mature down to a few different standards. That's already happening with web browsers, for practical purposes we have three current browser engines today, down from who knows how many.
Q2: it depends. If you think of what users need and pay for, yes, it is HUGELY inflated; if you think of the actual requirements we receive, maybe it's not that inflated -- at least part of this complexity is needed in order to build such truckload of eye candies.
It's so disheartening to see such a gigantic waste of effort. But that's the current state of our field.
So a lot was demanded of these shitty standards (HTML, CSS and JS) and in oder to push them to the max a lot of "frameworks" emerged helping you with that. First jQuery, then Knockout, ..., React, ...
> Is that complexity necessary or artificially inflated?
I'd say it's organically inflated: no one did it on purpose. Every one tries to make it simpler.
I'm a big fan of Elm, which GREATLY reduces the complexity or browser apps... for me.
And still I prefer server-side-rendered if possible (or I have to manage the state on both ends, which also increases complexity).
Web frontend work starts at a disadvantage because of the css/html/js divide. If you actually have distinct designers/authors/coders, it works as designed. If you have a small team, it doesn't. To the typical disasters that we are all used to and have probably been responsible for.
The best symptom of this, to really demonstrate, is when you don't know what tools a contributor needs other than a text editor.
To meet the requirements foisted upon them, frontend devs tend to gravitate toward tools and frameworks that allow for maximum flexibility. And greater flexibility comes with greater complexity.
If you looped in frontend devs earlier in the requirements gathering phase, you might be able to (drastically) simplify a lot of the frontend work (e.g. "if we design this UI flow slightly differently it will require way less development"), but I understand this goes against most of the software development best practices which are currently en vogue.
Personally, I’m a grumpy backend developer, I don’t like it. I’m doing a side project now where I’m trying out old school server side templates (Jinja2 in rust, compiled using Askama ) with a little JavaScript to make it so I can replace parts of the page via Ajax calls. It’s so light and so fast, I’m really enjoying it so far. Pretty much all the state is on the server.
You clicked {count} times
For web, you need to support multiple browsers and infinite number of screen sizes.
For mobile, you need to support iOS and android and multiple different OS versions and screen sizes.
You also want to minimize platform-specific code, which often causes you to roll your own way of doing things. From an engineering point of view you don’t want your code based to diverge, which would cause supportability issues and/or lengthen and complicate developing new features.
It’s basically a nightmare for any moderately successful company that doesn’t want to alienate any customers.
Imagine if TypeScript/JSX was available native in the browser requiring no transpilation step, and we dropped support for any package requiring some exotic transpilation.
You could easily step through your entire codebase first and thirty-party without battling source-maps or minified files.
Libraries that required adding a compilation step and a complex dev server would be shunned. Having this compilation step in place means it's easy to just pile on tons of functionality, import hooks, AST transformations, etc. which causes the complexity.
All that to say this: we wanted cutting edge language features, beautiful UI and didnt want the page to flash white when we did something so we stopped switching pages and handled state on the front-end. Not sure it was all worth it tbh.
2. Frontend dev is actually Blog/Video/Trend based development. Simpler tools exists but yeah.. I guess there is a market that feeds on this complexity.
• Internal/enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs.
• Eliminate mobile/web duplication. Use Jetpack Compose/Kotlin Multiplatform/Flutter/etc to bring your mobile app to desktop and keep all the frontend codebases synced.
If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places:
1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever).
2. HTML5/JS's failure to provide a components model leading to it being layered on top with npm, webpack, react, etc.
3. A desire to eliminate state-management related bugs via FP techniques.
4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations.
5. Assumption/desire that websites will work on mobile/tablets, even if a native app exists, causing a lot of work for responsive design.
6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app "frameworks". Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end.
The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.
Frontend frameworks like React are used everywhere. For real web applications like Facebook, they totally make sense. But for a lot of other projects, they don't because those projects do not have a complex UI/UX and so the framework adds more complexity than needed.
I can simulate any kind of asynchronity with the server trough websockets or boring but effective polling.
It works for me, yet all job offers I see are looking for react or whatever Devs with rails experience. It's like JavaScript totally took over.
i think the web platform is a very open platform. Sure, there are highly complex toolchains for the web, but you are not obligated to use them. If you want to, you can use vanilla JS (if at all), raw WebGL and even Wasm.
Is Javascript's complexity necessary or artificially inflated? Modern frontend development boils down to a bunch of abstractions on top of Javascript.
The reality is that most teams in the world are not huge and never will be.
Is the complexity artificially inflated? It depends on the app you want to make.
We also got faster machines that could handle the buckets of garbage average JS framework asks browser to do and internet speed that made 2MB JS blob the norm and not something you'd be fired over.
At least the app won't be married to the browser.
1. users demanding (whether unknowingly or not) better ui, quick updates
2. developers demanding “make it for me” tools
3. Companies “demanding” engineers to stand out
10 years ago, your social app didn't need to have sub-second response time worldwide while collecting literally everything about user journeys to drive engagement and serve ads, thwart DDoS via scraping or client-side crypto mining attempts, be compatible with mobile and desktop browsers, or be insanely visually appealing and deal with even bigger markup and stylesheet languages that, again, must seamlessly work on mobile and desktop. you didn't really need to have a mobile app that communicates well with frontend.
Also, consumer internet bandwidth, disks, and computers are way faster and cheaper now in the US and Europe than it used to be (and even in developing countries with the proliferation of Starlink). we have facebook machines AND PHONES running m2/a15 Apple Silicon that rivals workstation-class compute at a fraction of their CPUs TDPs. So customers will demand more because they can demand more.
Could we collectively just stayed frozen in 2013 or 2010 when life was simple and browsers weren't operating systems? sure. but clearly the push for more things is working as every tech company is worth more than they used to be back then, even after accounting for today's climate.
TL;DR: capitalism?
1. the mainstream adoption of AJAX
2. node + node development community (top 5% of node/npm contributors - also Google see 4.)
3. agencies trying to sell over-engineered BS to their clients
4. Chrome/Google
5. influx of non-CS/nerds into FED (commoditization of knowledge, process and perceptions.)
Look at Vite & Rome for example.
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!
100% inflated and ego-based. How do I know? After years of struggling to understand the increasingly complex front-end space, I decided to build my own full-stack framework [1] to check my own opinions weren't left-field.
Here's the harsh truth: it doesn't need to be as complex as it's made out to be. Not even close. I can speculate as to why (ego, job security, etc) but ultimately the punchline is that all of the APIs and a lot of the code under the hood are pointless Rube Goldberg machines.
People don't want to hear that because they're invested emotionally in a lot of these tools, but from direct experience doing multi-year research and building of a framework, it's all a scam.