[datadeft]

Why do we need a frontend framework? I am genuinely interested. The last project we used SSR and the sire ended up fast and snappy using a lot less energy than the previous similar project we used a JS based framework and we had all the functionality we needed.

[muspimerol]

I think the common argument is "complex interactivity". If you have sufficiently complex custom client-side interactivity (e.g. sending, receiving, manipulating and displaying data in the DOM without constantly reloading the page) then something like React or Vue is much easier and more maintainable than a bunch of custom JS. Logic for mutating and displaying data can also live on the backend and use SSR, but it has to live somewhere. I think people like SPAs because you can draw a convenient boundary at the server level by exposing a JSON API, and folks working in HTML, CSS and JS like the component model offered by frontend frameworks (I know I do).

There's also something to be said for consistency. When I walk into a React or Vue app, I can figure out what's going on and build on top of it quickly. Even if they are using a mish-mash of libraries (as JS apps do) the majority of the time you will see similar libraries and patterns used.

All that said, there are many monstrosities built upon SPA frameworks with poor performance that would likely provide better user experience if they were using SSR. But there were also many SSR monstrosities built before SPAs were in vogue.

[datadeft]

This is the most useful comment so far. I tend to agree. However, I still think that most frontend project are perfectly fine with mostly HTML + CSS and a tiny bit of JS.

[whstl]

Projects that don't need a lot of interactivity after rendering definitely don't need one and you can get away with rendering everything in the backend.

Other projects need some additional features that must be implemented in the frontend, but still don't need more than vanilla JS or jQuery.

Others might need more complex components, such as datepickers, carousels, interactive charts, interactive tables, accordions. But even those can be consumed from third-party components without a framework. A middle ground is writing your own encapsulated components.

However there are more complex apps that do benefit from frameworks. It's often because they have a lot of custom components and a framework really helps; and/or because they're not really divided into pages in a traditional web way, so rendering on the backend is significantly harder; and/or they have a lot of shared state between multiple areas of the screen, and not refreshing is easy than caching or re-fetching. All those among other reasons. Slack Web can benefit from this. Your daily CRUD not so much.

Whether people are using the right tools for each job is up for debate. And sometimes you'll have incorrect requirements. But there are definitely reasons to use more complex/flexible tools.

[_heimdall]

They were extremely useful before browsers had certain features, like web components of the Proxy api mentioned in the article.

Today the argument is usually based on highly complex apps, think complex dashboards accessible behind a login or browser-based apps for recording a podcast. Those are reasonable uses for client-side frameworks - the problem is they are often used for much more basic sites that just need a mobile menu, accordion component, or a dialog modal. All of these can either use entirely browser native HTML/CSS or easily built in JS without any dependencies.

[wbobeirne]

I've worked on quite a few projects that would have had significantly worse user experiences if they were done in a purely SSR driven way:

* Chat applications, or anything where you need to have the UI react to incoming events from a socket.

* Applications where sensitive data lives in the client and you don't want to be liable for that passing through your servers.

* Anything dealing with video or audio (e.g. video chat, screen recordings.)

* Applications that are driven by peer to peer data.

* Applications with high interactivity (e.g. spreadsheets, heavy form validation, drag and drop UIs, graphic manipulation.)

It really depends on what your application is doing. If you're just a blog or an eCommerce site, it's definitely worth asking if you need a frontend framework. But for some applications it's absolutely worth it.

[datadeft]

* Applications where sensitive data lives in the client

Isn't JS the worst kind of solution for security related things?

[zdragnar]

E-commerce of any sort involves sensitive data (PII, credit cards, etc). Plenty of third party payment processors let you build a very nice custom looking check-out flow via provided libraries that interact with popular frameworks. Your server never sees any sensitive info.

None of them require using those frameworks, of course, but they can make life easier.

[xboxnolifes]

In what way?

[datadeft]

A few:

https://snyk.io/learn/javascript-security/