3 ms·

You,re pointing the blame at a source of EVEN WORSE performance issues, but it doesn,t remove the slowdown described. Plain HTML renders several order of magni

You,re pointing the blame at a source of EVEN WORSE performance issues, but it doesn,t remove the slowdown described. Plain HTML renders several order of magnitudes faster than post-load JS rendering, and yes, it is noticeable, especially if you account for variable connection speeds. Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

branko_d 6y ago
> Plain HTML renders several order of magnitudes faster than post-load JS rendering Well, "several orders of magnitude" is a bit much, but the point stands. However, that's only during the initial load. After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. If done properly (and that's a big if!), and where appropriate, this can be much faster. > Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows. Very true! And on beefeir CPUs/GPUs, more RAM, faster storage etc. For the last couple of years, I've been careful to develop on "midrange" hardware, exactly so I can spot performance problems earlier.
- forgotmypw17 6y ago
  > However, that's only during the initial load. Primary and by far most frequent use case. > After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly. Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps. > If done properly (and that's a big if!), and where appropriate, this can be much faster. A big IF, indeed.
  - branko_d 6y ago
    I think you have "document paradigm" in mind. For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all. > Primary and by far most frequent use case. In document paradigm. > And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly. Not if the client-side routing is done properly. I did say "if done properly". > Anyone who doesn't support JS to the level you want? With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA. > Well, fuck those people, let them make their own wheelchair ramps. What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).
    - forgotmypw17 6y ago
      The alternative is HTML, which is accessible to most.

branko_d 6y ago

> Plain HTML renders several order of magnitudes faster than post-load JS rendering Well, "several orders of magnitude" is a bit much, but the point stands. However, that's only during the initial load. After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. If done properly (and that's a big if!), and where appropriate, this can be much faster. > Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows. Very true! And on beefeir CPUs/GPUs, more RAM, faster storage etc. For the last couple of years, I've been careful to develop on "midrange" hardware, exactly so I can spot performance problems earlier.

forgotmypw17 6y ago
> However, that's only during the initial load. Primary and by far most frequent use case. > After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly. Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps. > If done properly (and that's a big if!), and where appropriate, this can be much faster. A big IF, indeed.
- branko_d 6y ago
  I think you have "document paradigm" in mind. For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all. > Primary and by far most frequent use case. In document paradigm. > And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly. Not if the client-side routing is done properly. I did say "if done properly". > Anyone who doesn't support JS to the level you want? With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA. > Well, fuck those people, let them make their own wheelchair ramps. What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).
  - forgotmypw17 6y ago
    The alternative is HTML, which is accessible to most.