In which scenarios is server-side rendering is better choice than the front-end JS libraries like React, Vue, Angular etc.?

Question

As a Java developer, I just have scratched the surface of Javascript libraries like React, Angular, Vue etc. It seems that theoretically any web applications with server side rendering, like Spring-mvc with JSF, can be replaced by the aforementioned JS libraries those kinda totally decoupled views from the models and controllers.

Question: In which scenarios is server side rendering like Spring-MVC with JSF cannot be replaced by JS libraries the future work would be more tough?

Answer 1

History

In older days all web pages were generated on server. There were several tools for this in Java: JSP/JSTL, Velocity, FreeMarker for page generation; SiteMesh and others to generate common parts of pages (e.g. header & footer) in Servlet Filters.

This approach had issues:

• If you needed UI folks to help you out they'd have to deal with server side
• If you wanted to build everything yourself - you'd have to learn HTML/JS/CSS
• And in the end the app wasn't very interactive. Most interactions required requesting a new page. Though this mostly was because BE devs weren't comfortable with JS.

Then mixed approaches arose - components were written along with JavaScript which made them more interactive. We could use the component and rely on the framework to invoke our callbacks. Those were JSF, GWT and later Vaadin, ZK.

Using this approach meant that you could create a more or less interactive JS-rich app. But if you needed to change something in the component (and those components weren't very pretty), then you'd have to learn HTML/CSS/JS and how to build components in that framework.

Today we tend to separate UI from Server almost completely, which allows developers to have a narrow specialization (whether it's a good thing or not) and not bother with each other tech stacks. So now it's the browser who's responsible for HTML generation and BE only supplies data.

But all these approaches are viable - you can implement any kind of app with any approach.

Technical differences

Client side pages pro's:

1. You take away some of the load from the server. It doesn't need to bother with page generation.
2. You don't have to load extra HTML on each screen transition. Now you can build SPA (or close to it) which only loads data (could be JSON, could be binary).
3. And thus the app becomes more interactive

Server side pages pro's:

1. You don't have to do extra HTTP queries. SPA apps first load the initial HTML, then they invoke server endpoints for data (could be multiple requests). So the initial load is faster if you generate pages on Server.
2. If done properly you can cache the whole page for some time. Thus the page will be loaded very quickly and no one had to spend CPU generating it.
3. More SEO engines will be supported. In case of Client Side generation to index the page bots have to execute JS which is more complicated and much more time consuming. Google is fine with executing JS, but I don't know how many SEO engines do this.

Answer 2

There isn't any ordinary server-side web application that I know of that you couldn't convert to a frontend web application talking to a backend API, if you so desired. Like everything else in software development, it depends on which tradeoffs you want to optimize for.

As an example of software that is better suited to the backend, look no farther than Amazon Web Services. It's unlikely that you would want any of the services offered there running in your browser instead of Amazon's servers. The whole point of consolidating services as Amazon has done is to take advantage of the economies of scale and other factors that make working in the "cloud" so advantageous.

Answer 3

In developing countries many have very old smartphones. A super fancy SPA APP might be run very well for the majority because weak CPU/RAM on phones. SSR might work better there.