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

321–330 of 371 posts

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

#321

Post by zeroonetwothree »

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.

I don't see why we should assume the server is faster at processing the input data into HTML than the client is. It could very easily be that the client device does this faster. SSR additionally prevents progressive rendering, since you must generat eall the HTML ahead of time, which can make pages feel slower. Also HTML+JS data size can be larger than data+JS size (and you /may/ need the data anyway for the SSR version to do hydration). Of course all this varies, which is why it's silly to claim a general principle.

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

#322

Post by dan1234 »

throwawaymaths wrote: post #316
movedx wrote: post #274

Earlier quoted context omitted.

Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies? How about you try it and see?

By chuck away I mean all those processor cycles to perform cryptographic verification... And then throw away the result because you have to do it on the next connect anyways And I have written a library that does the full SSL handshake/upgrade cycle off of tcp sockets, and managed my own private CA, so I'm not a total idiot.

Isn’t that mitigated with TLS session resumption and TLS 1.3’s 0-RTT?

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

#323

Post by simonhorlick »

WuxiFingerHold wrote: post #303

There are only few use cases, where the new kind of SSR (with hydration) is worth it. An example are e-commerce sites where you want the customer to see all your great products as soon as possible and then some seconds later to be able to interact with your side fluently to buy something. These kind of scenarios paired with low end devices are the only proper use case. And I say consciously "only proper" because SSR…

Have a look at Qwik, it’s a new framework from the author of Angular. It does SSR without the need for client-side hydration. It’s fast and immediately interactive.

I’m really hoping it gains some momentum because I’d love to use it in some client projects.

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

#324

Post by javaunsafe2019 »

theappsecguy wrote: post #224
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...

Compute power is absurdly cheap these days, especially for something as simple as SSR of web pages

Woot sorry but have you ever used any cloud provider like AWS? Processing time and bandwidth are the things you try to avoid in order to avoid unnecessary expenses.

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

#325

Post by kaba0 »

throwawaymaths wrote: post #316
movedx wrote: post #274

Earlier quoted context omitted.

Huh? How does HTMLx "chuck" away SSL (you meant TLS, right? I hope you're not using SSL) and encrypted cookies? How about you try it and see?

By chuck away I mean all those processor cycles to perform cryptographic verification... And then throw away the result because you have to do it on the next connect anyways And I have written a library that does the full SSL handshake/upgrade cycle off of tcp sockets, and managed my own private CA, so I'm not a total idiot.

How is that different than all the other CSR SPAs that do a REST call on every button press as well? They do almost the same amount of work, and will also “throw away” the results.

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

#326

Post by Alifatisk »

slimebot80 wrote: post #314

Note: Remix is not built on React, as the article states. Of all the new ways of thinking, Remix is the leader in not promoting a specific paid delivery platform. So in that sense I can see why people might want to mitigate its advantages by trying to tie it to React. (having said that, Shopify might tie it down more, but I see no evidence so far)

I thought Remix was buiit on top of React? Like Nextjs.

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

#327

Post by javaunsafe2019 »

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…

Wow, big claims of gains without any proof. Why?

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

#328

Post by kaba0 »

dmitrygr wrote: post #238
silver-arrow wrote: post #165

Earlier quoted context omitted.

Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…

How well does their example work over satellite internet with 1.2sec latency? How about my cell connection when T-mobile throttles me to 64Kbps for going over my data allowance? How about my sister's cell connection, as she is on an MVNO and deprioritized sometimes to 128Kbps, sometimes to 6Mbps, and sometimes it varies within a minute between those two? FFS, people, learn to write proper software that does everythin…

And what kind of apps are you using? You think Amazon and whatever else doesn’t also start a rest call on basically every action, many of which are “blocking” the UX?

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

#329

Post by KronisLV »

kaba0 wrote: post #170
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…

Slightly off topic, but I found JSF the most productive out of any framework. It has some not so nice edge cases, but when you are “in the green” and you don’t need to scale to infinity (which, let’s be honest, is the case most often than not) it really is insanely fast to develop with. For internal admin pages I would hardly use anything else.

> Slightly off topic, but I found JSF the most productive out of any framework.

In my experience, it has been a horrible technology (even when combined with PrimeFaces) for complex functionality.

When you have a page that has a bunch of tabs, which have tables with custom action buttons, row editing, row expansion, as well as composite components, modal dialogs with other tables inside of those, various dropdowns or autocomplete components and so on, it will break in new ways all the time.

Sometimes the wrong row will be selected, even if you give every element a unique ID, sometimes updating a single table row after AJAX will be nigh impossible, other times the back end methods will be called with the wrong parameters, sometimes your composite components will act in weird ways (such as using the button to close a modal dialog doing nothing).

When used on something simple, it's an okay choice, but enterprise codebases that have been developed for years (not even a decade) across multiple versions will rot faster than just having a RESTful API and some separate SPA (that can be thrown out and rewritten altogether, if need be).

Another option in the space is Vaadin which feels okay, but has its own problems: https://vaadin.com/

Of course, my experiences are subjective and my own.

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

#330

Post by arcanemachiner »

spiffytech wrote: post #147
arcanemachiner wrote: post #132

Earlier quoted context omitted.

Pardon my ignorance, but what do you mean by metaframework? I just learned about Astro the other day. It allows you to blend components from SPA frameworks together. Is that what you mean?

'Metaframework' is a term for frameworks that wraps React or Vue or similar. Next.js, Nuxt, Gatsby, etc. I think Astro is considered a metaframework too. They're sometimes called stuff like "a React framework", depending on whether the speaker considers React a library or a framework.

Ah, that makes sense. Thanks.
Post reply on HN