JavaScript Concurrency and the DOM
summary
Claims that full DOM APIs run inside a web worker via worker-dom and that moving event processing, state updates and diffing off the main thread measurably cuts main-thread time. Implementation uses Web Workers, a compact transferable hydration format with a string pool, a custom mutation observer, and async fallbacks (eg getBoundingClientRectAsync). Demos run Preact/React and a DOM benchmark near 60 fps; a low-end Nokia 2 shows painfully slow single-core JS (one pass took five minutes and 19 seconds) so offloading helps. Code is on GitHub/npm and is alpha.
AI-written summary · about
chapters (5)
- 0:00Start
- 1:06Insert slide where 2 white dudes mansplain the difference between parallelism and concurrency.
- 2:31OMG, 60 frames per second
- 13:30Low Level Primitive
- 22:24How does this work?
related talks
36mMulti-thread demystified
34mParallel computing in React
32mRise of the Web Workers
29mParallel computing in ReactJS: Provide a pleasant user experience
36mMultithreading in React: A guide to Web Workers
13mHow to Use Web Workers for Fun and Profit
19mLet the Main Thread Breathe!
30mBuild Snappier Apps with React and Web Workers