But SSR isn't a core requirement for many applications. Nor is it necessary to build out a purely javascript based stack on the server side to get SSR with a shared React client codebase.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.
I never said the authors of big JS projects weren't smart. In fact, anyone that manages to keep their sanity in that environment is by definition smarter than me.
I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
Most projects do not have any requirements like real-time UIs that would justify a front-end app and will be just fine with a "boring" backend-rendered UI with some HTML, CSS & forms and will automatically avoid a horde of problems like syncing authentication between your backend & frontend, having to manage a separate build pipeline, server for SSR, etc.
> I however stand by my words that most React/Vue/Angular front-end developers in most companies are absolutely unnecessary and are actively detrimental to the project by introducing complexity to justify their position.
I strongly disagree; most of the projects that I worked on a decade ago that lasted more than a few months ended up with ad-hoc frameworks or conventions implemented in vanilla JS or jQuery that varied wildly in quality and changed frequently through the lifespan of the project. In my experience React/Vue/Angular with their generally well engineered and thought-out principles have resulted in a huge boon for productivity for long term projects in a team environment.
> Most projects do not have any requirements like real-time UIs
Whose "most projects" are we talking about here? Yours?
> Whose "most projects" are we talking about here?
Go on a job board, search for React/Vue/Your-Favorite-SPA-framework, go to their website and then see if there are any features that would actually justify an SPA.
Some examples: the Airbnb website, the New Reddit, etc.
I would use reddit as a counter example.
Sure some the new features could be built without an SPA, but it would be much harder to do so.
They have a full wysgi for theming built in, a real time chat app, a video sharing app, multiple messaging platforms, and methods of bundling multiple subreddits together.
They added all this really fast, due to the nature of the platform being an SPA.
I have the same issue at work. Any given feature in isolation could be done simply as a jQuery plugin, but together the only way to make it seamless is an SPA.
It used to be true. Their first few months of the SPA was really rough on the UX front, but it really improved since then.
They have a good design staff, but there was so many minor decisions made over the years that no knew exactly what was a necessary feature of the UI and what was just fluff.
They needed some real world testing to get a better design.
> Then we decided that wasn't cool anymore and went through this whole clusterfuck of SPAs to justify cool kids' careers and now we're going back full-circle to a way more complex solution with more moving parts of doing exactly what we implicitly had 2 decades ago because we realised cool kids' careers had negative impacts in terms of page load performance.
I really don't think the author of most of the tooling in the ES based javascript ecosystem are "cool kids trying to justify their careers". If you actually think that, take a look at the github profiles of some of the contributors for many of these repos. There's a ton of smart people working on these tools. They're not chasing trends. Sometimes complex problems require complex solutions. Sometimes they don't. It really depends on your project. Bemoaning the amount of options available seems like a waste of time.