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

251–260 of 371 posts

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

#251

Post by codingkoi »

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.

I haven’t used it recently but I believe it sets a header on the request when it comes from HTMX so you can change whether you send the whole page or just the fragment back.

You can also just send the whole page and use other features to select just the part that you want to update (obviously that has a cost of sending the whole page though).

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

#253

Post by dmitrygr »

simonw wrote: post #249
dmitrygr wrote: post #238

Earlier quoted context omitted.

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…

All of the environments you describe there sound to me like they would benefit from web apps that become responsive after an initial page load of less than 100KB, followed by ~10KB round trips to the server to fetch additional data. As opposed to the >2MB initial page loads that have become so common with heavy React SPAs in exchange for the theoretical benefits of avoiding more page loads for further interactions.

They benefit from a .exe (or a .tar.gz or a .apk) downloaded when convenient and run locally

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

#254

Post by eric4smith »

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 for businesses in this era who have to get to revenue faster.

And that’s why things like Phoenix LiveView and its counterparts in other languages is catching on so quickly.

People are getting fatigued with the latest flavor of the month JS framework.

But what do I know… I’m just a lowly “developer” working for crumbs. Never even finished a CS degree. Sigh.

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

#255

Post by tiagod »

unity1001 wrote: post #244
tiagod wrote: post #211

Earlier quoted context omitted.

I don't understand how jQuery and direct DOM manipulation is in any way better than something like Svelte for a modern Web app, especially something like a store.

Because what most websites, ecommerce stores need per any given view/page are a few unique, isolated jQuery functions to manipulate what is strictly necessary. Be it listing a category listing of products, be it adding to cart by clicking a button, be it updating quantities in cart, address or payment. The 'modern' frontend frameworks take way too much after frameworks like React that were born from social networks i…

Thats not what modern frameworks are evolving to, though. Svelte doesn't have a "touch everything" approach like React. Interactions are compiled at build time and only the JS needed to change the specific things that aren't static is generated. There is no runtime.

With jQuery on the other hand you're bundling a whole bunch of stuff you probably don't need to do things modern vanilla JS is perfectly capable onlf. And you'll have to reinvent the wheel every time either way.

Sure, your simple approach is probably enough for small stores selling a few items, but it really doesn't scale to all of them. And it makes for a way better development experience to use a modern framework for all but the very simplest of interactions.

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

#256

Post by throwawaymaths »

BizarreByte wrote: post #219
robertoandred wrote: post #190

Earlier quoted context omitted.

Sounds pretty slow. At least a second before the UI responds to any action?

It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates. I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering. It won’t be the right choice in all cases, but it’s a g…

It seems such a waste... You're chucking all that cryptography (ssl, encrypted cookies) away only to be redone every. single. Dom change

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

#257

Post by zarzavat »

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 modalities and maintain two sets of tooling (or worse switch in the middle of a project!) I gather this is against the current fashion but whatever.

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

#258

Post by roncesvalles »

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…

Yes it's totally moronic. In fact we should be moving more server-side work to client machines, with WASM and such.

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

#259

Post by amelius »

BizarreByte wrote: post #219
robertoandred wrote: post #190

Earlier quoted context omitted.

Sounds pretty slow. At least a second before the UI responds to any action?

It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates. I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering. It won’t be the right choice in all cases, but it’s a g…

> but of course it comes down to how well your backend is written

Also the latency of your connection matters.

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

#260

Post by duncan-donuts »

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.

I just started using htmx in a new personal project. I’m pretty excited to see how it goes. I’m doing a sort of back to basics stack with PHP, simple classless css lib and htmx. So far it’s been a refreshing experience
Post reply on HN