Live data from Hacker News

The future (and the past) of the web is server side rendering

deno.com

21–30 of 371 posts

Re: The future (and the past) of the web is server side rendering

#21
Mindshare will go towards rendering javascript components on the server since that's another complex problem that's fun to solve. That's good! We shouldn't have to give up the productivity gains of tools like React to improve time-to-interactive and other performance stats.

That said... I'm not going to pretend it's an urgent need and will wait for these tools to mature.

Re: The future (and the past) of the web is server side rendering

#22

“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.

I'm of two minds. I want agree with you of well formed DOM for the browser to render. That's great. Now, do we have to go all the way back to flat files where the whole page has to refresh to update one silly field or selection update? No, we don't have to go full cave man for that. We can still use the front end to make changes after the initial load. we don't need an app to be running in each user's browser for a large majority of places where this is happening.

Re: The future (and the past) of the web is server side rendering

#23
post #2

And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…

The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts.

This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.

Re: The future (and the past) of the web is server side rendering

#25

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.

Re: The future (and the past) of the web is server side rendering

#28

The issue I have with SSR is that it offloads processing power onto the server. That means I have to pay more as the host instead of relying on user's browser to handle the compute "for free".

The problem with this idea is that the user's browser's compute is not "free". Offloading the computing means the users have a worse experience, which will affect your userbase and page rankings.

That sort of depends. If the compute needs to happen regardless and now you add a layer of shipping data to and from the server, that could add even more latency and make for a worse experience.

Re: The future (and the past) of the web is server side rendering

#29
My first contact with HTTP and HTML forms was an immediate throwback to my mainframe experience. The browser was like a supermodern 3270 terminal, getting screens from the server, sending data back, getting another screen and so on.

There were a number of products that allowed a web app to maintain a 3270 connection to the mainframe and render the terminal screens as an HTML form. Fascinating stuff.

Re: The future (and the past) of the web is server side rendering

#30

“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.

Basically, by those standards, ngnix is the most popular server side renderer ATM. It can beautifully render HTML and pretty much any file format. It can even render video files and with Ngnix plus, you get bit more server side rendering for vidoe files too.

Apache used to be a good server side renderer too but those were the old days.

Post reply on HN