Live data from Hacker News

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

deno.com

261–270 of 371 posts

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

#261

Earlier quoted context omitted.

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…

I mean modifications to the template itself. Design changes, copy changes, etc

I go with the core idea of progressive enhancement: your front end code can improve what the server sent it rather than completely replacing it - if your style changes don’t break the semantic meaning, you don’t need to change any of your front end code.

What I typically do is render the first bit of data on the server and have the client JS use that as a for changes or new records. That ensures that anything done on the client always matches without you needing to code cosmetics in multiple places but also means your pages load seconds faster than a SPA because the first view is ready to go. When the user saves the entry, you can swap what you generated with the server response a few milliseconds later.

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

#262
post #180

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

What difference does it make, with respect to security, whether the server returns html or json that needs to be formatted into html? The computation for rendering (in every case I've seen, and I have to speculate in 80% of cases ever) is so trivial compared to the actual retrieval of the data to be rendered.

None really, I was not eloquent about it - just that returning well structured data makes easier to extract data. You could also argue that if you render locally, you might return data used only for rendering that's not output and that also leaves your server's boundary where it wouldn't be necessary to leave at all with SSR. But like you said, these are things that are not really security.

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

#263

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

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.

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

#264

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.

I was talking about my power and computation costs, in the aggregate, I agree that it's worse.

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

#265

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

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.

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

#266
post #90

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

> Does it though? Loading a webpage barely registers in cpu usage etc on a reasonably modern device.

CPU usage is not the problem. In most cases the problem is latency including the network latency to issue and return a substantial number of remote API requests across the Internet to get the data necessary to render the page.

In many cases unless you make page specific APIs that aggregate all the necessary data into a composite object on the server side this is the number one thing that slows things down. Network turnarounds are expensive but they are a lot less expensive when made inside of a datacenter than from a thousand or more miles away.

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

#267

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.

The argument against this is the cost of a user's bandwidth. If I have all the computation done on the server side, then I have to wait for the round trip every single time just to download the results. In this case, the browser's compute is more free, as the cost to send a remote request is more than likely higher. Like most things, there is no simple right answer, and it depends on what you are doing. But blindly a…

It depends on the style of application. For most line of business applications the data on the client side is potentially out of date as soon as it requested, and as a consequence very little can be done on the client side except arrange or rearrange data for display. All requests that make any substantive changes must be sent to a server somewhere anyway and client side data caching is almost useless.

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

#268

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…

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

What sort of slow backends do you work with? My PHP htmx application responds in ~30ms including network transmit. Even if you’re across an ocean it’s maybe 300ms.

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

#269
What on earth does this tangled mess "simplify"? I've been at it with web dev for over 20 years and I was left scratching my head. The trouble with going down the JS rabbit hole is that you lose perspective on simplicity. **d help us if this becomes the new hotness. Oh, wait it already is. Oh well, until next month ...

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

#270

Earlier quoted context omitted.

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

"classless css lib" ??
Post reply on HN