Ask HN: Why server side rendering is not used anymore

27 points by stdcall83 3 years ago | 34 comments

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 ?

cmer 3 years ago |

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.

arinlen 3 years ago | |

> Hype. That is why.

I'm not sure this personal assertion holds any water. Think about it for a second. You need to have a front-end, and you have to pick your tech stack. You know all you need is to render a nice page with some user interaction support and some automation. You have a small team of front-end developers to pull that off.

What are you going to pick?

Is it a good idea to force upon your team a full stack tech stack which forces front-end developers to develop and deploy backend code just to see a basic html+JavaScript page load?

Do you need to bother about Java/python/ruby/PHP/whatever just to have a button showing up in a browser?

Or is it simpler to just let your frontend team deploy their html+JavaScript resources in a file server and just get rid of any server development from their equation?

> 99% of web applications don’t need to be SPA.

Meanwhile, reality shows that close to 100% of web applications don't need to be dynamic HTML/server-side rendered colossal apps, and are better off as SPAs.

lmarcos 3 years ago | | |

You mention "frontend team", "server development", "backend code"... But it's all just programming, we are all just programmers (or problem solvers). We can use HTML today, Python tomorrow, and SQL on Fridays. You can learn K8s during spring, and focus on Go during winter time. On summer better to improve your Pinia skills, while on autumn one should read SICP. Christmas time is for bash, though.

Unfortunately, "modern" IT companies do make the distinction between "frontend" programmers, "backend" programmers, etc. They do this not because it's better for us (the programmers), but because it's cheaper for them. If you care about your career, do not specialize. On the other hand, if you only care about your job, then sure go ahead and become a "frontend" (or "backend") master.

manigandham 3 years ago | | |

This doesn't make any sense. You don't need to "develop and deploy backend code" if there's no backend logic for these pages.

The frontend is just HTML/CSS and there are many templating languages that can be used. Any competent front-end dev should be able to handle this.

> "reality shows"

What reality exactly?

ostenning 3 years ago | |

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.

cercatrova 3 years ago |

It is, now. NextJS, Gatsby, Remix, Astro, Deno's Fresh are all frameworks that prioritize server side rendering in the server-Javascript world, rather than client side single page apps from a few years ago.

Comevius 3 years ago |

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.

drKarl 3 years ago |

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

cweagans 3 years ago |

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.

potamic 3 years ago |

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.

stdcall83 3 years ago | |

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

toast0 3 years ago | | |

At risk of being that guy on HN, this looks like the kind of thing that you would run and generate a static html and always use the same css.

If you're not happy with the perl tool, I'd run it to get all the HTML, then build a new tool in your favorite language that reads through the same source material and generates similar HTML (you can fix stuff you don't like as you go along, but don't change too much if the goal is to just get it done). I'd give an experienced developer about a week, or an average intern a month or three, assuming there's some hidden complexity, but not too much.

I'm not surprised software solutions companies aren't going to bid on a project that's 40 hours of work. And that you got someone to build a monstronsity instead.

zumu 3 years ago |

You certainly can write snappy ergonomic apps that do the SPA thing (the server/client scheme you mentioned). It is very popular for consumer facing apps. Unfortunately SPA's are a little bit more complicated, and it sounds like they made a mess of it. While I don't know the details, it very possible that your internal tool could have been a much more straightforward SSR app.

quickthrower2 3 years ago |

The slow, hard to maintain and high priced are the features of a terrible consultancy.

There is no reason any of that should be the case for a client side rendered app these days if good people build it.

But getting good people in any trade is a perennial problem.

maxhille 3 years ago |

You are going to build the view agnostic API anyway for Android and iOS. So why not use the same API for the web app, too?

rk06 3 years ago |

No, the developers you picked were wrong. You need high quality devs to create high quality sites

joshxyz 3 years ago |

because json format is better for client server communication instead of html text.

lots of things to do when your data is a js object.

fzfaa 3 years ago |

Because people write code in terribly slow languages so they would have to have many more servers which is more expensive if they used server-side rendering.

antioppressor 3 years ago |

If you see React, just run.