4 ms·

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interac

by pier25 3y ago

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, you can move the compute layer of your app close to the user in multiple ways. Moving the data to the edge is much harder.

jdthedisciple 3y ago
This is my biggest gripe with this approach as well as HTMX. Avoiding delays for what should be purely client-side actions is a non-negotiable to me.
- recursivedoubts 3y ago
  https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
Malix_off 3y ago
Hyperscript/AlplineJS would do the job
miroljub 3y ago
If you need to fetch data from the server side, you need to fetch data from the server side. It doesn't matter much if it's a 10k json that you have to load and parse, or a 12k html snippet that you can directly display, the delay would be the same. If you are concerned about the delay when switching a tab, nothing prevents you to load both tabs during the first page load, and then just display the content without a new network requests. Whether you should do this or not is completely unrelated to whether you should use htmx, htmz or react.
- spiffytech 3y ago
  Unpoly does something like this: you can mark a link to be preloaded on hover.
trws 3y ago
FWIW, I happen to be in Australia and it’s quite snappy. No noticeable delay at all. If I were on a satellite connection or something it would be different, but trans-pacific cable seems to be doing just fine. Really it’s the super-long initial latency connections where this remains an issue.
mariusseufzer 3y ago
Texting from NZ: I don’t know how snappy your experience is but all I can say is that we‘re used to slower websites here in New Zealand. Switching between the tabs and having a <1sec delay is totally acceptable imho. It doesn’t feel „instant“ but instant enough!
- interstice 3y ago
  Also NZ, haven’t tested but 200-400ms is standard here and west coast US is fine. East coast or Europe is noticeably bad
- Systemling0815 3y ago
  [dead]
flaburgan 3y ago
But would the response be cached in the browser after the first call?
klabb3 3y ago
Yeah. I like the simplicity of htmx etc but network round trips are simply not suitable for a lot of interactions (at least if we’re talking about web apps). For a barebones approach I’d prefer tabs etc to be low-JS on top of a functional plain html page.
- _heimdall 3y ago
  Personally I've landed on the balance of leaving rendering wherever the state lives. In the tabs example, my question is always how dynamic and complex the tabs are. For fairly simple tabs its pretty clean to server render the HTML for all tabs and use a basic client-side script to handle navigation (ideally its synced in the URL as well). For more complex tabs, or tabs heavily dependent on dynamic state, I find that its much easier to maintain long term if the rendering happens server-side. I personally have enjoyed HTMX for this to swap out an island of HTML, but a full page reload has worked for decades now. In my experience the worst solution is shipping the complex state and the complex rendering logic to the browser. From performance to bug reproducibility, it has always cause me more pain that the DX original dev time are worth.
withinboredom 3y ago
Totally disagree as a regular user of 2g internet on a phone. If you are downloading a 1mb bundle to show me your home page, I'm going to give up within 30s or go elsewhere. I'm more than happy to put up with laggy feedback. That being said, usually people writing downloads using fetch will implement a promise-based timeout on top of the network timeout, which causes all kinds of issues on 2g internet. One of my favorite side-effects are implementations that "retry after 2s" that don't actually cancel the in-flight request, causing my entire bandwidth to be hogged up with dozens of these requests "retrying" when the initial request eventually returned successfully. Javascript developers are unintentionally evil to non-5g internet.
- pier25 3y ago
  1MB bundle of JS is definitely terrible. I'm not advocating that by any means :)
  - withinboredom 3y ago
    It happens more than anyone wants to admit, but even at 2g speeds, 256kb takes almost 20 seconds to download (I get about 120-180 kbps). When sites provide the HTML and CSS, I can usually stop the page from loading and at least read the content within a few minutes. When there's a js bundle, there is usually a fairly large initial bundle, then that loads a couple of other bundles ... and I'm still looking at a white screen, and not even a loading animation (from the browser or the developer) because as far as the browser is concerned, it has loaded the HTML and most developers don't even realize they can edit the base-line HTML sent to browsers because they never even see it.
mhd 3y ago
I don't think every solution in the webdev space is supposed to be a one size fits all panacea. Especially this, which seems more like an incentive to think about structuring webapps. Sometimes it's interesting to see how far you can go without going the "let's download the web in a JS blob" way. One of these days, I'm going to see whether I can still build something reasonably modern with Seaside, the continuation-based framework from the olden days, where basically the whole UI state is stored in the server-side session and everything is a request. Worked quite alright, way back when not everything had a local CDN and the internet tubes were a bit narrower.
eddd-ddde 3y ago
> Moving the data to the edge is much harder. Which means its gonna be the same thing if you try to render on the client, since you still need a round trip for data...
- pier25 3y ago
  With some JS you might not need to do multiple roundtrips though. For example to open a tab or a dialog.
  - Malix_off 3y ago
    That's why the creator of HTMX made _hyperscript
strken 3y ago
I'm in Australia and it's quite nice to use. The big killer here isn't just round trip time, it's the RTT compounded with the 14KB limit from TCP before it stops blindly sending data and compounded with extra resources that have to be fetched in a chain. If you keep the size of the response under 14KB and don't have render-blocking links to CSS and JS a page will be pretty fast; the moment it's any bigger the time before page load will double. I'm happy waiting about 300ms for a page served from the east coast of the US to load, but 600ms becomes noticeable and anything more - JS which loads more JS which loads JSON and blocks rendering until it's done, for example - starts to be excruciating.
keepamovin 3y ago
One cool hack you can do is set the background of all widgets to a non transparent color, and then set the background image of the iframe to a loading gif. That way, between loads, you will not have any widget content in the iframe and will instead reveal the loader. :)

