4 ms·

I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of

I very rarely see a "Web App" that's faster due to this. Take Gmail: plain-HTML gmail transfers and renders a whole page faster than full-fat Gmail does most of the things it does, which involve merely "some API data". The activity/loading indicators on normal Gmail display longer than the full-page load on plain-HTML gmail. This had some validity in the early days of AJAX when common practice was to respond with HTML fragments and it was mostly just a work-around for Frames not being very good at a bunch of things they should have been good at. These days, not so much.

zozbot234 5y ago
Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.
- handrous 5y ago
  It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
  - wonnage 5y ago
    Especially with graphql being the new hotness I wonder if it's time to replace JSON with a binary format like Thrift. The old argument was that REST+JSON was simple and easy to debug but that goes out the window with GQL anyway. JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
    - RedShift1 5y ago
      If you were sending HTML those copies and parsing would be there anyway?
  - Dylan16807 5y ago
    Even so, if we look at gmail all the data needed for the email list is 20-100KB. The bloat is caused by bad design, not the extra copies.
    - pdimitar 5y ago
      When 99% of all SPAs I ever used are that painfully slow (sometimes even on 4G) then obviously that way of work encourages people to make bad design. So we should uproot the problem and not dance around it.
- toast0 5y ago
  It really depends on both latency and bandwidth. A reasonable POTS modem does ok on latency, but bad on bandwidth. So roundtrip is fine until you send too much data (which is real easy, modern initial segment limit of 10 combined with a 1500 mtu is more than a second of download buffer). If you kept the data small, many round trips would be okish. On the other hand, traditional geosynchronous satellite always has terrible latency, so many round trips is bad regardless of the data size... One big load would be a lot better there.
  - giantrobot 5y ago
    POTS modems don't do great on latency either. I never managed under about a quarter second latency on dial-up. The first hop (your modem'd DAC and the ISP modem's ADC) was usually around 75-100ms all by itself. So even today with pretty fast networks (compared to the heyday of modems) you're easily looking at base latency of a quarter second.
    - icedchai 5y ago
      Modem latency was crap. That was another reason a 64K single channel ISDN connection felt so much faster, even though the bandwidth wasn't that much more. ISDN latency was wayyy better since it was digital: 10 to 20ms vs 200ms minimum with an analog modem. Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
      - giantrobot 5y ago
        My first experience with an ISDN connection was mind blowing. I had only ever used analog modems prior. So I'm just expecting faster downloads for large files and pages would load faster. It was a 64k line so I was expecting it to be twice as my modem at home. Web pages just appeared (modulo Netscape connection limitations). A fresh page load felt as fast as a cached page load on my analog modem. It was nuts. It was most noticeable in a handful of games of Quake I played. I got to experience the joy of being a Low Ping Bastard and actually landing a few hits on people.
- swiley 5y ago
  They also handle errors by having the user reload the page which means everything starts over. My experience growing up is that you don't notice the issues on sane pages written by hobbyists/professors/researchers and then you go to something built by google and everything falls apart.
RedShift1 5y ago
It only works if the webapp can keep its calls limited to 1 per page/user action. Lots of webapps make multiple roundtrips (additional fetches triggered by earlier requests so they can't be done in parallel) making it slow even on fast connections (looking at you Quickbooks Time).
- robertlagrant 5y ago
  This is exactly why BFFs exist.
  - RedShift1 5y ago
    What's a BFF?
    - robertlagrant 5y ago
      https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/

zozbot234 5y ago

Makes sense. Roundtrips will kill you on slow connections, and the average SPA does lots of back-and-forth roundtrips. Then the JS code has to tweak hundreds or thousands of DOM nodes in a completely serial fashion to reflect the new data. Much faster in practice to either download or generate (preferably via WASM) a single chunk of raw HTML and let the browser rerender it natively.

handrous 5y ago
It's part of the cause of all the damn memory-bloat , too. Receive some JSON (one copy of the data), parse that and turn it into JS objects (at least two copies allocated, now, depending on how the parsing works), modify that for whatever your in-browser data store is, and/or copy it in there, or copy it to "local state", or whatever (three copies), render the data to the shadow DOM (four copies), render the shadow DOM to the real DOM (five copies). Some of those stages very likely hide even more allocations of memory to hold the same data, as it's transformed and moved around. Lots of library or pattern choices can add more. It adds up.
- wonnage 5y ago
  Especially with graphql being the new hotness I wonder if it's time to replace JSON with a binary format like Thrift. The old argument was that REST+JSON was simple and easy to debug but that goes out the window with GQL anyway. JSON is just a terrible fit for GQL schemas. I regularly deal with metadata enum fields that are repeatedly serialized causing massive bloat. Sure it gets gzipped away, but you still have all those copies after decompression and parsing.
  - RedShift1 5y ago
    If you were sending HTML those copies and parsing would be there anyway?
- Dylan16807 5y ago
  Even so, if we look at gmail all the data needed for the email list is 20-100KB. The bloat is caused by bad design, not the extra copies.
  - pdimitar 5y ago
    When 99% of all SPAs I ever used are that painfully slow (sometimes even on 4G) then obviously that way of work encourages people to make bad design. So we should uproot the problem and not dance around it.
toast0 5y ago
It really depends on both latency and bandwidth. A reasonable POTS modem does ok on latency, but bad on bandwidth. So roundtrip is fine until you send too much data (which is real easy, modern initial segment limit of 10 combined with a 1500 mtu is more than a second of download buffer). If you kept the data small, many round trips would be okish. On the other hand, traditional geosynchronous satellite always has terrible latency, so many round trips is bad regardless of the data size... One big load would be a lot better there.
- giantrobot 5y ago
  POTS modems don't do great on latency either. I never managed under about a quarter second latency on dial-up. The first hop (your modem'd DAC and the ISP modem's ADC) was usually around 75-100ms all by itself. So even today with pretty fast networks (compared to the heyday of modems) you're easily looking at base latency of a quarter second.
  - icedchai 5y ago
    Modem latency was crap. That was another reason a 64K single channel ISDN connection felt so much faster, even though the bandwidth wasn't that much more. ISDN latency was wayyy better since it was digital: 10 to 20ms vs 200ms minimum with an analog modem. Some early ISPs I worked with started with 56K leased lines. The latency there was like night-and-day compared to a 56k modem.
    - giantrobot 5y ago
      My first experience with an ISDN connection was mind blowing. I had only ever used analog modems prior. So I'm just expecting faster downloads for large files and pages would load faster. It was a 64k line so I was expecting it to be twice as my modem at home. Web pages just appeared (modulo Netscape connection limitations). A fresh page load felt as fast as a cached page load on my analog modem. It was nuts. It was most noticeable in a handful of games of Quake I played. I got to experience the joy of being a Low Ping Bastard and actually landing a few hits on people.
swiley 5y ago
They also handle errors by having the user reload the page which means everything starts over. My experience growing up is that you don't notice the issues on sane pages written by hobbyists/professors/researchers and then you go to something built by google and everything falls apart.

RedShift1 5y ago

It only works if the webapp can keep its calls limited to 1 per page/user action. Lots of webapps make multiple roundtrips (additional fetches triggered by earlier requests so they can't be done in parallel) making it slow even on fast connections (looking at you Quickbooks Time).

robertlagrant 5y ago
This is exactly why BFFs exist.
- RedShift1 5y ago
  What's a BFF?
  - robertlagrant 5y ago
    https://samnewman.io/patterns/architectural/bff/ https://samnewman.io/patterns/architectural/bff/