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

1–10 of 35 posts

Ask HN: Why server side rendering is not used anymore

#1

Post by stdcall83 »

For an internal tool at our company that served a website with register schema of SOC (derived from IPXact XML's) we used an old tool written in perl that was very hard to maintain.

I took it upon myself to contact few software solution companies to rewrite the tool in a modern language and add few features.

All the companies dissmised server side rendering and suggest a server - client scheme based on NodeJS on the server and React / Angular on the client.

After proceeding with one of the companies, the end result was slow, very hard to maintain and every new feature was very highly priced.

We're in a worse situation than we were.

Was is a bad selection of technology for the specific use case ?

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

#2

Post by drKarl »

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 hired didn't do a great job...

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

#3

Post by Comevius »

There are great progressive server-side rendering libraries out there these days, but most companies are shoddy and have no reason to care about their craftsmanship. They make money either way, and lots of it. If you really care about quality you build it yourself, it's that simple.

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

#4

Post by potamic »

What are SOC applications like? Generally for rich web applications with a lot of interactivity, you want to do client side rendering. Interactive apps can be deceptively complex to build and you really want to hire the right people for it. The spectrum of web developers you can find in the market is very wide which doesn't make it easy to find the right people. It also doesn't help that consultancies generally want to stick with the hottest, bleeding edge tools to stay relevant in the market and to motivate developers to come work for them.

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

#5

Post by stdcall83 »

potamic wrote: post #4

What are SOC applications like? Generally for rich web applications with a lot of interactivity, you want to do client side rendering. Interactive apps can be deceptively complex to build and you really want to hire the right people for it. The spectrum of web developers you can find in the market is very wide which doesn't make it easy to find the right people. It also doesn't help that consultancies generally want…

Esentially something like this: https://www.xilinx.com/htmldocs/registers/am012/am012-versal...

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

#6

Post by jqpabc123 »

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

Someone must have lied to you or forgot to explain WebSockets.

Before WebSockets existed, some of us would use a hidden background frame to load server rendered code with a simple "onload" script to move it to the forground replacing only the portion that needed updating.

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

#7

Post by drKarl »

jqpabc123 wrote: post #6
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 Someone must have lied to you or forgot to explain WebSockets. Before WebSockets existed, some of us would use a hidden background frame to load server rendered code with a simple "onload" script to move it to the forground replacing only the portion that needed updating.

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...

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

#8

Post by mtberatwork »

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…

You certainly do not need to build out an entire SPA or use React to reload part of a page just to swap in some HTML or load something asynchronously in the background.

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

#9

Post by codegeek »

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…

"That is not only slower but it also feels slower to the user"

Not always the case and in many cases, server side rendering is totally fine and has been for decades. We need to stop suggesting that only 1 solution is correct. SPAs have a place but plenty of use cases can do fine with old school server side renders.

I think SPA were cool and with all the frameworks, it became even cooler to just do more client side work BUT don't forget that there are plenty of studies now that have shown that SPAs are not always the correct and magical answer and in many cases they are actually slower.

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

#10

Post by tailspin2019 »

drKarl wrote: post #7
jqpabc123 wrote: post #6

Earlier quoted context omitted.

With server side rendering you have to reload the whole page everytime Someone must have lied to you or forgot to explain WebSockets. Before WebSockets existed, some of us would use a hidden background frame to load server rendered code with a simple "onload" script to move it to the forground replacing only the portion that needed updating.

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)

Post reply on HN