Hacker News Reader

Comment by ketralnis | Hacker News Reader

Is it though? Is composing a response into a graphql or JSON or XML format that much more expensive than into an HTML format? Is

    {"comment": {"body: "lol"}}

notably expensive than

    <Comment body="lol"/>

View on HN

I assume a modern webpage has some logic to it which besides the redering also needs to be processed and if you apply that to a scale of billions x years I guess yes. But as I said I'm not an expert in the field nor have I any numbers. It's just what I thought.

Edit:

Thinking of having only to serve a state once and having each action processed on the client side instead of making for each a call the backend which has to return a fully rendered page.

Maybe I have a misconception goin on here!

The server doesn't [have to] return the entire page on a change. Return small chunk of HTML or small chunk of JSON. There will be a small cost to do the HTML on the server but there is also a cost to do the HTML on the client: sending them 50000000000kb of JavaScript initially.

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

Also see Blazor. We've been using it for a few years now.

Here is some specific documentation pertaining to how it manages incremental DOM updates: https://blazor-university.com/components/render-trees/

This is so easy to do with Rails via https://hotwired.dev/

Anything that wouldn't require a round trip for data can be scripted pretty simply just using Stimulus.

I can't imagine it's any harder with any of the other server side technologies like Liveview, Blazor, etc.

Reply on news.ycombinator.com