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

41–50 of 371 posts

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

#41

Post by shams93 »

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.

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

#42

Post by spiffytech »

computing wrote: post #5

"The future of the Web is what suits our business model" /s But in all seriousness, the web has websites, it has apps, it has games. Pick a tool that's appropriate for the job and forget about what is the past/present/future.

The rise of metaframeworks is interesting because it brings nuance to this. The line between site and app can be blurry.

For example, my app has a main screen that needs to be client rendered. It also has a user settings screen that could be implemented as a traditional server rendered page with no JavaScript, except it's a lot more practical to build everything inside the same project and technology. Apps and their marketing pages are often put on different subdomains for the same reason.

Metaframeworks that blend rendering modes help users get a lighter page load where appropriate, with less developer effort.

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

#43

Post by superkuh »

seydor wrote: post #10

I think it's a bit ridiculous to call it "server side rendering". It is called HTTP

It is ridiculous. It's pretty much newspeak. Like calling installing applications "sideloading" when you're not using some megacorp's walled garden. Also, I'd say "HTML" not "HTTP". What's HTTP(/3) these days is not what HTTP(1.1) was in the past.

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

#44

Post by altdataseller »

revskill wrote: post #31
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.

I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :) Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.

Trust me. Nobody is jealous of that stuff :)

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

#45

Post by revskill »

altdataseller wrote: post #44
revskill wrote: post #31

Earlier quoted context omitted.

I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :) Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.

Trust me. Nobody is jealous of that stuff :)

Trust me, everything exits for a reason, to solve (maybe specific problem). It's nonsensical to want it to die for "no reason".

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

#46

Post by HideousKojima »

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.

What is caching?

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

#47

Post by altdataseller »

revskill wrote: post #45
altdataseller wrote: post #44

Earlier quoted context omitted.

Trust me. Nobody is jealous of that stuff :)

Trust me, everything exits for a reason, to solve (maybe specific problem). It's nonsensical to want it to die for "no reason".

Not arguing they aren't useful. Just that no backend dev is ever jealous of what's happening with front end frameworks.

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

#48

Post by deniz-a »

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 in the frontend framework sense, where client code is run on the server. It's not how I use the term but it is a common usage.

Another possible reason that the htmx approach isn't discussed: the any-server-you-want nature of htmx is terrible for selling Deno Deploy :]

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

#50

Post by JayStavis »

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.

Point certainly taken but I think that "rendering" is the overloaded term.

Rendering basically means, to take data & logic and transform it into a view for another system (or person).

Graphical rendering is probably the needed operative word for this point? A bit of annoying semantics but I think rendering just means to provide a structured view for some state.

Post reply on HN