The browser's main thread is expensive

	The browser's main thread is expensive(kciter.so)
	423 points by kciter 9 days ago \| 150 comments
	tl;dr: The browser's main thread handles JavaScript execution, style, layout, and paint on a single ~10ms-per-frame budget, so long tasks cause jank in scroll, input, and animation. The article covers two strategies: using the main thread wisely via splitting (yielding with setTimeout/rAF), batching (debounce/throttle), prioritizing (priority queues, idle-until-urgent), and deferring (code splitting, IntersectionObserver); and avoiding it entirely by offloading animations to the compositor (transform/opacity, FLIP) or heavy computation to web workers with transferable objects. The biggest wins often come from eliminating work altogether through dropping, merging, or memoization.
	HN Discussion: ~Article is great but misses that most slowness comes from bloated JS bundles and hydration, not interactivity ↑Praises the article as enlightening and reinforces the value of yielding/cooperative multitasking techniques ~Minor technical clarification that matching display refresh rate isn't strictly necessary for smooth perception ↓Article should draw more on established scheduling theory rather than framing it as developer judgment •Adds supplementary information like View Transitions API, WASM/web workers use cases, and historical examples