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

341–350 of 371 posts

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

#341

Post by trashface »

simonhorlick wrote: post #323
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.

Author of angular is a real red flag after that whole angularJS -> angular 2.0 "transition". Worked at a company that spent a bunch of money on contractors trying to get a big angularJS app ported, they never fully completed it, and at the point I left it still had both versions running in the same app. What a nightmare.

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

#342

Post by DangitBobby »

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…

There comes a point in a project where the amount of client-side features requested makes you wish you had started with a fully-fledged modern framework like React. New features could be a single React component plus some updates to existing callbacks, and a new API call, but instead requires adding to a big accreting ball of HTML templates and a hodge-podge of vanilla (and maybe jQuery) js amounting to a bespoke framework that someone had to develop to manage the complexity.

I absolutely love Django and old-style web frameworks, but they are not without their own complexity risks.

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

#343

Post by DangitBobby »

Alifatisk wrote: post #326
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.

Remix is a React framework.

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

#344

Post by mmcnl »

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…

> SSR is always slower than static sites

I don't think this is _always_ true. With SSR you only render the HTML server-side on the first page load. Any interaction after that is just the JSON payload being retrieved and rendered by a JS framework, which is faster than a complete rerender.

Your comparison is valid for first page loads. But usually people visit multiple pages on a website. And then SSR usually wins, though I agree the added complexity is usually not worth it for 100% static websites.

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

#345

Post by mmcnl »

BizarreByte wrote: post #225
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/

HTMX has to be my favourite thing web related. I never really got React and always found it a bear to setup and use, but HTMX and server ride rendering? Easy and extremely productive for a non-frontend guy like me. I really hope it or something like it becomes popular long term.

htmx only seems to make sense if you're coming from backend frameworks and you want to add some sprinkles of interactivity.

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

#347

Post by mmcnl »

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

It's not an issue, it's a trade-off. Do you want your users to experience faster initial page loads? If yes, then the cost might be worthwhile. If not, then not. Especially in ecommerce it's well worth the cost.

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

#348

Post by mmcnl »

Havoc wrote: post #90
trashburger wrote: post #25

Earlier quoted context omitted.

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.

>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

Yes, a lot. Time to first contentful paint is way worse with CSR vs SSR. Takes some time to download and run these JS bundles.

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

#349

Post by mmcnl »

zeroonetwothree wrote: post #321

> 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 ma…

Performance is not _only_ determined by the processing time. Downloading the JS bundle and parsing it takes a lot of time. There's no need for that on the server. First page load is always very slow for CSR. Any client-side navigation after that is fast. SSR has a low initial page load and uses client-side navigation after that.

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

#350

Post by albertopv »

"A fully server side rendered version with isomorphic JS and a shared data model"

Seriously, how did we get there? Having dealt with jsp, jsf (myfaces, trinidad, adf...), asp.net, asp mvc, angular, plain html/css/js, how is is possible for FE web dev to be such a mess? So much complexity, for what? How many have to deal with millions of visit per day? Or even month? It seems to me history is quickly forgotten and new generations know very little about the past.

Keep it simple, please.

Post reply on HN