Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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?by nairboon
- I think the point is, if you click the '2.0s' button, you cannot re-focus on the input field for those 2 seconds.
- I remember seeing some JS cryptography library a long time (maybe 10 years?) ago that provided an async hashing function for exactly this reason: to split up what would normally be a simple synchronous computation and yield more often to the main thread.
Can't recall the name, but I remember thinking that was very clever once I understood why it was doing that, and am glad to see the concept explained directly here.
by mikemarsh - > 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.
by mschuster91 - 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.
by prodigycorp - The discussion of "FLIP (First, Last, Invert, Play)" would be improved by mentioning the View Transitions API, which is basically there to automate this technique.by skobes
- 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.by xnorswap
- 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.
by jkhdigital - This! Since it became easier for people to post their thoughts on a problem vs. research and learn from past work, we're now in the era where its harder to find the seminal and really-well-explained material for having to wade through years and years of people's rediscovery blogs.
(Don't get me wrong; I too think the article is great; just wish all the folks who went to JS bootcamp and are amazed by this would have cracked any CS or OS text book written since the late 60's and browsed a few chapters.)
- Do you have any suggestions for books on the topic?by TonyStr
- Well yes. But most of those studies assume/assert control over the environment. In this case you are running in the browser and you have to deal with the primitives it gives you. Both in compute management (threads/workers), communication (RPC, messages, shared memory, sockets), as scheduling (like having yield or not.
I’m not sure whether inventing a setup like green threads in JavaScript/workers would even be possible.
That is not to say that we should just forget about those learnings though.
by spockz - FYI: This isn't a browser-only thing. All platforms (Windows, Mac, ios, android) typically have a single-threaded UI.by gwbas1c
- For responsiveness that’s what you want, context switches add quite a lot of jitter and perceived slowness’s, making your app feel slow despite running at 120 fps.by Asmod4n
- 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
by larodi - 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.by piker
- haven't done this for documents, but for canvas rendering transferControlToOffscreen() worked better than moving ArrayBuffers. It hands the canvas to a worker that draws directly, no pixles over postMessage at all.
- ArrayBuffer is copied by default unless you pass it as a special transferable object. But only the current owner of the buffer can use it.
If you need to read and write from both threads at once, you need to look at SharedArrayBuffer.
by bastawhiz - I agree with most of the article, but would clarify the following: > For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame.
It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and even 48FPS will look smooth for most people. I agree that higher FPS is better, but there are diminishing returns.
by nerdralph - Below a certain threshold things are certainly going to look janky. But you’re right you don’t have to match the screens native refresh rate. More important is that you have a consistent frame rate. If you can’t hit 120hz, it’s better to target 60hz, rather than 120 a miss your frame budget. 30fps will also look better than 60 but regularly dropping frames.by Me1000
- It's a good nitpick. A hypothetical 1000Hz display will still look smooth to the human eye at 60/120Hz. A 1Hz display will never look smooth.
But it's more about honoring the user's preference. I personally would rather 60Hz, then 120Hz heating up my room unnecessarily. If someone has a display set to 1000Hz for whatever reason, then you should try your best to honor that.
by bgirard - Superb article.
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.
- Good article and I wish this was much better known.
The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do.
_so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated.
I've even seen (many) sites which have multiple SPAs stacked inside of them.
If you're on a slow internet connection and/or CPU the page is basically unusable for many tens of seconds and no amount of yielding post bundle hydrate will really solve that.
by martinald - Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.by amelius
- Why would a regular React site be so huge?
Maybe they had bundled fonts and images.
The bundle is just the lib plus your files minified.
You want to bundle vs hitting dozens of requests just to get files.
It’s not like React/webpack is a black box doing things I don’t know or want.
Performance: I challenge you to build a complex 3D game in vanilla threejs vs using r3f. useFrame alone is worth it
by fxd - I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...by jcelerier
- NoScript is a remedy for this. When a site is broken I whitelist a few domains likely to be necessary. After a few attempts I bounce. If I see a dozen plus domains I don't even bother. This cuts down on the volume of garbage sites I waste time on and shields me from novel trackers not on any block list.
The web is much faster when useless JS is taken away.
- The article acknowledges this in the very first paragraph:
> For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache.
These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic on freeing up the main thread because there's such a wide variety of approaches and many of them may not be obvious.
by pverheggen - 99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.by pjmlp