re: You Probably Don't Need A Front End Framework VIEW POST

FULL DISCUSSION
 

I understand the point of this article and agree, you should not simply choose a FE framework just because everybody else is.

However, I think you glossed over the fact that by replacing frontend frameworks with SSR you lose static hosting, preloading, perceived site speed to the end user, and many other possibilities.

Don't get me wrong, SSR is still great and has plenty of great use cases.

What you end up building seems like an SSR framework, like Ember, but without great developer tools, documentation, and community support that a framework provides.

I think frameworks can be overused or used for the wrong purposes, but it is always a great idea to use tried-and-true frameworks so you are not rebuilding the wheel.

 

Right. The point I tried to drive home is it depends entirely on the scope of your project.

For my own, if I ever get to the point where I'm rebuilding the wheel, it wouldn't be too hard to bring in the framework and migrate stuff over. The server logic/backend stuff is all there already.

 

Maybe the generic term rebuilding the wheel needs an antithesis. Like just because you want to build a car, you don't need to import an entire Tire Store. While it is unpopular to say "manipulate the dom" directly, its perfectly fine, and people do it and yes, almost all frameworks bring extra code to your project that you frankly do not need, nor ever use. There just aren't enough native pure Javascript programmers out there. And rendering Server side has been around so long, its a perfectly fine and secure paradigm to deliver a blog or message board. Of course you can use "Ajaxy" style lazy loading to bring in content as you need it without a page-rerender. Its cool you brought up Ember, I need to check that out in greater detail. Cheers!

 

I like the metaphor with building cars, but the beauty of JS and these frameworks is that in most cases, when configured properly, you are tree-shaking dependencies and truly only shipping the runtime (which in most cases is smaller than a single hero image) and your code.

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.

I can see where you are coming from, but tree shaking isn't a silver bullet as not everything is easily shakable. And any given dependency can tie unnecessary code in. Also, I'm very weary of setups that require a significant amount of knowledge to get good results. One benefit of SSR is that the simple thing also has relatively good performance.

SSR has relatively good performance, until you actually have high traffic to your site.

Static sites using CSR hosted on CDNs will heavily outperform at scale. Each client is performing the heavy lifting, instead of a singular server you must pay to increase resources.

I would also argue that any tool will be more performant the more adequately you understand and utilize it to the best of its ability.

Most websites won't ever see the scale you are referring to. And many parts of SSR can be cdn hosted as well. Not to mention that in many applications, the companies behind it have been SSR the client side framework to get a faster first paint, you now have both downsides. I will say that PWA can get around this by locally caching the CSR. What I'm getting at is that the simple projects, and the new programmers don't get addressed in a lot of these discussions. If you trivially set up one of these CSR apps, you're in for a long uphill battle for performance. Not to mention that extra work has a real cost associated with it in terms of development time and investment.

You clearly just do not want to use CSR SPAs, and that is okay.

However, you cannot argue that SSR is easier. As a FED, Isomorphic applications are simply easier to build. React, Vue, Gatsby, Nuxt, and Gridsome all have great CLIs that make scaffolding, extending, and optimization insanely simple.

When you use these tools, you are delivering a better end product to the user that is cheaper, more performant, and more secure.

I'm sure if you gave some of these tools a chance, and really dove deeply in, you would see the benefits for yourself.

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.

 

Matt, Ember isn't an SSR. There is FastBoot, which provides SSR similar to some React solutions, but it's not the default stack.

As others have said, with proper caching you can serve up SSR apps that run just as quickly as SPAs. In fact, if you're rendering the same content multiple times, you're probably doing it wrong. Those apps have the advantage of offering the developers a 1:1 relationship between their markup and what is rendered, with none of the abstractions upon abstractions that CSR folks accept without question.

My personal position is that this cannot be an intellectually honest debate without considering the role of Turbolinks and libraries like it. Rails or Express + Turbolinks are simpler to build and load faster than an SPA because there's no client compilation.

There are reasons to use client libraries like React, but they are actually the exception. Rails + Stimulus + Turbolinks for the win.

 

What is SSR? I just googled it and it said it was that concept where you can write any program with basic loops and if statements.

 

SSR - Server Side Rendering
CSR - Client Side Rendering

code of conduct - report abuse