Early react team member here. The popular react/webpack/npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions.
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.
For me the reason for the explosion in complexity in both frontend and backend comes down to package managers on all platforms getting way better with transitive dependencies and lowering the cost of adding those dependencies. Developers used to be wary of bringing in another dependency just in case it created some conflict, but ecosystems that near-perfectly encapsulate transitive dependencies have gradually done away with that healthy wariness, with a combinatorial explosion in packages as a consequence.
Create-react-app installs 1500 packages to show a hello world page, and it is quite sane in its choice of dependencies. For me this is a symptom of the whole npm ecosystem being diseased with dependicitis.
> Ironically, I think more dependencies are actually better, because it means they are smaller. "Do one thing well".
I could believe this if I thought that having 1500 dependencies led to less code overall, but the size of my node_modules folder shows that assumption to be flawed.
The other problem with this argument is that each dependency you add is another set of developers that you are depending on. It's another group of people who could suddenly pull a left pad or worse, and it's another group of people who you have to trust to have written secure code. The fewer dependencies I have, the smaller my chances of being exploited because of a people problem.
> Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example
That's certainly the trend. At my org, we "partnered" with AWS to help us figure out what the tech stack should look like. Sure enough, everything should be in an SQS queue, triggered off S3 running in AWS Step that's triggered through SNS notifications. All this requires countless lambdas which means deployments can last hours.
It's a mess to debug (meaning you can't), track logs, track status, etc.. Does all that "work"? It can, sometimes. Does it scale? For sure, theoretically, if you can get it all running.
In my team we use a trick to just run everything in AWS Batch containers, it's much easier, deploys quickly, and we can run the whole stack locally and debug it.
I worked at a company that did the same, and got the same answer. I hated that technical setup. Lambdas everywhere, Queues everywhere, microservices everywhere Exactly as you can said it was a huge pain to debug, and on top of that searching for code became a huge pain as it became split across so many different git repos, teams, and docs. And when you throw IAM on top of it all..... I am not a fan.
Makes sense that AWS would recommend these stacks (they are probably compliant with their Well Architected Framework), though the idea is to recommend something that can scale de facto infinitely with minimal SMEs required to run it all.
I agree that aiming for the simplest service your team can maintain is the best approach, scaling up as needed.
About #1 there's Win32 API, MFC, WinForms, GTK, Qt, Swing and all do UI and thousands of applications are built with far more state and complex UIs than a normal SaaS, price comparison portal or a booking website ever could imagine - but none of those technologies are ascomplex, as bloated and as fragile as modern frontend stack has become.
Second - Backend complexity, Kubernetes isn't Backend precisely, async Queues are unavoidable but these Microservices are basically an anti pattern driven by greed to land the next Job and hence insistence on using different programming languages per team/indivual etc. Now a cottage industry in it's own right with it's own self proclaimed scholars whereas it is just and exactly the domain of distributed system already.
If that constraint of per team programming language of choice is removed or languages interoperate with zero configuration, 98% of the companies need just well maintained internal libraries.
Disagree on the first reason - I don't think actual application code and logic has anything to do with frontend overcomplexity.
My issue, and the reason I moved away from JS altogether and to Flutter/dart, is the massive amounts of redundant and complex tooling, choices, and concepts.
Yes I'm mixing categories in the list above, but the point I'm trying to make is that with something like Flutter/Dart, there's only Flutter/Dart.
Even if there's some really cool new JS library that handles all of my application-centric concerns (namely, layout animations and good handling of shared types across n different apps/packages/services), I'll never use a JS library again because it will simply never be enough. I'm not going to use these band-aids anymore.
"It was popularized because the Instagram web team used it…" Twenty-five-year front end dev here, I don't recall anyone asking or caring what Instagram was using. Like, obviously projects of that scale make influential suggestions, but when Instagram says "we like This" and AirBnB says "we like That" then you have a couple strong condidates to evaluate.
IMO, the answer is more general: the modern web front-end evolved from lots of different directions. Instead of having one prescribed Correct way (a la AppKit, UIKit, Android Frontend Frameworks, etc.). If Netscape somehow still existed and maintained their peak of influence, things would be different.
/me remembers MFC/QT/BCGsoft and C++ codebase and gently smiles on thought that maybe the issue are everywhere else except the UI complexity.
We are where we are, but it is interesting that GUI libraries from 20 years back are still running circles around latest and the greatest UI web front-end, even if it is also client rendered.
Maybe, just maybe, we should search for an issue somewhere else?
Django, bootstrap and a sprinkling of jQuery works really well and results in simple code that can be maintained by a single dev. Bootstrap is only 11 years old. jQuery is 15 years old. Django is 18 years old.
jQuery is used by 94% of the websites that use JavaScript.
None of those are gui toolkits, though. At best, you are pointing to html working rather well at it. Though, that is more force of will from developers, as html was specifically not a front end toolkit at the outset.
There’s another discussion going on about how the older layers of Windows you dig into, the more useful the UI gets, perhaps that’s the narrative they’re thinking of: https://news.ycombinator.com/item?id=34216619
I’m inclined to agree, older UI toolkits could make plenty productive UIs. But they aren’t good at following yearly evolving design fads, and webpages tend to lean heavily toward marketing and appearances over being more utilitarian.
Older toolkits were great at single team creations. This, interestingly, did mean the person making it knew exactly how to use test it.
I question whether the toolkits were actually better, or we just had fewer things to use test? Certainly fewer form factors. Granted, the decision to try and have a single code base for many different resolutions and such is, of course, questionable.
Edit: directly to the point, is it the old toolkits that made better tools? Are those same toolkits used today? Pointing at older tools does not show that the toolkits were better.
Almost all of the apps bundled with macOS are written in Cocoa (some are written in Cocoa Touch, which is itself a nearly 15-year-old framework). And a great deal of excellent third-party apps -- off the top of my head, Transmit, Pixelmator, Day One, the Omni Group apps.
Mail has always felt like garbage to me. Notes, I will have to give a try again. Though, really, the entire "office suites" that everyone makes always feels off to me. I will full cede that that is just preference.
Safari feels off, as well. But I'm pretty firmly in camp firefox.
When I think bundled apps, I think of their notepad equivalent. The finder. The calculator. And... that is about it. I remember trying to make a script once, and that script editor left me very very lost.
There's always the option of a native client rather than a web-based client. A good example from days gone by is Evernote. If you've only started using it recently you might not know this, but the client used to be really good.
I haven't used QT or BCGSoft, but I for one have very negative memories of MFC. Sure the performance was much better than anything you get on the web, but the UIs were far less complex, didn't handle window resizing well/at all, handled text overflow poorly, and had much less aggressive design requirements than we have today. There was also a ton of imperative glue code and lots of hard-to-read generated code.
Please DO open Word 97 (and this is 26 years old UI) and compare it with the best done web UI you are aware of, regardless of framework, as long it is not QT compiled into webasm (as this is the only thing on web that comes close).
Now why is that, I don't know. But I can tell you what I can see as a user. Web frameworks/developers/name_your_poison are doing a really, really bad job regarding UI.
My understanding is that none of the core Microsoft apps like Office were built on MFC. In MFC projects I worked on, generally the simple stuff was built with MFC and anything more complex was built with the win32 API.
Actually MFC uses windows api, but this does not change anything, it is still 1997 API. And we are in year 2023 with worse UI, i would expect it to be in reverse.
Further on the zirp idea, a lot of the explosion can be seen to correlate really well with team sizes. This gets into a feedback loop where you need bigger teams, which in turn means you will benefit more from segmented code. Which means you need more teams.
Not shockingly, the answer isn't a simple use fewer people. Rather, the amount of complexity in a codebase will vary based on budget and organization size. That is, there is no correct answer intrinsic to the code.
zero interest rate policy, which basically means central banks do stuff to keep interbank interest rates very low (close to zero in the US, and it was even negative in the EU)
>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.
Ok, reasonable, but other frontend Ui toolkits (eg. Vue, Svelte before Sveltekit, etc.) seem to be able to handle this without going "enterprise" levels of complication.
>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)
This isn't a counterpoint, it is just pointing out that, well everything is getting more complicated. (more on that in a sec)
>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.
Ok, this is more to the point and gets to the real crux of the issue, but I don't think it goes all the way.
Every framework that has ever been adopted widely has been later complicated more and more to make it "enterprise-y".
Look at some early JavaScript (used to make webpage counters and fancy menus) and look at some modern Typescript, which is almost indistinguishable from enterprise Java and used as a basis for SaaS startups.
As soon as "professionals" get involved, it starts getting complicated. Every framework is susceptible to this if there is any amount of adoption.
Look at my beloved original Svelte. Now go look at the absolute shit-show that is the latest Sveltekit! (granted it is still better than the alternatives!)
To your second item above, look at how relativity easy it was to monitor or restart some monolithic projects back in the day with some simple scripts, email, and cron jobs, now it is, as you say, a "morass of kubernetes configuration, needless microservices and overuse of async queues". Literally make-work for the sake of itself in many cases!
Why?
It worked before, why is this necessary? It is the "enterprization" of everything and I agree with your third point that a big component of this is content marketing.
But at the end of the day it is more about the concept of "feeling professional". I mean, if you can teach someone how to program in JS in a couple of afternoons, how can you seriously justify $150k salaries and 3 levels of middle and project management to oversee such a thing?
The original canonical edition of this was JAVA. It was amazing seeing it go from where it started to the, almost satirical, levels of "enterprization" today. The modern version of this is JavaScript.
In both cases complication was added to make it more "serious" not necessarily to make it any better.
Every decision is a trade-off. If you call TypeScript complicated, what do you call maintaining a 1000+ component-based web app without types? Please try to understand that every decision is a trade-off. Also, all the major frameworks default to non-TypeScript documentation, so nothing is getting more complicated.
> Ok, reasonable, but other frontend Ui toolkits (eg. Vue, Svelte before Sveltekit, etc.) seem to be able to handle this without going "enterprise" levels of complication.
I've used Vue (2.0) and React extensively. I find them to be pretty equal in terms of complexity on reasonably large projects.
For all intents are purposes they are roughly the same. Same ideology, same goal, same developer workflow. Vue has a bit more syntactic sugar which takes away most of the complexity of React (unnecessary rerenders, useEffect hook that has its own book and still no one understands it) at the cost of somewhat leaky abstractions. Vue 3 is a huge step ahead by the way.
Everything will get complicated on large projects. The problem, especially the problem pointed out by GP, is that there is a lot of over-complication in smaller projects ... which is most projects!
By "ZIRP", did you mean "Zero interest-rate policy", "Zurich Integrative Rodent Physiology" or "Zimbabwe Idai Recovery Project" (top 3 results on DuckDuckGo)?
Async queues are far from meaningless. They are the basis of distributed, resumanble/retryable computation.
If you can't see the advantage of keeping your processors fed with work as close to 100% of the time as humanly possible, I got nothing for ya. Hell, AWS is basically popular because you can have novice programmers toss up synchronously programmed lambdas, and scale out the underlying infrastructure with Amazon magic, which in a non-AWS system translates to "define queue and message format which will be servicing producer/consumer workers, deploy and start dumping messages in/popping messages out of said queue; scale to taste.
It takes a while to wrap your head around async, but once you get there, you're building with one of the most powerful computing primitives I've yet to come across.
It's just unfortunate that the language and requisite mental model around it is, in my experience, a bit difficult to intuitively reach.
I didn’t say they were meaningless, just that they are often overused and can make systems needlessly more complex.
How many microservices architectures with dependent webs of async queues emulating distributed transaction semantics could be replaced by one big rdbms? I think a lot!
My favorite is when a new project thinks it needs this on day one. I'm willing to place money that most new projects will struggle to saturate a single computer. Much less a distributed infrastructure. (yes, I'm well aware there are some cases. But even most fang projects are doing relatively little work, all told.)
Chime famously (but maybe not externally) ran almost all infra off two co-located beefy servers all the way up to their millionth customer. Maybe that is dumb, but we never had any downtime or slowness that was a result of work we did. The APIs we would rely on sometimes though did.
Another reason there is so much complexity is that the computer speed allows it. If you are constrained by processing power you will chose a more simple architecture... until you start optimizing. A lot on unnecessary complexity is premature optimizations. That "web scale" service you are building with "serverless" and other cloud services will likely run fine on a 1$/moth VPS - but who would like to manage such a small budget :P
It's just so ironic to see this monstrous amount of complexity that is only made tolerable by the massively overpowered hardware beneath it, and which, reduces the throughput of said hardware enough that said complexity becomes necessary.
You aren't wrong, but I suspect there was more unnecessary complexity in early computers then you'd allow. Is why don't ridiculous demo scene stuff is still created today. :)
It's artificially inflated and I'm seeing this in almost all areas, not just frontend.
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?
One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.
Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.
Exactly, those patterns may be good if you know exactly what you're doing.
But in all the other cases, they just make everything more complicated and harder to understand.
I've once worked with a messy codebase, it was written in a very "naive" way, but that was also the strength of that code. Every view was in one file, every action was just one method, so you exactly knew what code was executed when. We tried to refactor it, but it became complicated really quickly (the domain was really complex), so we decided to just adopt to the style. We only split up components that became to big into smaller components, sometimes decoupled things a bit, but most of the time just kept all the logic.
And this product is successfully in use for over a decade now.
I find that in larger GUI apps the best thing to have is a layered architecture where visual and non-visual parts are separated globally, not on a view-by-view basis. One advantage of this is that you can slice off your visual part and have something like a "headless browser" variant of your app. Among other things this is good for writing integration tests if you also have a backend. Same trick is impossible or very difficult to do with MVVM.
> visual and non-visual parts are separated globally, not on a view-by-view basis
Yes, yes, and YES!
This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell.
I would implement my model, TDD-style, put minimal views on top, possible add a view-model here and there if there was some display-specific logic that was complex enough to warrant more extensive testing, voilà.
It was only recently, partly when working with some teams that were doing modularity for modularity's sake (and MVVM for MVVM's sake), and partly when writing down Blackbird[1] that I really noticed the per-view thing.
Don't do that.
>"headless browser" variant of your app
Exactly. Do this.
The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side.
> Same trick is impossible or very difficult to do with MVVM.
Well, it's impossible with the misapplication of MVVM that is common today. A view model is a perfectly fine addition if you have some complex but fairly presentation-specific logic. And you put that in a testable model that is fairly tied to one view.
Instead, people have used MVVM to double down on their view-centric misunderstanding of MVC, with anemic models that know just enough to service a specific view.
Meaning any kind of cross-app logic can't go in the model. Meaning it is going to go into the view parts (or rather: the misnamed and misapplied controllers). Which is exactly where it has absolutely no business whatsoever being.
> The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on > top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side.
This is exactly what I did with all projects I've worked on. It helped that I had to target both, iOS and macOS where sharing "business logic" was crucial, so you were kinda "forced" to think about that.
To put it simply, there is one question I'm asking myself, can I delete UI and then rewrite it from scratch without updating non UIView/NSView code (just calling MyClasses i.e. my APIs)? Let's just say, if I have to write NSSortDescriptor again, that means there is an architectural issue with my code, which has to be fixed.
Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?
Please forgive the lack of background of this next question, but does this mean you do not support BFF pattern?
Have you heard of Dubray's SAM (State-Actor-Model) approach?
Curious about your replies and thank-you for your time.
> a low-level "engine" or "kernel" [..] and the view be any of a React Native mobile app, desktop app, or convenience web API
Yes, exactly that. Not my idea, of course. See for example Hexagonal Architecture. Or good old NeXT Enterprise Objects Framework, later extended by WebObjects.
> Have you heard of Dubray's SAM
No I hadn't, thanks for the tip!
He identifies one of the core problems with how MVC is incorrectly applied:
"The core issue here is [that in] traditional MVC, the action (controller) would call an update method on the model and upon success (or error) decide how to update the view. "
However, he incorrectly claims that this is "traditional MVC". It is not. In fact, traditional MVC clearly forbids this, as it states that the View updates itself from the model. The View is active, you don't push data to the view.
Model -> View communication is a notification. That's it. (This is also how it is implemented in Smalltalk MVC, which is the prototypical and archetypical MVC implementation).
Thank-you for your reply. I had another question about models and the database.
It feels to me that the database tends to be more stable over time than the application: frameworks, design approach, and architectures come and go, but tables, stored procs, and views have always been there.
That said, supposing we were to start with the data model and many business rules expressed in the database first, would you reach for GraphQL to help the app manage the data it needs, or acquiesce custom db objects to provide the required data?
With SAM, I thought there would be a way to avoid BFF, while conforming to a TLA+-ish way of enforcing (the model's valid) states at all times.
I know I am handwaving a lot of ideas. Just wanted to get your input on the backend side of things.
> Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?
Let me present: Kotlin Multiplatform Mobile[0] (or KMM, a real mouthful I'll grant you). Something I'm very excited about, because you could do exactly that. Seems like an interesting thing to keep an eye on.
Sounds neat, thank-you. Have you heard of Java Cuba/Jmix?
From my limited, surface understanding, that is what KMM reminds me of: a way to define UI in Java, which means the entire stack could be in a single language (or mix of JVM languages).
MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane.
But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours.
The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
What's important to realise is that the elements in MVC are roles not entities.
So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role.
Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.
I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem:
I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily.
Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
FWIW, Redux literally _is_ a pub-sub/observer pattern implementation :) And the Redux core library _is_ extremely small.
But, that led to the community building hundreds of addon libraries for the same sets of use cases, which is what led us to build our official Redux Toolkit package to simplify standard Redux usage patterns.
"State management is complex, so we used a framework to make things easier."
"Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity."
Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)
Ah I beg your pardon. I read the comment in completely the wrong tone of voice.
To me it seemed like the comment was attacking its parent for investigating state management frameworks in the first place - when it in fact called out "no framework" as a valid alternative to any number of frameworks.
Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.
Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.
The problem has always been immutable state. JavaScript doesn’t have ergonomic constructs to handle immutable state very well. IMO, immutability shouldn’t even be enforced by the view rendering layer. Immutability in React is enforced to cater to the needs of React’s implementation, and not the needs of the developer. It should be a choice by the developer whether or not they store their state in immutable data structures. Hooks are marketed as a means to make React into more of a framework, but the reality is that they are an attempt to smooth over the problems surrounding immutable state. Solid js also doesn’t solve this problem, even if it has more ergonomic ways of dealing with the problem.
Digging deeper, it seems to me that attempting to subvert the standard behaviour of the DOM will always produce a leaky abstraction, and it negates the benefits of working on a standardised platform.
I'll definitely agree that Redux _has_ been overused.
But it's also worth understanding _why_ Redux was created in the first place and why it got so popular.
As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time.
This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization.
The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time.
The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].)
After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup.
So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2].
Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today.
> This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization.
Can someone explain this to me please? How is it possible, that Facebook, did not have a plan from the beginning for a larger global state, even though their own app is huge? How did they solve it in Facebook in the first place? or did they started using React for themselves AFTER solving the global state problem somehow?
I didn't look into Redux for a while, but RTK looks really good. That's a meaningful evolution.
I never did really complex frontend applications, but once I used React Query or SWR most of the needs for global state were gone. And so the need for Redux.
This. While engaging in flame wars about React I have noticed that all of them start with a peculiar definition of done that, lo and behold, necessitates not only React but whatever feature if the month they are busy ductaping to it.
What we need is an honest conversation about what USERS think about spa apps, flat design, etc while holding very obviously interested parties from skewing the narratiwe.
I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants.
Those kinda features are hard without a pretty complex frontend.
Not saying those things are always necessary, or that people don’t add bells and whistles where they aren’t wanted.
> I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync
I'm inclined to disagree.
One of the most successful web apps I know is a CGI (not FastCGI) app written in Pascal and containing some 30-yo code.
100% of users I met are happy but they don't even know why. "It's good", they say.
I believe their underlying reasons are:
- the app is extremely fast. Full screen reloads are not a matter anymore with broadband internet.
- client side code is light enough to run well in crappy, old windows-based PCs running internet explorer
- lots of reports and features. The vendor's team has time to develop them since they are not busy trying to centralize stuff, fighting w/ CSS properties and other stupidities.
This! I often build Django apps without any javascript and it's so light weight that the pages render instantly. If there is some interactivity needed then I toss in htmx where needed.
The problem is that most of these front end apps end up calling out to the server all the time. So you end up with essentially the same latency of SSR with the complexity of an application split across a HTTP boundary.
I do think there's a place for real time web UIs in business apps. I spent a chunk of my career replacing green screens with web UIs. Usually ended up slowing people down because they lost the ability to chain commands.
With green screens they'd know that the navigation to change and address was like 3, 2, down, down, enter. So they'd get there in a split second. With a web UI they'd have to wait for the screen to render in between each action. Ultimately it's much slower.
You see it with the death of paged result views, and their replacement with "Yet Another Query Lang/Search Widget". Sometimes, to a User, that God's eye paginated view of a dataset is a lifesaver, because over time you start learning it's shape.
You learn datapoint X is on page 5, and as time goes on, you can further optimize, and you gain a visceral, kinesthetic sense for the dataset/program.
You have to use it though; and you have to document it. People aren't going to just magically intuit how your obtuse arse search widget works. They don't know your data model.
Even worse, they don't know your company calls something the industry now calls "Fred" "Bob", because "Bob" was the standard before "Fred", but you're a late adopter for reasons.
Or worse, that you labelled a field "Barney" in the UI, but in your search widget query, it has to be dealt with as BRNE. Or even worse: you enter "Fred=fredvalue AND Barney=BRNEvalue", yet you end up finding out someone had a fundamental misunderstanding down the line, and it turns out fredvalue is mapping to BRNE on the backend, and BRNEvalue is mapping to Fred.
These are all examples of actual bugs I've had to squash in the last 2 and a half years; and which only get worse and worse as time and system integrations move on, because they'll tend to echo out of your system under development into other auxilliary systems like your call center IVR or CRM, or customer service tool. Now you have three disparate systems to get fixes/work scheduled for, and which all need to be done in lockstep to roll out coherently across an org.
I've had to sit with Users, watching them, learning the desire paths, then sit down and have a long talk with a designer to explain the heuristics they weren't taking into account given the people who were actually using the thing.
Compared to snappy interfaces that your hands can master, and to be honest, it feels like a lot of web app is just regression, and an excuse to justify enploying someone to wholesale change the aesthetics of the interface no matter how much of a detriment that in the end becomes to the functionality of the tool.
You sure? Because all I hear on daily basis is "please don't make me learn new shit" and "get these annoying ads out of the way". Web is so "rich" these days that disabling Adblock should come with epilepsy warning.
> 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.
On one hand we are complaining about app store monopolies, and on the other hand the enormously rich web ecosystem with plenty of choice and enormous freedom is also too fragmented/bloated? What is the desired state here?
PS. Needless complexity === I don't understand it so it's useless?
"Where is this coming from? Is it because we want our work to look important?"
I am intimately convinced it could play a role, at two layers. First, at the framework layer itself: the plethora of propositions seems symptomatic of our approach to dealing with things we don't like. When confronted to the choice of walking the extra mile to improve and contribute to an existing language/framework, or building your own new thing that focuses on solving your own problem, my guess is that the more senior architects (esp. those working at licorns or GAFAMs) will choose the latter option, thus resulting in an increased offer. Also, let's not forget, being the author of a successful language or framework sounds cool.
Second, at the user layer (architect at random corp): this individual is increasingly convinced that working with the latest silicon valley approved framework will work wonders on her/his resume.
I am confronted to new software architectures on a weekly basis as a result of my job and the choices of framework/language X as opposed to Y often follows a common pattern: some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end.
If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)
> some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)
I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server.
It's clean, it works, it's performant, it's logical and it's maintainable.
And as long as I'm still here, it's staying that way :)
(note: I agree with your approach, just making a point)
> that uses the latest Angular
But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is.
Speaking just for Angular, things seem to have settled down a lot. The applicaton was originally created under 13 and has been migrated to 14 and just recently to 15.
Those upgrades were quick and painless. Some new features come with each update, but aren't required to implement them and the existing code runs fine under v15.
It's very easy to see why this happens. Because nobody actually knows what they're doing.
There is no logical/mathematical theory around program design. We have no idea if we're improving in optimization, staying the same or even going backwards.
For the shortest distance between two points, we have a theory that defines the best distance: A line. That's an easy target to hit. For the best way to design and organize our programs... there is no theory. It's all made up and opinionated. Without a theory we can never truly know.
Thus we are doomed to forever move in a flat circle creating framework after framework and endlessly having progress move horizontally while wasting effort creating isomorphic patterns without ever knowing if the new pattern is better or worse.
Until the day we have a mathematical theory around program organization that can say Design A is 2.3 times more optimal then Design B. Then on that day... this madness will stop.
But until that day we're all stuck in an endless limbo mouse wheel mind fuck. I look at front end and I suspect that out of all software technologies, front end is one of the few fields that is actually moving backwards. I'd estimate 0.01x less optimal every year then I predict at a delta of 0.5x less optimal from an inflection point it starts to oscillate back towards the natural equilibrium again. Then when it hits equilibrium it will oscillate in the opposite direction again. Endless.
Python is likely one of the most stable technologies imo. It's definitely not remotely close to the MOST optimal state but it's nested too comfortably in a local optima and it will likely be stuck there forever.
It's all over techcomms too: GML / Scribe aaalllllll the way to DocBook, then DITA and S1000D. And people run to adopt those thick specs, in spite of there being zero supporting data that they in any way reduce cost . . or do anything useful[1] at all. Watch that adjective "useful".
I see it as Scientist/Technician vs Prophet/Priest.
These two pairs are solutions to a problem: the world isn't doing what I say. They can both work, or at least do better than random. The difference is that the former can explain why, and the latter can't.
The cool thing about not explaining? It makes the Prophet the only person who can evaluate the work. They have vision into the solution, and it appears only to them.
The bad thing about Prophets? If you've quantified the solution, then it can be falsified and replicated.
Wait a second . . how hard can it be to quantify a solution? It's actually really hard - particularly in things like natural language (tech comms) and visual arts (yes, front end is viz art, FIGHT ME :D). Some industries have blown up their prophets to such towering heights that they will set fire to clients and money and any other quantitative measure of value . . all in search of that One Truth (content re-use and so-called "single sourcing", I am looking at you, but I'm not even going to tease the elephant in the room that is AS9100)
People in insecure positions will always seek to turn their Technician position into a Priest position, even if they need to find some Prophet to cling to. And eventually, they might get a chance to be a Prophet too. It's like an MLM for your mind.
[1] "Structured content is the future!" Oh, is it now? How's that been working out for you last checks watch twenty years? "Hierarchical organizations are required for finding stuff!" Do you know, I think I remember the Internet Outline google publishes ever second /s. Ah, "useful".
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.
I agree with all of this. We are building web 'applications' now, not just websites. Users expect interactivity i.e. state management, animations, modals, dialog boxes... We have moved all of the UI patterns from the operating system into the browser, for better or for worse (probably worse). We have made front-end developers today what used to be Winforms devs, JavaFX/Swing devs, Cocoa devs... but without the basic OS UI frameworks they could build on top of before. Never mind the limitations front-end devs still have to deal with- like being asked to theme a <select> god help you!
I think it is a problem that the frameworks smooth over many issues around working with web standards, which means that less successful patterns emerge around working directly with the DOM.
I suspect that amongst all of the patterns, frameworks, and learnings gained from the Nodejs era of web dev, there exists a far more cohesive and scalable way to build front-end app directly on web standards, but this mode of development can’t compete with the shear number of developers working on solutions layers above the standard platform. These solutions have an allure because they have more elegant workflows for very immediate problems (I need to update the DOM based on this state change) but the unstandardised nature of these solutions don’t really help the ecosystem advance to its potential.
Exactly. Things are just complex, and who wants to wire up a form library from scratch? All of the tools out there now (assuming you know which to choose) have made our lives easier, and (vastly) less bug ridden, then ever before. It's hard to know what to choose, but the domain itself is necessarily complicated.
I misspoke, meant we can't use frameworks. We have Webpack setup, but the HTML is currently Django templates, and the project right now has too tight a deadline to reshape the frontend into something that more conventional frontend frameworks expect.
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
> 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
The people who complain about current front-end complexity are almost always back-end devs or people who don't touch front-end. However, almost every veteran dev who has developed UIs across many media and environments repeats your point.
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.
I think this is the fundamental problem. The data structures you work with are different from the data structures displayed. Almost every framework out there is there to solve this problem in a different way.
Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.
Can confirm. I love winforms. Convinced that even the most hardcore Unix devs are missing out on the sheer joy of being able to double-click on a form you just dropped into an editor and seeing it automatically add an event handler for the common case of whatever type of UI component it is. (Buttons are onclick, inputs are ontextchange, etc.)
I do not think that you would be able to do ActiveX, COM, OLE, MFC, C++ after 2 weeks of bootcamp. Yes, Delphi and Visual Basic simplified many of it but there were still many challenges to develop and ship your software. Just shipping alone and dealing with installers was a challenge by itself. Now compare it with a browser tab and a single click that deploys your code across the globe so it event can run in space on ISS.
But here's the thing: you didn't needed COM or ActiveX or MFC in many cases. You could literally wire up and build an up pretty effortlessly. With webdev today we jump directly to very complicated things when 90% of the time they are not needed.
For simple things we still have Excel and Ms Access where people continue to build simple UIs for personal use. At my previous job, our CFO build own framework (Excel) to manage and automate financial reports (which makes him a full-stack developer based on industry standards)
I guess the frustration comes from the fact that historically Web started as a set of static HTML files to create/publish documents and we inertially compare todays Web with it but we if stop comparing apples with oranges than it becomes apparent that:
1. It's never been simpler to create and publish web content
2. It's never been simpler to build/ship/and distribute software
Complexity arises when people (given many options) pick wrong tool for a job.
Picking the wrong tool but also cargo cults. If everyone is a X-developer and is using Y and you are working in X you start to wonder if you should be using Y, right?
My 15 year old Delphi program which runs the whole factory still hasnt been replaced, despite the company and IT staff growing by 10x. Its now taken 4 years, 3 IT Managers and 2 consulting firms to decide Delphi is archaic and it will all be re-written using "cloud and modern frameworks". They have given the team of 3 developers 2 years to do it. Considering they have not managed to keep a developer or IT Manager for longer than 18 months, I would say good luck. I really dont know how anyone gets anything done these days.
The drag and drop your parent comment mentions is used for creating the WinForms application, not for interacting with it.
Creating the application is still done on a Desktop PC.
Correct, but the form itself was always a fixed layout, designed for desktop, not a responsive layout where things changed based on the size of the user's display and the input methods available to them
The browser is powerful enough now that one could replicate this if one wanted to. I don’t think it’s the pinnacle of software development, but it had some advantages.
The difference is that winforms basically had one way to do everything which expedited development because it skipped all of the infinite number of stupid small decisions and libraries that must be cobbled together in a typical SPA.
Win32 could do it all. And in windows there was often a different way to handle things like video across each major OS version. Yet still, I feel it was simpler! Crazy!!
I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps. I still use WinForms professionally to this day. Productivity is absurdly high. The number of concerns to worry about is low. The framework has been stable for 20 years and I know all of its quirks, which never change. Fads are ignored. We can zip around with amazing speed.
On the other hand, our apps are:
- Ugly looking
- Dated looking (this is different than ugly, but our apps are both)
- Full of UI jank (too many WinForms controls take their sweet time painting on the UI thread)
- Non-server-based
- Non-cross-platform
- Non-sandboxed
- Installed from downloaded file that gives scary warnings in your browser when you try to open it
These downsides hint at some of the reasons why I think web-based development is necessarily more involved than for Windows apps.
A large part of the reason people ignore your model for business use, where the target platform is locked down to a single target, is the perceived need to run their software on any given piece of hardware.
That's a question that really aught to be answered. If the business application only requires Windows PCs as a target your design wins out despite the perceived shortcomings.
>I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps.
I agree that the developer-facing usability of a good desktop GUI toolkit runs circles around whatever webdev is these days, but the barrier to entry for a completely new programmer is certainly a lot higher than HTML.
Most of them can be solved by using a more modern but similar toolkit like Jetpack Compose, JavaFX etc. Then you have distribution, but to get rid of the scary warnings just requires you buy signing certificates. Distribution is still a pain after that, but that's why I built Conveyor, to simplify it.
Going further would require remixing bits of Chromium to create a browser-like thing with a sandbox, but which is much less opinionated about what runs inside of it.
Problem is, for there to be a market requires that devs (or someone) pays for it. How much would you pay to be able to not write a web app?
A couple of months ago I had to develop a whole CRUD GUI in, wait for it...Excel, using VBA.
It was very much like designing desktop programs some 20 years ago using WinForms, which was actually a piece of cake using the designer tools that came with Visual Studio etc.
It's shameful that creating programs in Excel is such a smooth ride compared to even the most trivial web app. But of course, the web app must be compatible with a billion of other things, compared to Excel and VBA.
IMO it's mainly Google and Chrome/ChromeOS trying desperately to keep people away from the competing Windows and Apple ecosystems, which requires that the browser do essentially anything a stand-alone program could do. This doesn't explain why there are a million JS frameworks, but it does explain why the browser has ballooned in features and complexity over the years.
>This doesn't explain why there are a million JS frameworks
Not sure if this is a valid answer, but I would assume that both Microsoft and Apple provided decent and easy to use frameworks to build applications on their operating system. This setup a particular amount of vendor lock in, the library is already there and doesn't need downloaded/installed making it easy on the end user.
On the other hand, frameworks were not provided by the browser manufactures initially. Also, everything is downloaded so 'include foo.js' is just as easy as 'include bar.js' opening up a vast ecosystem of frameworks.
> Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc.
If frontends didn't use the "OS" capabilities of the browser, how would one build a multi-user real-time text editing app like Google Docs?
Edit (and off topic): Writing this comment gave me flashbacks of using Mapquest online for driving directions before smartphones. You had to print the directions out and bring them to your car on a piece of paper. It worked though!
I think it's something analogous to Jevons' Paradox.
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.
That's it. It's induced demand. Build roads with more capacity, and more cars will appear to use them. Build frameworks with more capabilities, and more tickets will appear to use them.
Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn't really care/understand that their internal crud app for editing invoices wouldn't need that complexity.
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...
I disagree with this. Almost all front-end projects I've worked on in the last 10 years or so have had some requirement that made pulling in react a better choice than trying to push back on business and/or get buy in to do everything server side. Providing users the kind of tighter feedback loops for their workflows is only possible with JavaScript.
And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end development, and I blame all the over-engineered frameworks.
> And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load
This is not why half the internet is borderline unusable. React will happily do a full page render in under a second (including network load time). The primary reasons for that are:
1. People writing code that does many network requests in series. 5-10 seems to be not uncommon for many apps.
2. Adverts and as SDKs.
The app I inherited at my last job was a huge 2MB bundle (due to including both the firebase SDK and a large charting library), which I assumed was the cause of the slowness (it was taking ~3-4 seconds to load). But it turned out that was serial network requests that were slowing it down. The app is still 2MB (we made good progress on removing firebase, but hadn't quite gotten there when I left) but it now loads in around a second.
You don't need to do everything on the server side. You can use Svelte or Solid.JS and have the same DevX as a framework, while compiling down to lean and blazing fast JS code on the client.
It's a mix of this FOMO and a lot of people not knowing how to wire up AJAX well. I've seen entire teams reach for react just because there is a portion of the page where some AJAX was required and react is the only way this new crop of devs knows how to do DOM stuff with server side effects.
React today, Angular before that, JQuery, Knockout, All the gloriously bloated .net AJAX controls from Webforms, etc. There's been ways to wrap AJAX calls pretty much since XMLHttpRequest was implemented.
I'd argue "Wiring it up well" is a task better suited for these vetted and highly used libraries than rolling your own code in vanilla JS.
Difference being jQuery was well suited and really necessary back in the day. Browser incompatibility meant that pretty much any non-trivial DOM operation needed to be wrapped by jQuery to be done safetly. Now every browser is just chrome except for firefox and firefox and chrome have played nicely standards wise for nearly a decade now.
Vanilla JS being viable on the frontend without jQuery or some wrapper probably didn't happen until HTML 5 so around 2014 by my reckoning.
The GP is saying that people use react as an ajax abstraction library.
It does make some sense. People used to use jquery exactly that way, and react provides an even better interface for ajax. I wouldn't be surprised if most of the usage of react is there just because people don't want to query their servers by hand.
> react provides an even better interface for ajax
how does react provide an interface for ajax?
react does literally no calls at all...
I feel like 50% of the people complaining in this thread have never touched react or their last interaction with frontend code was jquery 15 years ago and they're still carrying those learned paradigms around and applying them to every new framework/ frontend lib they come across
Just want to highlight something from my original post:
> react is the only way this new crop of devs knows how to do DOM stuff with server side effects
DOM stuff with server side effects, they think they need react to do dynamic DOM stuff, especially if that dynamic DOM stuff affects server side state. So this isn't just about AJAX
> Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance.
Yes. Backend engineering is completely immune to hype and increased complexity.
laughs into a cloud of micro services
But, more seriously, both front and backend architecture has increased in complexity. I think it’s more than condescending to say it’s because front end engineers base their decisions solely on website aesthetics.
A lot has to do with the fact that for a long time JavaScript has been the only game in town, and engineers have had to work hard within the constraints to afford the same programmer ergonomics available within other environments. This has led to a proliferation of tooling and frameworks which are a nightmare to manage.
No one is picking webpack because ‘it make pretty’.
Micro service makes perfect sense in a company with large number of teams. Ofcourse it would be stupid to use microservices if you are a small company with a handful number of devs.
In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices.
... 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.
"obviously the problem your solving doesn't exist, but if it did exist it would because front end requires someone without a complete lack of aesthetics"
Hmm... in the early days of HTML+CSS, there were a lot of visual people in the field. Some of them wrote some JavaScript, but stopped when things got too complex. These days they are doing UX design or create designs in Figma, and don't really touch code anymore.
Many of people that did only frontend (HTML+CSS+JS) also moved to full stack, with usually dreadful results.
From manager POV it's great, they don't need to manage 2 teams and can move people from frontend to backend as needed. and then you end with chmod 777 like in old bad PHP days. But hey we put that in container now!
This reads like a critique written by someone who has never actually worked on frontend. The choice of framework has no bearing on how visually appealing the site looks. It would be silly to posit that a company would, for example, choose to build their site on React primarily because there are a lot of visually appealing websites out there that happen to be built with React.
There is a significant chunk of backend devs who subconsciously and consciously avoid the complexity of front end dev and at the same time, snark about the alleged simplicity of it.
Ha you could not be more wrong. Front end is all about velocity and trying to not end up with a ball of mud at the end of the year. State management is where a lot of the complexity and logic exist.
Whereas within backend, our current state of affairs is “oh, need some new functionality? Let us spin up microservice #214 for that one thing”.
This is changing, and across all area’s experienced engineers can avoid these problems, but the thought of front end developers coding with their hearts instead of their minds is a funny one.
HTML and CSS weren’t designed to be general-purpose GUI description languages. HTTP wasn’t designed to be a client-server GUI application protocol. JavaScript wasn’t designed to be a serious application programming language. And the continued evolution of those technologies hasn’t focused enough on substantially changing that state of affairs. For example, a lot of basic UI controls still have to be custom-implemented and custom-styled by each app. CSS layout and styling is still a byzantine minefield. The ecosystem of tooling and libraries and frameworks remains highly fragmented. A staggering amount of manpower is being wasted away in bespoke frontend development.
> HTML and CSS weren’t designed to be general-purpose GUI description languages
Maybe not, but they are now, and are incredibly diverse in what that can achieve.
> HTTP wasn’t designed to be a client-server GUI application protocol.
Again, maybe not, but it is now with Websockets, http2 and webRTC.
> JavaScript wasn’t designed to be a serious application programming language.
Also maybe not initially but it is now incredible capable and amazingly only 50-100% slower than C! We now have WASM that let you reuse a vast amount of code from desktop too.
> basic UI controls still have to be custom-implemented and custom-styled by each app
Even with native gui toolkits developers are having to constantly build custom widgets for their specific use case. HTML gives us a baseline of widgets what work everywhere from desktop to mobile on all OSs. Would I like more? Yes, but what HTML gives us is the ability to build our own really easily, in an accessible way.
> CSS layout and styling is still a byzantine minefield.
I disagree, flexbox and grid layout are incredible and solve all the issues with the older box and float model.
> The ecosystem of tooling and libraries and frameworks remains highly fragmented.
True, and it can be a barrier to entry for someone new. However newer tooling such as Vite and ESBuild are incredible, fixing menu of the warts of the older tools.
But it would also say the the the amount of tooling options available is a testament to the success of the web platform.
> staggering amount of manpower is being wasted away in bespoke frontend development.
Most people don't want the web painted in the same shade of magnolia. Plus all those supposed "wasted" hours pay hundreds of thousands peoples salaries, supporting family and contribute to a vibrant economy.
The web platform is one of the greatest inventions of all time, and so incredible successful. It's so diverse in its capabilities and surprisingly performant at that. Honestly it's far better than people often give it credit form.
So web frontends are great because ... they're incredibly successful. That kind of tautological reasoning doesn't contribute to the discussion tbh. Web frontends are everywhere because recurring payments and/or attention economy approaches are more profitable than classical software sales, simple as that.
Web front ends are great because they truly run on any device without needing to install a binary. They're our only way to permissionlessly reach mobile users (due to mobile duopoly and sandboxed OSes). A web front end can reach billions of users and devices and be deployed in milliseconds.
That doesn't mean that the tech stack/ecosystem is great compared to how good or bad it hypothetically could be while having the property you mention. It's like saying a programming language is great because it is Turing-complete, which, while certainly an important property, is not exactly an encompassing measure of quality.
The web is the way it is because no one owns it. The web standards and protocols were negotiated over decades and have already accounted for countless amounts of compromise and feature sets between numerous competing interests and evolving tech while also maintaining backwards compatibility. How great it could hypothetically be is practically useless as an argument.
I would not say that Web UI is that more complex than desktop UI. In principle.
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.
Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else.
So now we have a "proper" frontend dev language which sits on top of a virtual DOM which is still based on HTML etc.
All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway.
I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.
HTML is nothing more than grouping definition of DOM elements. One of possible ways of defining element agglomerations.
It is not bad or good, it just allows to make job done - to group (semantically link) DOM elements together.
But the DOM element itself is what makes the difference. DOM element is the atomic block that a) can be attributed, b) may have states c) to be styled according to those attributes and states and d) can receive events.
In that respect Web UI is more granular than desktop UI. On desktop you have windows (NSViews, GtkWidgets, etc) that are macro state machines. E.g. COMBOBOX, LISTVIEW that have predefined complex structures and expose quite few configuration options|styles.
Web UI components are usually composed from many individually accessible and configurable DOM elements.
And that creates an impression of Web UI complexity. But in fact Web UI is just a DOM element with styles and bunch of layout managers to replace those DOM elements - its vocabulary is conceptually simpler and more regular than desktop macro blocks.
ReactJS (PReact, Mithril, Vue, etc) are not more than reactive DOM element aggregators - definitions of runtime assemblage of those LEGO bricks (DOM elements) in response of state/attributes changes.
On top of those we have Web UI frameworks that are all about providing sets of components - predefined types of aggregates of DOM elements.
I disagree with the premise, things have gotten a lot simpler.
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.
I'm more of an ops and backend guy, but I used to do a lot of web development in the early days of the web - assembling HTML, a sprinkling of javascript, hand-rolled CSS and embedded styles. In a certain way it was very simple, but in another it was horribly complicated. Sure, the pages we built were simple compared to today, but the tools we had were extremely crude and building a large website required some pretty clever things to stay maintainable. After I started doing more backend stuff, I lost touch with the evolution of Javascript and its various frameworks and I believed everything had become very complex.
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.
This is my experience as well and I agree with your point.
25 years ago, I had to know which parts of HTML, JavaScript, or CSS did or didn't work properly in different versions of Netscape, Internet Explorer, and a few other browsers. This also varied by platform. Internet Explorer 4.x varied significantly between the 16-bit version on Windows 3.11, the 32-bit version on Windows 95/98, and the surprisingly decent version they released for the Mac.
"Graceful degradation" was the goal on my team, so it wasn't so much about building functionality with JavaScript as it was about using it to make things more convenient when possible, without breaking things otherwise. For example, we would use client-side validation to save a round-trip to the server, but server-side validation would ultimately catch the problems if a client had JavaScript disabled. Keeping those validation rules in sync was a pain, because the server-side code was written in a different language from the client-side code.
I do think that frontend development is more complicated than it needs to be these days, but understanding the evolution, I can certainly see why it reached this point.
I recently transitioned to a "full-stack dev" role (using React on FE), and honestly, it is much _simpler_ than I expected. I had the opinion before that FE is lacking the breadth of BE development, but of course, without actual experience in the matter I might have missed something.
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!
There are probably 15k npm libraries that solve that very thing. I think this is part of what people struggle with and complain about WRT web dev. There are so many choices for libs and frameworks it can be hard to know which one to pick and which dragons you'll find along each path.
I suspect a lot of it is historical. If you go back a few years there were lots of browser incompatibilities and many limitations in Javascript, CSS and HTML. To work around those difficulties and limitations many frameworks were created. Today many of the limitations of the basic technologies have been fixed but the frameworks are still here, though probably less necessary than ever. But once people have gotten used to doing things a certain way (for example using jquery instead of querySelector) they tend not to change.
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.
Sure developers have a hard time handling all that HTML, CSS, Javascript and connections(DOM, etc.) between them, but I see a much bigger problem in browsers. There are actually only a few browsers and most of them are based on chromium(or Webkit). Why? Because web standards are huge!
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).
Well said. I've been following Andreas building Ladybird, and it has been an eye-opener to see the complexity of what is effectively an operating system built on another operating system.
mid-2000s I think it all started with the rise of AJAX and "Web 2.0". In the beginning it was just sort of gimmicky for visual effects and experience and we were all scratching the surface of what browsers could do.
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.
The lack of objectivity around this is absolutely astonishing from a community such as this.
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.
In my experience, people don't start out with the goal of loading indicators on buttons. It's usually the mistaken idea that avoiding a page reload will make the action faster. Instead, you now have a slow Ajax call, and the button appears broken, so now it needs a loading indicator.
"a slow AJAX call"? What is even meant by that. Async JS is not slow. It's only limited by the user's connection speed and amount of data to be transferred and server response speed. This is a few dozen milliseconds but can be optimized down to sub 10 ms (the server and latency is the bottleneck not JS). A full page reload will of course take longer because instead of one tiny JSON object you have to send the full HTML back down the wire, and the screen also completely repaints and sets up a whole new DOM structure in memory for the same components.
On the web side you need to synchronize the DOM, the visual state (which is mostly related to the DOM), the user's state, and the backend state using a protocol that's stateless.
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.
> How do you specify "animation like x/y/z" on a screen?
And not just "a" screen, but screens of all dimensions and even physical interfaces (but mostly, desktops vs phones, which are completely different).
I've only dabbled mostly amateurishly on web frontend, but personally I think I'd prefer to serve totally different files to someone based on the form factor of their device rather than deal with reactive frontend frameworks. Heck, I already serve both Gemini and HTTP.
The question itself might contain a partial answer. If "frontend" and "backend" are assumed to be two completely separate disciplines, the architecture is going to reflect that (Conway's law).
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.
"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."
In the enterprise, data transit, processing and management architecture is more complex than save this text in the database; just as decent UI and UX is more complex than a text field and input button.
In the enterprise sometimes things are complex and sometimes things are getting complex when you take a team of 100 people and ask them to build a new system they will build a huge system and discuss for months about reliability, error handling, remote storage, and a lot more needed systems.
Each specialisation will define some constraints that will only be needed when their system is 3 years old but present it as if you dont start with that it will be hard to add it afterwards.
Thus if you ask a 100 people department to create a new web app it will create a web app that will provide enough work for 100 people.
Frontend was always complex, being web, mobile or desktop apps. It is following similar cycles from decades ago. Winamp[1] in 1997 made their own UI using custom draw in Windows because those components and level of customization didn't exist in the standard API. We can historically observe these cycles of complexity and technology changes only looking at Windows toolkits: Win32, MFC, QT, Silverlight, Windows Forms, WPF, etc.
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?
People wanted applications and app-like behaviour in the browser. And browsers are uniquely uneqipped to deal with that:
- 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.
This will be a posting, which either receives no to little responses or will have 256 responses within the next couple of hours :)
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"
A lot of programming seems to have turned into gluing a bunch of poorly programmed and documented systems together. I miss one of my previous jobs where I got to build a lot of stuff from scratch.
Well why reinvent the wheel with ie Spring in Java - you want well tested automatically scaling thread messaging bus for example, just configure existing stuff. Maybe its boring to some devs, but business like boringly stable tools, and they are the ones paying for our work.
Would you like that architects reinvent 'engineering wheels' with every house, bridge or tunnel and do all feom scratch just because its more fun for them? No you want well tested reliable approach, if they are bored a bit even better. Ie nuclear power plants who have some unique hybrid designs are endless source of maintenance delays and additional costs. Software devs just have much more freedom and little regulation, for now
Not necessarily reinvent the wheel, but not build the same glass buildings all across the world either. Your analogy is not that far off. Real world architecture is quite the same.
Spring is a strange example. It’s main selling point is you’re not reinventing the wheel and, instead, building on well tested and operational work already done.
In my teens, I could regularly churn out a small GUI program after school in an application like HyperCard, or later REALbasic (now Xojo). I remember writing a saved game editor for Psion Boy[1] which had an editable list of inventory items, fields for character stats, and buttons for saving and loading game files.
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.
I have one more thing to add to your benefits of web front ends. Security.
At least some security separation between the application and the users operating system. If I loaded the save game in a web app, I would at least have some assurity that the application was only going to get access to that one file, being the web browser is going to enforce that.
With a binary thing are far more terrifying, every file I have permission to is up for grabs. Running it on my primary machine is a no go for the most part. I'll have to load it in a VM if I really want to use it. With this said Windows 10+ has the Windows Sandbox feature that very few people know about, but there is still a fair amount of friction there compared to a browser.
Most of the answers here are pointing to things like inefficiencies, short-sightedness, and over engineering, but I'm not seeing the positive side.
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.
React must be used for all websites- no matter the cost, no matter the implications, no matter the practicality. How else will you hire any developers? They explode if not writing JSX.
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.
Expectations have increased a lot in web development. When I first started working, web front ends for business applications were ugly. They were designed to do the job and nothing more. They might also be hard to use without a manual. These days the designs I get given look pretty and have simplified interfaces for the user. The designs never use native elements and often invent novel UX interactions.
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 expectations have gone up and a developer can't even take on coding some pages without prior input from some UX enginner who is likely assisted by some UI designer.
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.
I get the impression making a web app was considerably more difficult for a solo developer pre-jQuery. For a while we had an explosion of choices, and ultimately things coalesced around React and similar paradigms. Meanwhile the per-capita productivity has been skyrocketing as increasingly sophisticated cloud services provide everything from raw key-value storage to turnkey caching and auth solutions.
Is it more complex than single-device programming? Perhaps, but the modern browsers represent a nearly universal platform with very low per-user complexity.
Where the majority of the complexity was in the backend. Now, the complexity has simply moved.
I'm quite happy I don't need to have two different codebases in different languages for most things anymore. I'm more than happy to offload it to the browser to save me some effort, time and money.
You have to validate on the backend among other things. Honestly the only thing we have nowadays is flashier websites for the most part. Some very small percentage of websites actually require the tech that has been built despite the fact that nearly all engineering teams seem to push for it.
From an application manager/solution manager perspective, I see 2 main reasons and a few smaller ones:
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.
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").
The main reason is because we shoehorn complex apps/ui's into a browser that wasn't made for 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
You could do this now with HTML canvas and web assembly, but you won't, because the web already has a rich feature set of accessible and search engine friendly features.
> but could concentrate on what really matters we wouldt have such a big problem
Curious for someone who dismisses the complexity of front end, what you think really matters in creating a cross platform UI application experience that works on all devices?
I'm old enough to remember when Flash and Java were hailed as the future of application development because they were "cross platform."
Your "browser made for apps" isn't the dream you're imagining - today's SPAs are miles better, whether they run in-browser or are packaged up as Electron apps.
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.
Back in the days of mostly static HTML, and maybe some simple JS for effects, you didn't need much complexity in the Frontend. Most logic was in the backend. That logic has moved to the Frontend, and so has the complexity. Yes, Frontends are more complex than ever before. But at the same time, backends have never been simpler. Most backend devs just implement some simple CRUD APIs for the Frontend code.
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.
Because complex applications are now delivered as web apps instead of as desktop applications, and these require complex tooling to maintain. Then everyone wanted to use the same tools in other areas (I guess), where it is probably not necessary in a lot of cases. You see similar trends elsewhere (e.g. cloud, k8s), perhaps CV building is the real reason.
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.
> Why did Frontend development explode in complexity?
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
> Is that complexity necessary or artificially inflated?
This entirely depends on the product. You need the complexity for some products; and not for others.
I agree it's gotten too complicated. In my mind, the evolution has gone like this:
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.
I've done frontend since IE6 was the major browser. Back then most of the time was spent using hacks to work around the limitations. No rounded corners, no opacity, no grid, etc. As it got easier, with better adoption of the web standards and better tooling, frontend-devs were able to do more.
But I feel as REST and GraphQL got more adopted a lot of the complexity moved from the backend to the frontend.
The frontend part is easy these days, but working with the backend is the hardest part of being a frontend developer.
Complexity is one end of the spectrum. Browser APIs for various stuff like animation, video, audio, webgl, etc is not that easy for developers to consume. Often most of these features have their own set of sub-complexities and concepts. For e.g. drawing/animation on the canvas is relatively simple, than doing stuff with 3d animation; the latter involves lighting, viewer perspectives, etc.
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.
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.
90% of small and medium apps could be redone with a simple UI toolkit that gives you a box of widgets and callbacks. I built a geoscience 3D application in the mid 90s with FLTK and it was the last time I made something UI based where I didn’t feel that the UI toolkit was getting in the way of getting the work done. Assuming a lot of complexity in anticipation is the wrong approach 99% of the time.
In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices.
... 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.
Because we took a platform for linked documents and grew it into a platform for applications. If the web were still documents, or if it started as a platform for applications, then it wouldn't be as complex.
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.
Related question: what would the folks here recommend for someone that wants to keep the frontend “stupid simple” while not resorting to writing everything in pure HTML/CSS/JS?
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.
Personally I've had great success with adding Web Components to server side rendered projects. It's really simple to just bind a class to the custom element and attach a few event listeners. If you need something a bit more complex rendered on the client side you can use mithril or similar libraries like lit-html. When I need to hydrate a state I JSON encode the model as a data-state attribute and I decode it when the Web Component's connectedCallback method fires.
JavaScript as an ecosystem and language became much more accessible than ever, with all the toolings and TypeScript, it's easier to build abstractions upon abstractions; and people love to have their own version of abstractions. It's human nature, it's inevitable.
All I have to say to this is we recently rebuilt our admin tools application and the team responsible have been all backend / devops engineers. Stack is React and GraphQL. Without having any real FE experience this team has been absurdly productive. Rewind the clock a bit and it would have been a nightmare. From this experience alone I can conclude that the complexity issue the OP is citing is mostly an illusion, assuming there's someone around who can help guide tech choices at the beginning. There's simply no way a team of non FE engineers could build this stuff so well, and so quickly, a decade ago.
Yeah, I definitely know this through painful experience, but historically library upgrades in non-trivial apps have always been difficult. It is what it is, and its the same in every stack.
- 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.
I keep seeing this type of thing popping up. The short answer is because people are expecting more from the web.
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.
* The increase in complexity is unavoidable as well as accidental (creep due to marketing). Some of it is necessary to address the increased sophistication of the web. Just compare what we can do today to what we used to do in 1996 with cgi and perl.
* 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.
Frontend is inherently complex and becoming more complex because we build more dynamic web apps. PM and designers don't know what works and keep changing the product until they get something acceptable, which will also mean much more moving parts for developers until the product matures.
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.
> Is that complexity necessary or artificially inflated?
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.
There's a common pattern I've seen over and over. When people learn a new thing they tend to go through a creative phase with it. The first time I noticed it was in a programming class I took in school. We were learning in Pascal. (It was cute!) When we got to the lesson on changing output colors, for the next week it was like some unicorn barfed rainbows all over our screens.
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/ )
As I've said elsewhere, frontend development is limited only by the limits of human imagination, whereas backend development is limited by the constraints of backend systems. For example, there is an absolute answer to 'what's the most efficient big O runtime I can achieve for sorting this data set'. There is no absolute answer to 'what is the complexity of drawing an aesthetically pleasing button and modeling its interactions to maximize user joy?'
Question 1: On average, yes, but not as much as people think.
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.
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.
Regarding frameworks: Things like frameworks have utility in large scale web applications where you need to manipulate a lot of data on screen on the fly. Using the right framework for the right thing can make development and maintenance fat cheaper and faster.
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.
My conspiracy theory of choice is that all these big front end frameworks have been developed and heavily funded & pushed by (primarily) Google and Facebook specifically to make it so people are forced to run client-side JavaScript to get even the most basic functionality in every website, this ensuring tracking and ad code can get delivered.
Alan Kay thinks the internet and TCP/IP is awesome - but the web is horrible. He's coming from the small-talk world where you have an incredibly powerful environment that's self enclosed.
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.
The Barrier (tm) has lowered substantially. Let's be honest guys, it is really hard to hire an engineer whom understands the virtues of modern system, and how simply you can work out the most complex logic with it.
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.
NPM is the Instagram for developers. They produce mostly wrapper packages around standard APIs in order to get some fame. It would be much better if they teach people how to achieve basic stuff without already-baked-in APIs.
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)
Any link to that YouTube tutorial? It's hard for me to imagine someone who presumably knows how to create CLI scripts not independently coming up with a solution very similar to yours.
I'd say this is the result of huge investment bubble in IT companies, where nobody cared enough of efficiency of workforce.
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.
Most of the state of application used to live on the backend but now that has transition to the frontend. Dealing with the state of application is difficult because of edgecases and side effects, React can handle many different domains mobile, tv, and website. Of course development will be more complex with more target domains.
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.
Most of it seems about resolving the tension between javascript, peoples opinions, the DOM, and the role of the server.
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 started my Web Dev career in 2005, around the time "Web 2.0" started to pickup steam. It was (In my recollection) really the beginning of the Web Application model. Users were starting to expect web pages to do more, and be more than "click a link, go to another page"
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.
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.
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!
Because business cares about business and moves too fast to get it right or waste time on values, and by the time enough people might object the network effect or inertia or tech debt or whatever you want to call it has become The Way It’s Done and nobody can stop long enough to fix that.
Business is in competition with other business, not in competition with 'doing things right'. Forcing businesses to 'do things right' is called regulation and will get you lots of subcomments on how that's bad here on HN.
Because the web distribution model for apps is extremely cost efficient. This has caused exponential growth in web app development. To support this, frontend frameworks have grown almost exponentially as well. Every corporate app is a webapp nowadays. This wasn't the case 10 years ago. When we talk about web development, we are now not just talking about websites but about apps as well. So the industry has changed significantly.
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
From where the web started to now, the complexity makes sense. There were tons of browsers all implementing html, css, and javascript with their own quirks not to mention their own additions. For example, the father to all modern live websites, XMLHttpRequest is a Microsoft invention that was originally intended for Outlook web mail.
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.
Anwering Q1: a number of reasons, the most important being: 1) programmers' immaturity, we're always looking for new toys; 2) excess of venture capital fuelling too many new projects, opening space for new stuff to be used instead of the old, stable and boring ones; 3) product/design people asking for increasingly insane UI frills, influenced by trends started by big tech's products.
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.
I started a project in October. Spent part of November and through December building prototype frontends to decide which way to go - the whole next / nuxt type debate, looked at svelte and Laravel. Finally came to the conclusion that since I was using Django for the backend anyway, there really wasn’t anything that couldn’t immediately be done just as well with Django templates. Sure, maybe at some point I’ll need to integrate some other frontend tools, but by that time I will have tested market fit and I will have customer feedback that tells me if I actually need something different for my UI. All of these front end frameworks add a ridiculous amount of complexity and brittleness for unclear advantage.
Shitty ducktape-y standards (most notably JS that was initially designed in 10 days). But it still became the standard for x-platform SaaS UIs: point your browser to a URL and go!
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).
Complexity in software typically comes from codebases made for multiple teams. When you have multiple teams, this is unsurprisingly a benefit. When you don't, you typically get one team pretending to be many, and the needs of the other personas will be guessed, not known.
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.
Frontend development happens at the tail end of long pipeline of requirements gathering by product and design folks.
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.
Browser capabilities exploded dramatically as well as hardware, this is why we have Figma and virtual machines running in the browser. So the answer to this question seems obvious to me. It would be odd if UI complexity stayed the same.
I think the principal reason is the browser now has sufficient features, broadly deployed, that we swung back towards thick client architectures. So the frontend gets more complex because it’s doing more. It’s not the first time in the history of computers that this happened.
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.
Because browsers don't support server-side declarative views natively yet. FE development wouldn't even be a thing if web servers could respond with something like
Context: I'm a Rails full-stack developer, I started developing web apps 12 years ago.
I still consider myself a full-stack developer, even if I'm a BE dev right now, since now we have FE and BE in the company I work for.
12 years ago, there were no FE/BE devs: there were only full-stack devs. We used to struggle maintaining tons of imperative JQuery/Prototype/MooTools/you-name-it JS code built on top of server-side declarative HTML.
It was an hell of development/maintenance. Imperative code was pretty easy to write at the beginning, but after 2000 JS LoC you had half of the view implemented in JavaScript. end-to-end testing tools were almost inexistent, so there was no way to avoid regressions on the messy JS code you wrote. After 10000 JS LoC you were pretty f*ked. This workflow was unsustainable for any web app that aspired to appear "modern".
In a couple of years, FE frameworks (AngularJS was the first among popular ones) started facing this problem. They offered you a declarative way to implement dynamic HTML views.
Moreover, companies killed two birds with one stone: they could totally divide FE and BE, so to hire way more developers as junior developers are better suited to work for FE, and reserve the senior ones, with more experience and better payed, for BE. This is another crucial aspect of BE/FE devs division.
Now, to answer to your question:
> But... This is FE development, you think the backend devs would like to be writing this?
We (BE devs) had done that for years. But now we'll fight hard against going back to full-stack, but only for our advantage: in this way, we can get treated way better and get payed way more.
Too many different platforms to support which causes engineering issues.
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.
Frontend development has risen as an alternative so that it's much easier to not program for native frontend system but instead hiring "fullstack" developers and or purely frontend developers. The complexity of these frameworks correspond with applications that are either web first and or electron based. The complexity is necessary in certain situations but at this time it is very artificially inflated because of the fact of ease of hiring and that most people and or frameworks that propagate by word of mouth or just following what others in the industry do.
There are a lot of salient points made in this thread, but one other aspect is that frontends are the end of a dependency chain, that is roughly like pipelines->databases->middleware->webservers->frontend. The tail end of such an architecture can be more easily change, because less depends on it, usually the only thing is the user's eyeballs. In that situation, more variety proliferates because there aren't as many constraints. Less constraints usually translates to a diversity of approaches, which is what we see in the frontend world.
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.
I think the natural evolution of programmers is to become more capable of building complex systems until you reach the realization that just because you can build it, doesn't mean you should. You then think hard about how to build as simple system as possible. The front-end space hasn't historically struck me as filled with a lot of grizzled systems programmers that have learned this lesson, so we get what we have today. Eventually they will learn and thinks will start becoming more minimal.
The shift from thin client to fat client forced the frontend to deal with greater state, sync and cache issues. The build ecosystem has multiple steps and langs. The visual fidelity and complexity of UI makes it difficult to test requiring us to deal with e2e testing with new tools.
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.
1. Browsers evolve but the JS ecosystem is competitive so instead of using the brain power to find a common solution to problems we end up with a grid of benchmark of frameworks about how fast it refreshes. I still see job description mentioning Redux while you don't need it 99% of the time or even never.
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.
In many cases it's probably not necessary. There's a lot of low hanging simplification fruit available in at least two areas:
• 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.
"If all you have is a hammer, everything looks like a nail."
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 still do a mixture of jQuery and whatever I learned from modern JS. I totally missed the boat on everything else. I still render server sided, and rarely run into any issues.
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 Frontend is mostly what gets promoted by Sales and Marketing when selling the product. The complexity results in trying to exactly meet what they request, or give them enough to talk about being new in the product. Performance improvements for the most part can only take up a few lines. New features, on the other hand, can take up countless pages if needed.
I think it is artificially inflated. The web took off to such a degree that that is where all the high paying jobs were. So people came over from other places and brought their complexity with them and imposed it on web development. The fact that you now have to have a build system to create a website is like something taken straight from application development.
It's actually quite elementary and obvious if you have been in the market long enough: from websites it shifted to web apps, which have a different type of and higher complexity.
Beside that, also the websites got more complex, as a wider range of people started to use them, as well as different types of devices, languages, purpose and so on.
I'm not planning to join the 'artificially bloated vs. necessary' debate, but
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.
Tech companies get a lot of subsidies (directly and indirectly) so they develop inefficient practices.
When people don't have profit and loss incentive, where incentive means they are not removed by the market due to losses, human psychology tend to favor bigger, complex things.
This might be a bit of a stretch but I believe native mobile apps is what triggered complexity in web apps. The bar was raised and users were expecting performance and experience equal or better than native mobile apps.
I don’t think react valued simplicity. It didn’t have an official store for years and still lacks CSS solutions out of the box but it seemed to be the only way to do components so people used it.
tailwind is the best utility css library to use with React, you can make components with Angular, React became more popular than Angular because it didn't introduce new concepts like dependency injection and stuck closer to ES6 standards
no tailwind became popular because it introduced the concept of "utility css" and was the pioneer of it, if React included css in the components it would have looked like styled/inline javascript or scss/less or css modules, developers do not write their own classnames with tailwind
Utility CSS is the mixin pattern and was widely used for a decade before tailwind existed. This confirms by believe that tailwind is mainly used by people with little to no CSS experience.
The main reason is easy “to plug and play” various tools, i.e react, websockets, graphql, webpack etc. That’s not related to frontend only, but kubernetes devops are also crying from complexity.
Unpopular opinion: Because people started thinking it'd be a good idea to treat the browser like an operating system instead of an ardent renderer of interlinked hypertext documents..
Because many devs now specialize only in frontend and many succumbed into new ideologies of what is right - like using React and Webpack instead of seeking simplicity in design.
Developers are smart people who enjoy solving complex, interesting problems. If you give them a simple problem, very often they will find a way to make it interesting.
first v8 for speed then node.js - it allowed to do complex code generation stuff to happen on backend and on one side erase some incompatibility problems, on other to just do stuff that wouldn't be possible if JS was only run on frontend.
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.
I think the better question is why haven’t we made front end development toolkits less complex (by pushing a lot of the complexity into the browser itself)?
for most libraries, I think people in core teams cause it. eg react is destroying the potential of hooks more and more with each release. and it's weird that no one of them said, "what are we doing right now, does this stuff really have to be this complicated", but I guess that's exactly what open source development culture is today. we know best and you should use it.
IMO it's because the bar has gone up, especially from customers.
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.
...or developers think that. Or they pretend customers will care because they really want to play with their new framework.
Nowadays everything is a single page app, and for 90% of website/web apps it would be better (and orders of magnitude simpler) with good old server rendering. It would also be much faster.
Thats true, but people do crave complexity. If something is "too simple", often people, especially developers, are strangely suspicious of it being useful or competent. Present someone with something doing a couple things well but simply, you'll be normally greeted with a million comments of how it doesn't scale or give enough levers or do this or that.
because people didn't learn properly how to build object oriented code with objects. instead they made up the excuse that it's implicitly complicated when in reality they just aren't very good at factoring
I'm going to attempt to give some fact- & data- based answers, as there seems to be too much ideological axe-grinding in (many of) the existing responses (as is, unfortunately typical on HN it seems, when discussing Front End Development). Even if my attempt seems...boring? (And sorry for the length; hopefully it makes up for that a bit in quality...?)
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.
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:
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:
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!
> Is that complexity necessary or artificially inflated?
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.
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.