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.
Ask HN: Why server side rendering is not used anymore
21–30 of 35 posts
Re: Ask HN: Why server side rendering is not used anymore
#22Earlier quoted context omitted.
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, bu…
Connection drops have not been as big a deal as I would have expected. But Blazor takes care of that for client side detection, automatic reconnecting, and providing hooks for showing a basic "connecting" UI. There's not a lot you have to implement yourself - the websocket transport is largely abstracted away (unless you specifically want to dig around in there).
That said, I've polished off some of the rough edges with some additional handling. For example, if the user is not directly interacting with the app right at that second of a connection drop, I won't immediately show a loading indicator, so there is no visible difference in the app UI (it just looks like everything is still fine). If the connection reconnects before they interact with it again, they'd never even know it dropped, if it doesn't I then show the loading indicator (which appears after a second or two in any case if the connection is taking longer to reconnect).
If you can cope with the slightly different paradigm of an always connected socket, there are huge upsides to using this framework, and the dev loop can be very fast with hot reloading etc.
Re: Ask HN: Why server side rendering is not used anymore
#23Hype. 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.
> 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.
Re: Ask HN: Why server side rendering is not used anymore
#24Earlier 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...
Phoenix LiveView and similar tech would like to join the chat
Re: Ask HN: Why server side rendering is not used anymore
#25You 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.
Re: Ask HN: Why server side rendering is not used anymore
#26The 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.
Re: Ask HN: Why server side rendering is not used anymore
#27You 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?
Re: Ask HN: Why server side rendering is not used anymore
#28Hype. 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.
> 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 stac…
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?
Re: Ask HN: Why server side rendering is not used anymore
#29With 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…
HackerNews, the site you're reading right now, uses server-side rendering. Even for voting. And yet it's incredibly fast and more usable than most SPAs. I'm sure you've also used StackOverflow at some point, which is another incredibly fast and responsive SSR site.
There are also many "partial" update mechanisms from XHR/fetch + innerHTML to slim frameworks like AlpineJS/HTMX to newer SSR live rendering like Blazor/LiveView/Hotwire.
Re: Ask HN: Why server side rendering is not used anymore
#30Earlier 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...
Why not? What about a "rich web application" means it shouldn't or can't have a connection open?