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

361–370 of 371 posts

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

#361

Post by pas »

BackBlast wrote: post #207

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins. "it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in en…

Mobile cores are usually power/thermal constrained. Still parsing HTML or running an ungodly amount of JS that then spits out that HTML on the device is not that big of a difference, both kill the battery charge fast :)

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

#362

Post by bigDinosaur »

bigmattystyles wrote: post #263
bigDinosaur wrote: post #242

Earlier quoted context omitted.

This is a non-problem in all SSR projects I've ever dealt with.

But how many of the SSR projects you have dealt with had a requirement to enable API access for users? If it's not a requirement, then yea, you're right, it's a non-problem.

Several. I just literally do not see the problem. I'm not saying it's absolutely the most efficient way to do a given project, just that it never was presented as any kind of problem to provide both a SSR app with an API. Obviously you just can't reuse already existing API routes and methods that you would if you had structure it as a SPA but you're likely rendering using SSR from structured data anyway which you can just send as JSON or whatever on a separate route.

I've done this multiple times and it's fine. It's really not an issue for delivering projects. I'm not saying I'd do this every time - if the API was identical for both my app/website and any other clients I'd very possibly abandon the SSR approach for the ease of a frontend API that everyone can use identically, but that's a specific project requirement not a general statement on SSR and API development.

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

#363

Post by boring_twenties »

ranger_danger wrote: post #352
boring_twenties wrote: post #304

Earlier quoted context omitted.

"Has JS disabled" is in itself a good fingerprint factor though.

how would a website inform the server of that fact though?

I dunno, how about ?

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

#364

Post by recursive »

pas wrote: post #360
recursive wrote: post #311

Earlier quoted context omitted.

Huh. Ok. I just didn't know that was a thing. Ok, I guess I don't need analog outputs then. Still nice to have though. Better zero pucks than two.

Hifi geeks don't trust the DAC to something inside the TV, and ... they are not wrong. Plus you can reuse the DAC even if you change the screen.

I'm not an audiophile. I just want something better than what the screen does, and I don't want to buy a soundbar or get into HDMI. And sometimes use headphones.

But still, I'm pretty sure, one day I'm going to get one of these optical -> analog boxes.

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

#365

Post by eric4smith »

zarzavat wrote: post #257
eric4smith wrote: post #254

Most SPA is totally unnecessary and a big waste of time. People are worrying about the speed of SSR when they should be worrying about the developer time on the client which is several orders of magnitude more. I think people have fallen in love so much with complex Javascript frameworks that they’ve forgotten how easy it is to get to an MVP with SSR. Speed is important. Speed of development is even more important fo…

For simple projects it really doesn't make much difference. Depending on your available tools, client-side or server-side rendering might be easier. In the end the only difference is what is going down the wire: data or HTML. That said , client-side rendering is strictly more general than server-side rendering. So I prefer to use client-side rendering everywhere so that I don't have to switch between two different mo…

Makes HUGE difference. All the front-end work is another complete app with all the work that entails.

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

#366

Post by TrispusAttucks »

bigmattystyles wrote: post #265
TrispusAttucks wrote: post #204

Earlier quoted context omitted.

Maybe I misunderstand but it's pretty trivial to render different server side output based on context and is common in most frameworks. Just pass a header for request content type json. Then the server returns data in json format as opposed to html.

but then you'll have a server side path for json and one for html. If I have rendering logic client side entirely, then I just have json / xml on the server. That's it.

No. It's one path. The client merely requests the the format it desires. The response handler on the server side returns the appropriate response format as requested by the client. Nothing crazy here.

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

#367

Post by movedx »

throwawaymaths wrote: post #317
movedx wrote: post #312

Earlier quoted context omitted.

I suppose, but it's not really that big of an effort to just use the correct term for the correct version of the technology.

The certs are generally called SSL certs, not tls certs, too.

> AWS Certificate Manager - Provision and manage SSL/TLS certificates with AWS services and connected resources

Both, I guess.

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

#368

Post by BackBlast »

pas wrote: post #361
BackBlast wrote: post #207

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins. "it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in en…

Mobile cores are usually power/thermal constrained. Still parsing HTML or running an ungodly amount of JS that then spits out that HTML on the device is not that big of a difference, both kill the battery charge fast :)

As I said, servers cores are also power and thermal constrained. A16 is like 50% faster than high frequency latest and greatest Sapphire Rapids single core. 50%.

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

#369

Post by jhot »

satyrnein wrote: post #202
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/

Can the same server side code render that fragment, regardless of whether it's part of the initial page load or a subsequent update? You need an additional route for the Ajax call, right? Just curious how this gets structured.

Most template engines have some form of inheritance making it easy to render just the fragment or include it in a full page based on route.

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

#370

Post by pas »

BackBlast wrote: post #368
pas wrote: post #361

Earlier quoted context omitted.

Mobile cores are usually power/thermal constrained. Still parsing HTML or running an ungodly amount of JS that then spits out that HTML on the device is not that big of a difference, both kill the battery charge fast :)

As I said, servers cores are also power and thermal constrained. A16 is like 50% faster than high frequency latest and greatest Sapphire Rapids single core. 50%.

Businesses are not server-side compute limited. Ask any business basically. They would gladly trade more of their own CPU power & heat for more time on the site/service from their users.
Post reply on HN