There was very little new information for me as I have applied some of these techniques myself based on having developed an intuitive understanding on how a rendering "thread" works and blocks, but for a less experienced developer this article should be incredibly enlightening and provide a solid understanding of what's happening.
I employed use of yielding on a hobby project [0] I made about 15 years ago, particularly when it had to do lots of draw operations on a canvas. I also experimented with using worker threads to render pieces of it on a background thread, but at the time there was no way to copy the data efficiently between them and the main thread, one had to send the data as a base64 encoded PNG and the overhead of encoding, decoding and then copying it onto the canvas made it perform far worse than just doing it all on the main thread.
The website also does Gzip decoding of uploaded files in JavaScript and the library I found at the time did all the work synchronously so could lock up the UI thread easily for 10+ seconds. I tweaked it to be able to yield every 200ms or something, the process of which was very educational, particularly due to it convincing me to never omit the curly braces after an if statement, I spent a very long time trying to understand why it wasn't working until eventually I realized a statement I added wasn't in the if statement's block. It's not that I didn't understand how if statements worked, it's that in my mind the lack of curly braces was initially invisible to me.
Top article, kudos! applied some of these techniques previously, and they do matter a lot. thing is, when you learn/teach JS there is usually limited time left to talk these topics, and they are essential more than it seems.
the whole point of cooperative multitasking is to yield now and then (back to the runner), so that it can process the drawing. Besides, at 60fps there's so much that can be computed once every N frames, and the eye does not see it, the animation flows.
It becomes even more interesting when webgpu is involved, but the CSS animator is indeed very fast.
note: some recent work of mine (newskool digital flyer sites) -> bsf.hmsu.org // nouveauxhivers.dub4powder.xyz
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.
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.
One obvious tool that this article doesn't mention is Chrome's performance monitor. Many techniques in the article only have to be applied once you can verify that they are running slow.
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 :)
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 want to do a blanket response to people calling this AI slop: the post was written in korean and translated to english. Calling this slop is judgment slop.
Actor Model, dedicated or shared application worker. Full support for multi-window apps. Resolved since 2019. 26000 commits in, and counting. You are welcome!
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" is the mantra, 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
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 behavior.
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.
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.
> 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.
what's your solution to the performance hit that you get when you load up the dom with a zillion things? long, unvirtualized threads will bring every decent computer to its knees.
the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.
So this is AI slop written? Why would anyone believe I'd want to read AI spam?
Also, the issue I see is who controls browsers as much more profound. We need to find a solution here, as the browser is too important to allow private companies to keep mankind hostage.
Edit: Wow, and the praise-accounts. Is that new on hackernews?
What signs of slop are people seeing here? Or is it just a knee-jerk reaction to encountering lots of text?
I’ve worked in the field for a long time and see a carefully written, correct, calm article. No obvious AÍ tells in wording or sentence construction. It is a bit long - might have been inspired by ciechanow.ski
"and there’s a reason for that"
"The code isn’t slow. It just happens to be the code that’s holding the main thread."
"dealing with the main thread becomes the important part"
"What to remember for now is that holding the main thread for a long time is the same thing as freezing the screen."
"One thing not to misread here is"
I realize the author may not write native English, but this is not translation slop, it's AI writing slop.
AI;DR – too bad as the content seems to be worthwhile, but then why not take the trouble to write it up yourself. Have it proofread/edited/spruced up all you want afterward, but don't have it do all (or most of) the writing.
There was very little new information for me as I have applied some of these techniques myself based on having developed an intuitive understanding on how a rendering "thread" works and blocks, but for a less experienced developer this article should be incredibly enlightening and provide a solid understanding of what's happening.
I employed use of yielding on a hobby project [0] I made about 15 years ago, particularly when it had to do lots of draw operations on a canvas. I also experimented with using worker threads to render pieces of it on a background thread, but at the time there was no way to copy the data efficiently between them and the main thread, one had to send the data as a base64 encoded PNG and the overhead of encoding, decoding and then copying it onto the canvas made it perform far worse than just doing it all on the main thread.
The website also does Gzip decoding of uploaded files in JavaScript and the library I found at the time did all the work synchronously so could lock up the UI thread easily for 10+ seconds. I tweaked it to be able to yield every 200ms or something, the process of which was very educational, particularly due to it convincing me to never omit the curly braces after an if statement, I spent a very long time trying to understand why it wasn't working until eventually I realized a statement I added wasn't in the if statement's block. It's not that I didn't understand how if statements worked, it's that in my mind the lack of curly braces was initially invisible to me.
[0]: https://mordritch.com/mc_rss/
the whole point of cooperative multitasking is to yield now and then (back to the runner), so that it can process the drawing. Besides, at 60fps there's so much that can be computed once every N frames, and the eye does not see it, the animation flows.
It becomes even more interesting when webgpu is involved, but the CSS animator is indeed very fast.
note: some recent work of mine (newskool digital flyer sites) -> bsf.hmsu.org // nouveauxhivers.dub4powder.xyz
> 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.
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 :)
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.
FLIGHT §%=
https://github.com/neomjs/neo/blob/dev/learn/benefits/body/O...
.setTimeout(0)
CANNOT C
.setTimeout(0)
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.
What's your point? Are you saying all animations and rendering are unnecessary?
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.
the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.
Also, the issue I see is who controls browsers as much more profound. We need to find a solution here, as the browser is too important to allow private companies to keep mankind hostage.
Edit: Wow, and the praise-accounts. Is that new on hackernews?
I’ve worked in the field for a long time and see a carefully written, correct, calm article. No obvious AÍ tells in wording or sentence construction. It is a bit long - might have been inspired by ciechanow.ski
I realize the author may not write native English, but this is not translation slop, it's AI writing slop.