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

231–240 of 371 posts

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

#231

Post by superkuh »

forgotpwd16 wrote: post #112
superkuh wrote: post #39

Earlier quoted context omitted.

I'm probably not in your target demographic but when a website pushes computation to me for simple things like displaying text and images I close the tab.

>when a website pushes computation to me for simple things like displaying text and images I close the tab How will you even know without looking at the source or blocking JS across the web? Like, sure, if they've fancy animations across all elements from the moment you open the page should be obvious. But what about something like https://rhodey.org/ ? It opens instantaneously in my ancient laptop connected to a ter…

I block JS across the web by default. For some sites I'll learn the miminum set of domains to allow for temporary whitelisting. But most aren't worth the effort.

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

#232

Post by verdverm »

szastamasta wrote: post #60

I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding. I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.

You can CDN your own bundles which include your libraries without much issue. You don't even have to really CDN them as much as make them cache friendly (name them with hash) and set the TTL to 30d. Download once then the browser will keep a copy for future page visits

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

#233

Post by Schiendelman »

guhidalg wrote: post #215
zelphirkalt wrote: post #182

Earlier quoted context omitted.

> Isn't it also nice from a computation cost standpoint to let the client do the rendering? Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.

No? Each client may be receiving the same document, but based on their device, view port, preferences, etc… the rendered result may be different. Either way, the measurement of Joules/page is likely to be such an astronomically small number compared to the constant cost of simply having a server at all IMO.

The number of devices is very small. I’m sure you get a number of different window sizes, but within a range, you can very slightly scale.

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

#234

Post by Groxx »

zelphirkalt wrote: post #182
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.…

> Isn't it also nice from a computation cost standpoint to let the client do the rendering? Aside from all other implications, letting each client render the same stuff is a massive waste of energy and compute.

Client-side json-to-html is such a microscopic part of the compute cost related to showing a change in a website that it's a rounding error. Totally inconsequential. A single widely-used inefficient css attribute or repaint costs WAY more.

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

#235

Post by Implicated »

TrispusAttucks wrote: post #212
cafebean wrote: post #178

Earlier quoted context omitted.

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

It already exists for several popular frameworks/languages. One example is [1] Laravel livewire. [1] https://laravel-livewire.com/

Can confirm, livewire is like _magic_.

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

#236

Post by ColonelPhantom »

robertoandred wrote: post #218
the_gastropod wrote: post #200

Earlier quoted context omitted.

Yep. DOM manipulation can be done to server-rendered views to do that kind of thing, just fine. No SPA js framework required.

So now you've got two templates? How do you keep modifications in sync?

Personally I would use htmx and roundtrips for all sorts of modification including data (such as reorganizing two rows in a table). But you'd also do that in an SPA, right? How do you prevent desyncs there? Also for e.g. sorting you'd need a server roundtrip anyway in the (likely) case where you use something like pagination or lazy loading.

For sending data, you would just have a reply that instructs HTMX to display a success message. On an SPA you'd have the same. With both, you can interact with the page while the data is being sent.

Of course, sometimes you want purely 'cosmetic' actions, such as an "add row" button that pops open some data entry fields. For something like that you should not use htmx itself, but instead basic vanilla JS or a simple library such as https://alpinejs.dev/ which complements htmx nicely for client-side stuff.

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

#238

Post by dmitrygr »

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

Earlier quoted context omitted.

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?

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 everything locally!

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

#239

Post by anthk »

shams93 wrote: post #41
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.

Simple CSS files can solve that.

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

#240

Post by anthk »

superkuh wrote: post #43
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.

Discord "server".

The amount of ignorance of the newer generations it's astounding.

They keep reinventing the wheel over and over.

Post reply on HN