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

171–180 of 371 posts

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

#171

Post by ketralnis »

w4eg324g wrote: post #167

Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...

Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is

    {"comment": {"body: "lol"}}
notably expensive than

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

#173

Post by namaria »

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

Just not always a good reason. You're not breaking ground here by having stumbled upon the concept of causality.

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

#174

Post by the_gastropod »

robertoandred wrote: post #154
silver-arrow wrote: post #123

Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/

So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?

Versus the overwhelmingly common SPA counterexample where any change in the UI means sending a request to the server, waiting for it return your json response, parsing that json response, building html out of that json response, and updating the dom.

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

#175

Post by w4eg324g »

ketralnis wrote: post #171
w4eg324g wrote: post #167

Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...

Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is {"comment": {"body: "lol"}} notably expensive than

I assume a modern webpage has some logic to it which besides the redering also needs to be processed and if you apply that to a scale of billions x years I guess yes. But as I said I'm not an expert in the field nor have I any numbers. It's just what I thought.

Edit:

Thinking of having only to serve a state once and having each action processed on the client side instead of making for each a call the backend which has to return a fully rendered page.

Maybe I have a misconception goin on here!

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

#177

Post by Dalewyn »

kitsunesoba wrote: post #144
Havoc wrote: post #90

Earlier quoted context omitted.

>Offloading the computing means the users have a worse experience Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device

Depends on the complexity of the page. A lot of sites with heavier JS and SPAs eat a lot of memory which can cause problems for users of the many laptops out there with 4/8GB of RAM, as well as many smartphone users who have 2GB of RAM or less. In the case of the latter visiting a heavy website can be enough to prompt the OS to kill some other app to make memory available, which means in that situation one's site is…

That's a problem with the dingus that wrote all that JavaShit, not a problem with the end user's computer.

We have 20+ core consumer-grade CPUs and double- to triple-digit RAM and the internet at-large (read: Web2.0) still runs like it's the 1970s.

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

#178

Post by cafebean »

ketralnis wrote: post #171
w4eg324g wrote: post #167

Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...

Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is {"comment": {"body: "lol"}} notably expensive than

Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.

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

#179

Post by Existenceblinks »

advisedwang wrote: post #58

This is why I'm really excited about htmx [1]. No need to write isomorphic javascript at all. You can still use server side templates but have interactive web pages. [1] https://htmx.org/

It's a banger for docs type of site. All html partial pieces are pre-generated and put in cdn. Sort of like how search utilizes index stuff.

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

#180

Post by ttymck »

bigmattystyles wrote: post #164

If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…

What difference does it make, with respect to security, whether the server returns html or json that needs to be formatted into html?

The computation for rendering (in every case I've seen, and I have to speculate in 80% of cases ever) is so trivial compared to the actual retrieval of the data to be rendered.

Post reply on HN