Thinking Qwik!
summary
Claims that Qwik keeps initial JavaScript constant around a 1 KB loader and shifts app state into HTML via quick.json so pages become interactive without hydration. Uses a QRL resolver and lazy-loads tiny event-handler chunks that preserve closures with useLexicalScope. Demo compares Next.js sending 1.4 MB vs zero initial JS for Qwik, then Qwik fetches the ~1 KB core and per-handler chunks on click; Lighthouse numbers show optimize-JS moving score 80→97 and TTI 4s→2s.
AI-written summary · about
chapters (8)
- 0:00Introduction to Qwik
- 1:55Performance paradox in modern web
- 3:18How Qwik differs from hydration
- 5:03Resumability in Qwik
- 6:50Progressiveness in Qwik
- 8:34Demo: Next.js vs Qwik
- 13:59Qwik's event handling
- 14:30Conclusion and impact
related talks
18mResumability in the next generation frontend framework With O1 loading time
48mResumability in the next generation frontend framework With O(1) loading time
21mQwik: Performance is a Human Design Issue
30mQwik Go For 100
20mQwik
22mUsing the React Ecosystem with the World's First O(1) JS FRM
34mQwik: performance as a human design problem
49mJavaScript Streaming - A Qwik glimpse into the future