undefined | Better HN

0 pointsthe_gipsy2y ago0 comments

Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.

0 comments

intrasight2y ago

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?

abrahms2y 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).

intrasight2y 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

2 more replies

chrisweekly2y 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.

the_gipsyOP2y 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.

crabmusket2y 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-pok...

1 more reply

j / k navigate · click thread line to collapse