by pier25 3y ago

jdthedisciple 3y ago

This is my biggest gripe with this approach as well as HTMX. Avoiding delays for what should be purely client-side actions is a non-negotiable to me.

recursivedoubts 3y ago
https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

Malix_off 3y ago

Hyperscript/AlplineJS would do the job

miroljub 3y ago

If you need to fetch data from the server side, you need to fetch data from the server side. It doesn't matter much if it's a 10k json that you have to load and parse, or a 12k html snippet that you can directly display, the delay would be the same. If you are concerned about the delay when switching a tab, nothing prevents you to load both tabs during the first page load, and then just display the content without a new network requests. Whether you should do this or not is completely unrelated to whether you should use htmx, htmz or react.

spiffytech 3y ago
Unpoly does something like this: you can mark a link to be preloaded on hover.

trws 3y ago

FWIW, I happen to be in Australia and it’s quite snappy. No noticeable delay at all. If I were on a satellite connection or something it would be different, but trans-pacific cable seems to be doing just fine. Really it’s the super-long initial latency connections where this remains an issue.

mariusseufzer 3y ago

Texting from NZ: I don’t know how snappy your experience is but all I can say is that we‘re used to slower websites here in New Zealand. Switching between the tabs and having a <1sec delay is totally acceptable imho. It doesn’t feel „instant“ but instant enough!

interstice 3y ago
Also NZ, haven’t tested but 200-400ms is standard here and west coast US is fine. East coast or Europe is noticeably bad
Systemling0815 3y ago
[dead]

flaburgan 3y ago

But would the response be cached in the browser after the first call?

klabb3 3y ago

Yeah. I like the simplicity of htmx etc but network round trips are simply not suitable for a lot of interactions (at least if we’re talking about web apps). For a barebones approach I’d prefer tabs etc to be low-JS on top of a functional plain html page.

_heimdall 3y ago
Personally I've landed on the balance of leaving rendering wherever the state lives. In the tabs example, my question is always how dynamic and complex the tabs are. For fairly simple tabs its pretty clean to server render the HTML for all tabs and use a basic client-side script to handle navigation (ideally its synced in the URL as well). For more complex tabs, or tabs heavily dependent on dynamic state, I find that its much easier to maintain long term if the rendering happens server-side. I personally have enjoyed HTMX for this to swap out an island of HTML, but a full page reload has worked for decades now. In my experience the worst solution is shipping the complex state and the complex rendering logic to the browser. From performance to bug reproducibility, it has always cause me more pain that the DX original dev time are worth.

withinboredom 3y ago

Totally disagree as a regular user of 2g internet on a phone. If you are downloading a 1mb bundle to show me your home page, I'm going to give up within 30s or go elsewhere. I'm more than happy to put up with laggy feedback. That being said, usually people writing downloads using fetch will implement a promise-based timeout on top of the network timeout, which causes all kinds of issues on 2g internet. One of my favorite side-effects are implementations that "retry after 2s" that don't actually cancel the in-flight request, causing my entire bandwidth to be hogged up with dozens of these requests "retrying" when the initial request eventually returned successfully. Javascript developers are unintentionally evil to non-5g internet.

pier25 3y ago
1MB bundle of JS is definitely terrible. I'm not advocating that by any means :)
- withinboredom 3y ago
  It happens more than anyone wants to admit, but even at 2g speeds, 256kb takes almost 20 seconds to download (I get about 120-180 kbps). When sites provide the HTML and CSS, I can usually stop the page from loading and at least read the content within a few minutes. When there's a js bundle, there is usually a fairly large initial bundle, then that loads a couple of other bundles ... and I'm still looking at a white screen, and not even a loading animation (from the browser or the developer) because as far as the browser is concerned, it has loaded the HTML and most developers don't even realize they can edit the base-line HTML sent to browsers because they never even see it.

mhd 3y ago

I don't think every solution in the webdev space is supposed to be a one size fits all panacea. Especially this, which seems more like an incentive to think about structuring webapps. Sometimes it's interesting to see how far you can go without going the "let's download the web in a JS blob" way. One of these days, I'm going to see whether I can still build something reasonably modern with Seaside, the continuation-based framework from the olden days, where basically the whole UI state is stored in the server-side session and everything is a request. Worked quite alright, way back when not everything had a local CDN and the internet tubes were a bit narrower.

eddd-ddde 3y ago

> Moving the data to the edge is much harder. Which means its gonna be the same thing if you try to render on the client, since you still need a round trip for data...

pier25 3y ago
With some JS you might not need to do multiple roundtrips though. For example to open a tab or a dialog.
- Malix_off 3y ago
  That's why the creator of HTMX made _hyperscript

strken 3y ago

I'm in Australia and it's quite nice to use. The big killer here isn't just round trip time, it's the RTT compounded with the 14KB limit from TCP before it stops blindly sending data and compounded with extra resources that have to be fetched in a chain. If you keep the size of the response under 14KB and don't have render-blocking links to CSS and JS a page will be pretty fast; the moment it's any bigger the time before page load will double. I'm happy waiting about 300ms for a page served from the east coast of the US to load, but 600ms becomes noticeable and anything more - JS which loads more JS which loads JSON and blocks rendering until it's done, for example - starts to be excruciating.

keepamovin 3y ago

One cool hack you can do is set the background of all widgets to a non transparent color, and then set the background image of the iframe to a loading gif. That way, between loads, you will not have any widget content in the iframe and will instead reveal the loader. :)