3 ms·

One misconception about Hypermedia-driven applications is the belief that you can't / shouldn't use JS or other new technologies. You can create a Cloudflare Wo

One misconception about Hypermedia-driven applications is the belief that you can't / shouldn't use JS or other new technologies. You can create a Cloudflare Worker returning HTML[0], which you can call using HTMX in the frontend. Using HTML to drive an app's interface has nothing to do with the tech stack, in fact, I think it opens the door to a more diverse tech stack. Optimistic UI updates, state management, and other "modern" JS techniques are cool, but often, the complexity is not worth it. Also, let's not forget that web browsers are already good at taking HTML/CSS and showing it in your screen. Somehow, we decided it was better to make all your users waste CPU cycles to do the same with Javascript and a Virtual DOM (but only after 10MB of JS files have finished downloading) [0] https://developers.cloudflare.com/workers/examples/return-html https://developers.cloudflare.com/workers/examples/return-ht...

nine_k 5y ago
From another POV, browsers are pretty bad at displaying HTML and CSS. The layout mechanics are complicated. DOM is slow and non-transactional which means jumpy redraws and jank during partial updates, and you just can't render it at 60 fps, or even 30 fps, like you would with a direct-mode game-style UI; at best you can peg several CPU cores to 100%. And this can never be fixed because backwards compatibility. It can only be replaced in some indefinite future. This is why the virtual DOM was invented. And yes, if you know how to cook it, it's faster than jQuery. OTOH great many web pages are not apps, and should not be treated as SPAs. But this happens, and it will until server-side rendering is made ridiculously easy to set up, and also becomes the fashion.
- polyrand 5y ago
  Yes! Thanks for the insight about the virtual DOM. I'm definitely not saying the virtual DOM is bad, or that JS is bad. But like you said, people are starting to mix pages and apps, thus also mixing the complexity requirements of each one. Luckily, it seems server-side rendering is coming back, even in React.
- naasking 5y ago
  The fastest DOM update libraries in the benchmarks I've seen eschew the vDOM entirely. See domdiff for instance.
  - nine_k 5y ago
    One may not need to build an entire tree and then compare to another tree; the generation and comparison may go hand in hand to avoid building an actual vDOM. It's DOM diffing anyway. It's still the "track and update dirty regions" logic of 8-bit game consoles, instead of the "redraw the whole screen from scratch" logic of modern game engines. DOM is not performant enough, and likely will never be, in its current shape. Merging the vDOM-less transactional DOM update logic into the DOM standard could be nice, though.

nine_k 5y ago

From another POV, browsers are pretty bad at displaying HTML and CSS. The layout mechanics are complicated. DOM is slow and non-transactional which means jumpy redraws and jank during partial updates, and you just can't render it at 60 fps, or even 30 fps, like you would with a direct-mode game-style UI; at best you can peg several CPU cores to 100%. And this can never be fixed because backwards compatibility. It can only be replaced in some indefinite future. This is why the virtual DOM was invented. And yes, if you know how to cook it, it's faster than jQuery. OTOH great many web pages are not apps, and should not be treated as SPAs. But this happens, and it will until server-side rendering is made ridiculously easy to set up, and also becomes the fashion.

polyrand 5y ago
Yes! Thanks for the insight about the virtual DOM. I'm definitely not saying the virtual DOM is bad, or that JS is bad. But like you said, people are starting to mix pages and apps, thus also mixing the complexity requirements of each one. Luckily, it seems server-side rendering is coming back, even in React.
naasking 5y ago
The fastest DOM update libraries in the benchmarks I've seen eschew the vDOM entirely. See domdiff for instance.
- nine_k 5y ago
  One may not need to build an entire tree and then compare to another tree; the generation and comparison may go hand in hand to avoid building an actual vDOM. It's DOM diffing anyway. It's still the "track and update dirty regions" logic of 8-bit game consoles, instead of the "redraw the whole screen from scratch" logic of modern game engines. DOM is not performant enough, and likely will never be, in its current shape. Merging the vDOM-less transactional DOM update logic into the DOM standard could be nice, though.