5 ms·

This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?

abrahms 3y ago
Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).
- intrasight 3y ago
  > Mobile phones have less powerful CPUs True - but not by much > Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller > where you already have it loaded into memory anyway Likely not true if implementation uses streaming semantics
  - nchmy 3y ago
    > true - but not by much. False. https://infrequently.org/2022/12/performance-baseline-2023/ https://infrequently.org/2022/12/performance-baseline-2023/
    - aatd86 3y ago
      I always see these claims but isn't network the more limiting factor? Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet? Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?
  - alethiophile 3y ago
    I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save. I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.
the_gipsy 3y ago
JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.
- crabmusket 3y ago
  Nolan Lawson demonstrated using a web worker to perform virtual DOM updates in 2015. Sad it hasn't caught on in any of the major frameworks. https://pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org#i-like-the-way-you-work-it https://pocketjavascript.com/blog/2015/11/23/introducing-pok...
  - ttfkam 3y ago
    It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both. Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact. Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me. Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.
    - crabmusket 3y ago
      Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx. I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.
chrisweekly 3y ago
I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.

Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).

intrasight 3y ago
> Mobile phones have less powerful CPUs True - but not by much > Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller > where you already have it loaded into memory anyway Likely not true if implementation uses streaming semantics
- nchmy 3y ago
  > true - but not by much. False. https://infrequently.org/2022/12/performance-baseline-2023/ https://infrequently.org/2022/12/performance-baseline-2023/
  - aatd86 3y ago
    I always see these claims but isn't network the more limiting factor? Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet? Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?
- alethiophile 3y ago
  I can't speak to any kind of general principle here, but viewing any standard modern web page e.g. Twitter, Discord in a Web browser reliably takes more CPU and memory than running a late-game Factorio save. I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.

the_gipsy 3y ago

JavaScript is single-threaded, so whatever CPU work is going on will compete with the UI responsiveness. Even mobile apps, which run a dedicated thread for each, probably won't do one single clean UI update in response to the server-response.

crabmusket 3y ago
Nolan Lawson demonstrated using a web worker to perform virtual DOM updates in 2015. Sad it hasn't caught on in any of the major frameworks. https://pocketjavascript.com/blog/2015/11/23/introducing-pokedex-org#i-like-the-way-you-work-it https://pocketjavascript.com/blog/2015/11/23/introducing-pok...
- ttfkam 3y ago
  It's not enough to be a novel approach. It also has to be demonstrably better from a performance standpoint, a developer experience standpoint, or arguably both. Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact. Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me. Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.
  - crabmusket 3y ago
    Very fair assessment, though not everyone is using, or will use, Svelte or Solid. Including people who are using htmx. I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.

chrisweekly 3y ago

I'm not the GP but I'd say it's not "just" doing that render-blocking work on a single thread on a potentially under-powered mobile device, it's also introducing significant latency to fetch, parse and execute the code that will render to the DOM.