Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why server side rendering is not used anymore

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Ask HN: Why server side rendering is not used anymore

#11

Post by mrdoops »

drKarl wrote: post #2

With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you…

Phoenix Liveview and the many other copied featuresets in other web frameworks are sending dom diffs over a websocket connection where a tool like morphdom will render only the necessary changes to the page.

This sort of architecture for static rendering is a big deal because it gives live page updates in a way that is SEO friendly and significantly less complex for development than SPAs are.

Re: Ask HN: Why server side rendering is not used anymore

#12

Post by bmcahren »

drKarl wrote: post #2

With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you…

Node/React/VueJS SSR apps are a benefit to the user and do no such thing. SSR for React uses your heavyweight servers to pre-render the initial HTML. Thereon it's an SPA again, it's just seeded with the SSR results. In-fact, if the client determines the seed data for state/html can't be used it will be abandoned and the client will render by itself. This can happen when your state model isn't intact or if you have differing versions of client and server. You can have certain modules entirely render on the backend by choice but it's not mandatory.

Re: Ask HN: Why server side rendering is not used anymore

#13

Post by naikrovek »

drKarl wrote: post #2

With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you…

> With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data.

this is not true, and if the collective "full stack" community believes this, I feel like I suddenly have a very good understanding of why websites, and more generally the web tech stack itself, sucks so much these days.

Re: Ask HN: Why server side rendering is not used anymore

#15

Post by gkhartman »

tailspin2019 wrote: post #10
drKarl wrote: post #7

Earlier quoted context omitted.

Maybe someone lied to you... With websockets you have to keep the connection open, so it would be great to build a chat but not so much for a rich web application...

Blazor Server is a pretty good websockets based framework for rich web applications. (Source: I have one deployed as a SaaS app)

I've wanted to try this, but that connection drop issue sounds like a deal killer when serving page data when compared with ajax polling. How does it handle connection failure? I've worked on event based software for desktop/mobile where the best case was to detect the connection drop on the client side then show a "reconnecting" message while it tries to regain it's websocket.

It usually sounds easy to implement, but comes with more edge cases than you'd expect.

Re: Ask HN: Why server side rendering is not used anymore

#16

Post by ostenning »

bmcahren wrote: post #12
drKarl wrote: post #2

With server side rendering you have to reload the whole page everytime there's an update on some data or if you want to submit data. That is not only slower but it also feels slower to the user. With SPAs you only reload the part of the page that has some data changing which loads asynchronously in the background, so it's not only faster, it also feels faster. If your new implementation is worse maybe the company you…

Node/React/VueJS SSR apps are a benefit to the user and do no such thing. SSR for React uses your heavyweight servers to pre-render the initial HTML. Thereon it's an SPA again, it's just seeded with the SSR results. In-fact, if the client determines the seed data for state/html can't be used it will be abandoned and the client will render by itself. This can happen when your state model isn't intact or if you have di…

Or data that is serialized from the server to the client isn't consistent on both sides leading to differences in rendered output

Re: Ask HN: Why server side rendering is not used anymore

#17

Post by ostenning »

cmer wrote: post #14

Hype. That is why. 99% of web applications don’t need to be SPA. And the majority of the other 1% probably need just a fraction of their app as SPA. Rails gets it right with a Hotwire IMO.

Definitely feels that way. I would choose Rails today because its an older technology with a proven track record. Companies tend to go with hype technologies because thats what developers want to learn and so there are more hiring possibilities, I suppose.

Re: Ask HN: Why server side rendering is not used anymore

#19

Post by cweagans »

Server side rendering is still used a _lot_. Wordpress, for instance, is a double digit percentage of the web. It's not the JS package du jour though, so it doesn't get as much hype.

If you step out of the JS ecosystem (especially as it relates to server-side code), you'll still find a _lot_ of SSR.

Post reply on HN