Resumability in the next generation frontend framework With O(1) loading time
summary
Qwik claims O(1) loading time by serializing app state and event listeners into HTML so pages boot instantly without hydration, then lazy loads tiny JS chunks on demand via a service worker. The build step (Qwik Optimizer) splits code at functions marked with a dollar sign and emits a quick.json loader mapping serialized state to URLs. Demo behavior shows single-click handlers and an on‑view clock download only what’s needed, while stateful closures may fetch additional code. resumability Qwik City
AI-written summary · about
chapters (16)
- 0:00Introduction
- 2:35What is Quick and promise
- 3:38Current rendering patterns
- 12:04Hydration problem in frameworks
- 14:56Slow initial loads problem
- 16:46O(1) loading time
- 18:58Quick demo setup
- 20:01State and event serialization
- 25:20Lazy loading mechanism
- 27:08Quick City and ecosystem
- 30:05Quick vs React differences
- 34:30Q&A: Network dependency
- 37:07Q&A: Component architecture
- 41:40Q&A: Lazy loading types
- 44:34Q&A: Offline behavior
- 47:24Closing remarks and thank you
related talks
18mResumability in the next generation frontend framework With O1 loading time
28mIntro to Qwik: The Answer to Web App Scalability Issues
15mThinking Qwik!
20mQwik
26mMake it Resumable with Qwik
21mQwik: Performance is a Human Design Issue
34mQwik: performance as a human design problem
22mUsing the React Ecosystem with the World's First O(1) JS FRM