Actor Model, dedicated or shared application worker. Full support for multi-window apps. Resolved since 2019. 26000 commits in, and counting. You are welcome!
This article concludes with the following statement:
> So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment.
It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the oldest and most well-studied in all of computer science. It would make sense to go consult a textbook on the matter before trying to reinvent the wheel.
Brilliant, I had no idea about this stuff. Thanks for writing it up.
On the price ticket example, on my device (Samsung A15, mediocre phone from 2024) I get 11 fps with the slow example and 30 fps with the fast one. (15 if I scroll!)
Is that a case of the back pressure you mentioned?
All the other (fast) examples are 60 fps though :)
Great piece, OP. We work in WASM and are considering web workers to help with rendering documents off the main thread in that context. I was surprised to read that ArrayBuffer is moved by reference only! Might be an option. Thanks for putting this together.
One thing that I found quite interesting to see is how the behaviour of the "4.000 particles" demo changes between the 5ms rendering and the "everything now" rendering.
> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen?
Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.
Yeah, but if your website with, you know, text and stuff, doesn't do any stupid and unnecessary crap, it doesn't matter where the nonexistent unnecessary yet expensive code doesn't run.
and if you have no website at all, it takes zero seconds to load.
But for people who are developing websites that are more than just text, this is an excellently written article and great advice.
It's funny, for mobile app dev it feels like the community are a lot of focused on staying off the main thread, this is the first time I've come across one for webdev.
Well yeah but if you do actually need things like images, animations, high frequency updates, etc, this is actually a pretty good overview of how to approach it. Also learned that react uses posting to a MessageChannel to yield!
GP is right that just like with garbage where "reduce, reuse, recycle" the first question for optimizing something should be if you need to do the calculation at all.
This is true as well, yeah, but it came off as dismissive of everything too. Personally I prefer information dense interfaces with minimal chrome, but there really is a certain joy when you get to use a well designed and optimized fancy reactive, immersive interface
Amazing how you are being so down voted, most webpages do utter crap that no one would want the webpages to be doing other then advertisers. Really most things should be text and if we lived in a more cooperative world everything would be easy to parse and manipulate text with some video and images and perhaps various well defined interface types for different services that can be implemented in various ways as to the users liking.
My point is that many websites are using way too much technology for what they need to do, with correspondingly long load times and choppy runtime begavior.
Correct. But if the page is, at least in part, an art piece rather than an information dump, or needs to do interactive rendering for its purpose (an editor like the markdown example, live updating status displays, games and other interactive toys, etc), then the tech is necessary and this article is useful.
Again, correct. But “don't do this if you don't really need to do this” is rather pointless to say, hence is being downvoted, because people already being that sensible don't need to hear it, and those who are not are unlikely to listen. The comment is just noise, as unnecessary as the unnecessary animation and other gumf that it is railing against.
Actor Model, dedicated or shared application worker. Full support for multi-window apps. Resolved since 2019. 26000 commits in, and counting. You are welcome!
https://github.com/neomjs/neo/blob/dev/learn/benefits/body/O...
This article concludes with the following statement:
> So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment.
It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the oldest and most well-studied in all of computer science. It would make sense to go consult a textbook on the matter before trying to reinvent the wheel.
Do you have any suggestions for books on the topic?
Brilliant, I had no idea about this stuff. Thanks for writing it up.
On the price ticket example, on my device (Samsung A15, mediocre phone from 2024) I get 11 fps with the slow example and 30 fps with the fast one. (15 if I scroll!)
Is that a case of the back pressure you mentioned?
All the other (fast) examples are 60 fps though :)
Great piece, OP. We work in WASM and are considering web workers to help with rendering documents off the main thread in that context. I was surprised to read that ArrayBuffer is moved by reference only! Might be an option. Thanks for putting this together.
Excellent article, I went into it thinking the headline is obvious, but the examples are well crafted and it isn't just the obvious stuff.
In the first example: doesn't pushing the button while typing cause the textfield lose focus? What's the point of the typing in the example?
I think the point is, if you click the '2.0s' button, you cannot re-focus on the input field for those 2 seconds.
Nice examples, a bit repetetive perhaps.
One thing that I found quite interesting to see is how the behaviour of the "4.000 particles" demo changes between the 5ms rendering and the "everything now" rendering.
I wish await in JavaScript could conditionally yield. Instead I end up having to use arounds like if (shouldYield()) await do yield();
There's an RFC or two to spawn threads so I'm looking forward to that. The current way of workers + messages is tedious as hell.
Such an excellently written articles with really nice interactive visualizations!
The javascript web is. Restore the interop with noscript/basic HTML and it will lean towards sanity, something lost a few years ago.
> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen?
Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.
Yeah, but if your website with, you know, text and stuff, doesn't do any stupid and unnecessary crap, it doesn't matter where the nonexistent unnecessary yet expensive code doesn't run.
and if you have no website at all, it takes zero seconds to load.
But for people who are developing websites that are more than just text, this is an excellently written article and great advice.
It's funny, for mobile app dev it feels like the community are a lot of focused on staying off the main thread, this is the first time I've come across one for webdev.
Well yeah but if you do actually need things like images, animations, high frequency updates, etc, this is actually a pretty good overview of how to approach it. Also learned that react uses posting to a MessageChannel to yield!
Since when do images need more than just an <img> tag and a bit of styling?
GP is right that just like with garbage where "reduce, reuse, recycle" the first question for optimizing something should be if you need to do the calculation at all.
This is true as well, yeah, but it came off as dismissive of everything too. Personally I prefer information dense interfaces with minimal chrome, but there really is a certain joy when you get to use a well designed and optimized fancy reactive, immersive interface
Amazing how you are being so down voted, most webpages do utter crap that no one would want the webpages to be doing other then advertisers. Really most things should be text and if we lived in a more cooperative world everything would be easy to parse and manipulate text with some video and images and perhaps various well defined interface types for different services that can be implemented in various ways as to the users liking.
Sure, but there are sites like HN and there are sites like https://earth.nullschool.net/
What's your point? Are you saying all animations and rendering are unnecessary?
My point is that many websites are using way too much technology for what they need to do, with correspondingly long load times and choppy runtime begavior.
Correct. But if the page is, at least in part, an art piece rather than an information dump, or needs to do interactive rendering for its purpose (an editor like the markdown example, live updating status displays, games and other interactive toys, etc), then the tech is necessary and this article is useful.
Which is something like less than one percent of websites, and this technology is deployed much, much more widely.
Again, correct. But “don't do this if you don't really need to do this” is rather pointless to say, hence is being downvoted, because people already being that sensible don't need to hear it, and those who are not are unlikely to listen. The comment is just noise, as unnecessary as the unnecessary animation and other gumf that it is railing against.