>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!
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.