The keyword in your argument is "Application". The niche of sites that really embody that definition is small. If you are dealing with a really demanding use case requiring a large number of changes to the page over the course of a single usage, and you have to keep track of your state while doing so, CSR is a viable option. My point is that the number of sites that actually need that is a minority.
And as a FED you might find FE apps easier to build, but not everyone is a FED. Some have to build both ends, and when that is the case, being able to simply template some html server side and send it down the wire is much easier than spending hours just configuring and tweaking your bundles, tree shaking settings, code splitting, SSR the inital view, etc. Not to mention that you then have to build the server side API for your application alongside the FE. If you are on a large team and need to be able to silo development between different groups of developers, then CSR apps can give you that extra decoupling distance. But that again is the minority.
I really think you're in the minority for all of these opinions, but I do respect your opinion. Thank you for your time and input toward the discussion. Hopefully I haven't turned you away from CSR SPAs.
"So, instead of importing the entire Tire Store, you should be importing the 4 exact tires you need, and get back to building the car." -sounds like using Python ;)
Andrew makes valid points. Matt, he is in the minority because the majority of web devs are not doing backend work.
I'm full stack lamp, i've built SSRs with caching that load as fast and score better on pagespeed insights and other tools than some SPAs.
It's rarely the tools we use, but the skill of the developer using those tools that really matters. Side note: i've also used angular, react, and vue, though not as much as i'd like yet, so don't judge me just on the lamp statement.
You can build SPAs and CSRs, but if you're screwing em up, an SSR site can outperform it just as easily as SPAs and CSRs can outperform SSRs when those are setup wrong.
People like coding things with the things they know how to use.
How many of us actually stop to go and learn the other side of it to truly have an understanding of how they all work? Very few of us even work in environments where we have to try them all out. Agency work puts me in a lot of projects where i have to learn other ways of doing things, most people work on one platform, using one tech stack, for years and then want to claim that stack is the better way of doing things.
I like to think I've seen enough to say the tools hardly matter if the developer knows how to use them.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.