Hacker News Reader

Comment by arbenpurben | Hacker News Reader

This. This gets us 98% of the way. The people that have to worry about the 2% are not you, because your web app almost certainly doesn’t need offline-first of FPS-like user interaction, so in 98% of cases, hypermedia + tech like htmx gets you 100% of the way.

For pete’s sake, just let your server serve html. Replace only the parts of the page that need to update… with html. From your server. The poor thing is just sitting there, idling, bored, borderline depressed because it doesn’t get much of chance to do what it is meant to do, which is, you know… serve. “But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays.

View on HN

"“But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays."

That is a very creative analogy, but not one I agree with.

My servers should do as little as possible. They should not serve files just for the sake of it, because they have all these shiny serving features.

And I like JSON as it is not as verbose as html and I can directly work with it in javascript. And then update my html where I need it locally.

If you prefer it differently, than this is fine. The web supports many ways.

> My servers should do as little as possible.

Why? It’s not like they wear and tear?

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal.

Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[Edit: I don't want to get into this argument right now]

the original web architecture has sophisticated client-side caching built into it, all modern browsers support it:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

the difference between constructing a string of JSON and a string of HTML is a round off error when compared with network connection costs and data store accesses, etc.

I'm guessing you haven't measured it, as IME it certainly is true. Try it, you might be surprised.

Also, SSR'd pages can be cached too.

"The server load from a server-side rendered page vs an API call that returns JSON is... very minimal."

That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways.

My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.

>One advantage of pushing the computing on the user-side is that it reduces the load on the server:

But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards.

The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.

Since all the clients have to do the work, doesn't that result in a net increase in electricity consumption? Since most electricity comes from fossil fuels doesn't that in net hurt our battle against climate change?

Servers are probably a bit more energy efficient than most consumer devices, but in general it does not matter if you calculate it at A or at B. Somewhere it needs to be processed.

You were maybe thinking of processing once and then push it to thousands of clients? Those scenarios exists, but are the exception and not the topic here.

> Those scenarios exists, but are the exception

More like, they are the rule.

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

The developer time isn't higher than if it was server side rendered. And for some applications, like the ones I'm building, it would be impossible to do the work on the server.

I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.

It is all a question, of how big you want to scale it.

Stack Overflow runs SSR with a half a dozen servers. How much more scale do you need?

A bit more, if the servers also have to handle media.

Eeeeeeexactly

> For pete’s sake, just let your server serve html

You do realize this means all the user data has to be sent to the cloud? Which is what we want to escape? Hypermedia was created for bots for discoverability, I don't know why anyone would think this is an user-centric concept.

Reply on news.ycombinator.com