The Untold History Behind Lynx
summary
Rspack originates as a custom bundler built because existing tools couldn’t handle Lynx’s native constraints: a 90‑day Spring Festival app with hundreds of engineers, billions of users, ~70 billion red packets opened and ~100 billion impressions forces new tradeoffs. Iterations move from Speedy (Rollup + JS) to ESBuild prebundling, a Go fork, then a Rust reimplementation. Key concrete problems are slow HMR rebuilds, inability to inject runtimes, JSCore transpile targets, and webview IO and chunking — solved by Rspack and companion rspeedy using first frame rendering and dual thread patterns.
AI-written summary · about
chapters (9)
- 0:00Introduction to Links
- 1:47Dual-thread architecture
- 4:35Origins of RSpack
- 7:02Spring Festival app challenge
- 11:13PIA and build constraints
- 13:20HMR and performance issues
- 15:25Decision for custom bundler
- 17:30Evaluating build tools
- 19:16RSpack final iteration
related talks
24mTurbopack and Rspack - Modern day JavaScript bundlers
45mBundler Bonanza
30mSnowpack, Webpack and the Third Age of JavaScript
27mTurbopack. Why? How? When? and the Vision...
39mBundlers: a deep dive into modern JavaScript build tools
21mWebpack: Final Reckoning
34mModule Federation, Bundlers, and Future State
17mTurbopack - Rust-based successor to Webpack