Just because a new solution is trending doesn't mean you have to figure out how to use it in your tech stack. Evaluate your needs and where it may or may not fit and decide accordingly.
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
SSR was just an example. It's a valid solution, my point is that it's now yet an extra workaround to a problem we created in the first place.
Websites were SSR'd by default back in the day, the backend (with PHP or whatever you had on there) generates some HTML that the browser displayed. 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.
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.
SSR just seems like tail chasing, but this time around there is no mature server-side framework (like Django, Laravel, Rails). Maturity, ecosystem cohesion, and higher level abstractions are all casualties along the trail of abandoned work in the name of "scalability" and "modernity".
> This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place.
No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project.
Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.