Qwik: Performance is a Human Design Issue
summary
Claims that Qwik gets zero JS on initial load and resumability via serialized state, so click handlers and tiny symbols download only when used. It uses a Vite plugin and an optimizer to split modules, plus speculative module prefetching via a service worker, yielding flat scalability as components grow (1→80) instead of growing JS payloads. Demo shows a server‑rendered counter that never executes component code in the browser until clicked, and the Qwik site uses this in production.
AI-written summary · about
chapters (12)
- 0:00Introduction to Quick
- 1:00The performance bottleneck
- 2:21The DX performance tradeoff
- 3:26Performance as a design issue
- 5:43Quick's flat scalability
- 7:13Limitations of hydration
- 9:08Resumability explained
- 10:45Solving system limitations
- 12:01Live demo and code
- 16:15How resumability works
- 17:06Speculative prefetching
- 18:43Forcing execution and conclusion
related talks
34mQwik: performance as a human design problem
21mQwik: web revolution by default
15mThinking Qwik!
30mQwik Go For 100
20mQwik
48mResumability in the next generation frontend framework With O(1) loading time
18mA Brief History of Web Applications — Why the Qwik JS Framework Is Innovative
18mResumability in the next generation frontend framework With O1 loading time