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

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

deno.com

Post reply on HN
Print view View original

61–70 of 371 posts

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

#61

Post by recursivedoubts »

deniz-a wrote: post #48
recursivedoubts wrote: post #15

I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness. An alternative approach is to retain the…

In the sample code, there is no "streaming" going on -- the server simply uses the client code as a template to generate HTML and sends it as a normal HTTP response. In pseudocode: import "client.js" as client on request: document = new ServerDOM(), client.render(document, data), respond with document.toHtmlString() > I don't understand why it isn't "true" SSR This article seems to be using the term SSR exclusively i…

Ah, I thought there was some sort of diff-and-send going on to the client.

I do know there are folks using htmx and deno (we have a channel on our discord) so I don't want to come across as oppositional! Rather, I just want to say that "normal" SSR (just creating HTML) can also be used in a richer manner than the plain HTML example given.

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

#63

Post by nawgz »

shams93 wrote: post #41
trollied wrote: post #17

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

yeah people demand this overkill without understanding what they are demanding. Everyone seems to use react so we must also use react, then the site no longer works for mobile so then you also need react native. All when you can use vanilla js to do the small bits needed for a PWA from one simple codebase.

> then the site no longer works for mobile

What a comical misunderstanding, only to use it to demand people stop using frameworks. You seem to have said it best

> people demand ... without understanding what they are demanding

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

#64

Post by [deleted] »

trollied wrote: post #17

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

[deleted]

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

#65

Post by IanCal »

jhp123 wrote: post #35

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the c…

> but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work

Removing or shortening round trips absolutely removes work. Sending you a page, letting you parse the JavaScript, execute it to find out the calls to make, sending that to the API, the API decoding it and pulling from the database, rendering the JSON and returning that, you parsing the JSON, executing the JavaScript and modifying the DOM

Vs

Pulling from the JSON and rendering the HTML, sending it to you to render

Seems like the latter has less total work.

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

#66

Post by somehnguy »

blobster wrote: post #33
anonymousDan wrote: post #27

Is SSR still much better for seo?

Yes. There's a separate queue for sites that need js rendering and it eats much more into your crawl budget. Best way to avoid it imo is to use something like Rendertron, which is made and recommended by Google.

https://github.com/GoogleChrome/rendertron appears to be deprecated and no longer recommended by Google. They are now recommended basically what this article is about.

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

#68

Post by jasonlotito »

trashburger wrote: post #25
ArcaneMoose wrote: post #24

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.

The argument against this is the cost of a user's bandwidth. If I have all the computation done on the server side, then I have to wait for the round trip every single time just to download the results. In this case, the browser's compute is more free, as the cost to send a remote request is more than likely higher.

Like most things, there is no simple right answer, and it depends on what you are doing. But blindly assuming the experience will be worse using CSR is as silly as assuming SSR will always be worse as well.

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

#69

Post by IanCal »

szastamasta wrote: post #60

I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding. I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.

> Why can’t we just use public CDNs is beyond my understanding.

Privacy issues iirc. I think you can use the setup to introduce tracking/reveal information about your history.

Post reply on HN