4 ms·

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"}

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"/>

w4eg324g 4y ago
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!
- cmoski 4y ago
  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.
cafebean 4y ago
Web page design will have to fundamentally change to accommodate surgically updating web pages, for the large overhead to disappear.
- TrispusAttucks 4y ago
  It already exists for several popular frameworks/languages. One example is [1] Laravel livewire. [1] https://laravel-livewire.com/ https://laravel-livewire.com/
  - Implicated 4y ago
    Can confirm, livewire is like _magic_.
  - bob1029 4y ago
    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/ https://blazor-university.com/components/render-trees/
- Lio 4y ago
  This is so easy to do with Rails via https://hotwired.dev/ 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.

w4eg324g 4y ago

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!

cmoski 4y ago
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.

cafebean 4y ago

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

TrispusAttucks 4y ago
It already exists for several popular frameworks/languages. One example is [1] Laravel livewire. [1] https://laravel-livewire.com/ https://laravel-livewire.com/
- Implicated 4y ago
  Can confirm, livewire is like _magic_.
- bob1029 4y ago
  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/ https://blazor-university.com/components/render-trees/
Lio 4y ago
This is so easy to do with Rails via https://hotwired.dev/ 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.