4 ms·

Because transferring tags back and forth is insanely wasteful and not needed. Instead of updating one element because we got fresh data, you will transfer the w

Because transferring tags back and forth is insanely wasteful and not needed. Instead of updating one element because we got fresh data, you will transfer the whole freaking page worth, most of which is identical to your previous state.

mixedCase 4y ago
Why do you think server-side rendering (or transferring tags back and forth as you unconsciously grazed the solution) requires whole-page loads? Hotwire, Htmx and similar solutions allow you to simply load whatever's changed, no need for reloading an entire page or having jarring transitions.
robertlagrant 4y ago
Transferring HTML and transferring a whole page are not the same. HTMX (for example) lets you transfer just a subset of the page that needs refreshing. Is <tr><td>1</td><td>2</td></tr> really that "insanely wasteful" compared to [{"value1": 1, "value2": 2"}] ? What's the difference after gzip, which is rather excellent with repeated items like tag names? Still insanely wasteful?
Lio 4y ago
In a Low-JS application of the type supported by Hotwired, Liveview, etc you would only send the HTML elements that are updated not the whole page. That's going to go over the wire with compression so you're unlikely to loose out much compared to the raw JSON. With an SPA you're going to have to render your data to some form of JSON format e.g. GraphQL and then rerender it again as HTML on the frontend. Without specific examples it's hard to talk meaningfully about performance but conceptually Low-JS is, IMHO, easy to work with and you get the fallback for clients without JavaScript for free. For frontend interactions which don't require new data from the server you can still make use of local JS via something like Stimulus. YMMV.
remram 4y ago
> Because transferring tags back and forth is insanely wasteful You are full of superlatives but short on arguments. As the number of pages you load tends to infinity, this might be true. In practice, loading a couple of 3KB pages is much better than loading a couple of 1KB data blobs plus a 500KB JavaScript app bundle. It is also more memory-friendly, more compatible, and better for SEO. As for wasteful of bandwidth... how big can HTML get? Is the bulk of your bandwidth cost really taken by HTML?

mixedCase 4y ago

Why do you think server-side rendering (or transferring tags back and forth as you unconsciously grazed the solution) requires whole-page loads? Hotwire, Htmx and similar solutions allow you to simply load whatever's changed, no need for reloading an entire page or having jarring transitions.

robertlagrant 4y ago

Transferring HTML and transferring a whole page are not the same. HTMX (for example) lets you transfer just a subset of the page that needs refreshing. Is <tr><td>1</td><td>2</td></tr> really that "insanely wasteful" compared to [{"value1": 1, "value2": 2"}] ? What's the difference after gzip, which is rather excellent with repeated items like tag names? Still insanely wasteful?

Lio 4y ago

In a Low-JS application of the type supported by Hotwired, Liveview, etc you would only send the HTML elements that are updated not the whole page. That's going to go over the wire with compression so you're unlikely to loose out much compared to the raw JSON. With an SPA you're going to have to render your data to some form of JSON format e.g. GraphQL and then rerender it again as HTML on the frontend. Without specific examples it's hard to talk meaningfully about performance but conceptually Low-JS is, IMHO, easy to work with and you get the fallback for clients without JavaScript for free. For frontend interactions which don't require new data from the server you can still make use of local JS via something like Stimulus. YMMV.

remram 4y ago

> Because transferring tags back and forth is insanely wasteful You are full of superlatives but short on arguments. As the number of pages you load tends to infinity, this might be true. In practice, loading a couple of 3KB pages is much better than loading a couple of 1KB data blobs plus a 500KB JavaScript app bundle. It is also more memory-friendly, more compatible, and better for SEO. As for wasteful of bandwidth... how big can HTML get? Is the bulk of your bandwidth cost really taken by HTML?