Qwik is very similar to other web frameworks at a high level. Qwik is a framework that renders a tree of components resulting in an interactive application.
The unique part of Qwik is not in what it does but in how it achieves its goals. Qwik's goal is to have instant-on applications, even on mobile devices. Qwik achieves this through two main strategies:
- Serialize the execution state of the application and the framework on the server and resume it on the client.
The goal of Qwik is having only to download and execute the bare minimum of the application.
By aggressively delaying the application download and execution, Qwik can provide near-instant startup performance that the current generation of web frameworks can't match.
Resumability & Serialization
Resumability is discussed in detail here. Resumability allows Qwik applications to continue execution where the server left off. All frameworks need to keep track of internal data structures about the application's state. The current generation of frameworks does not preserve this information when transitioning from the server to the browser. As a result, the framework's data structures need to be rebuilt in the browser, duplicating the work that was done on the server. The rebuilding of data structures and attaching of listeners is called hydration.
Qwik serializes listeners, internal data structures, and application state into the HTML during the server-browser handoff. Because all of the information is serialized in HTML, the client can just resume execution where the server left off.
What is the problem?
- Network bandwidth: A large amount of code is shipped to the client, which may take a long time on slow networks.
- Startup time: Once on the client, the code needs to be executed (as part of hydration) to get the site interactive.
As our applications get more complex with a higher fidelity of interactivity, the amount of code has steadily increased over the years with no sign of stopping. Simply put, our sites are getting more complex. An increase in site complexity, in turn, requires more code. All of this code negatively impacts site startup performance.
How did we get here?
Do you need to solve rendering, styling, animation, A/B testing, analytics, etc.? There is a tool for that. Just import or add a
<script> tag, and these tools will solve your problems, but at the expense of making the initial bundle bigger.
As an industry, we have failed to think about the implication of bundle size. Each tool solves a specific problem individually, but the size is not part of the equation. Size is the problem that emerges when you put all of the tools together, and by that point, there is very little the developer can do about it.
What's the solution?
Qwik is designed from the ground up to address the size problem. Small bundle size is its initial goal, and all other design decisions are subservient to that goal.
Size should not be a developer problem
Today, size is the developers' problem. If you follow best practices for each of the frameworks, tools, etc., you will have a large bundle size. It is at that time when developers start to mitigate the problem with some sort of lazy loading boundaries etc. (But as anyone who has done this will tell you: the options are limited.)
Our industry best practices lead to large bundles, and the web is full of examples.
The mantra of Qwik is that bundle size should not be something that developers should think about. It should just naturally emerge as part of how the framework is designed.
Qwik is designed from the ground up to produce lots of lazy loadable boundaries. Tooling can break up your application into many lazy-loadable chunks, and the runtime can download them only when needed.
Why not fix existing frameworks/tools?
In short, the lazy loading philosophy must be done at a low level and can not be retroactively added to the existing frameworks/tools without changing them fundamentally. Such fundamental change would be incompatible with the framework/tools and their respective ecosystems, rendering them useless.
When a framework makes certain assumptions, such as that all rendering is synchronous, adding asynchronous lazy loading becomes pretty close to impossible. Or, if a framework recovers the listener location from templates, then download and execution of those templates is a must before the site can be interactive. These are just some of the more obvious examples, but in practice, there is a long tail of endless reasons why the current mental model does not fit the requirements of resumability.
The above also means that it is not feasible for existing frameworks to add resumability as a feature. Existing frameworks will never be able to do what Qwik can (without breaking backward compatibility).
Why are we building Qwik?
Does page speed really matter?
Put simply: slow sites deter visitors, costing businesses millions. Fast sites have better SEO, better UX, and are more profitable.
Some examples from web.dev:
|Every 100ms faster → 1% more conversions
For Mobify, every 100ms decrease in homepage load speed worked out to a 1.11% increase in session-based conversion, yielding an average annual revenue increase of nearly $380,000.
|50% faster → 12% more sales
When AutoAnything reduced page load time by half, they saw a boost of 12% to 13% in sales.
|20% faster → 10% more conversions
Retailer Furniture Village audited their site speed and developed a plan to address the problems they found, leading to a 20% reduction in page load time and a 10% increase in conversion rate.
|40% faster → 15% more sign-ups
Pinterest reduced perceived wait times by 40% and this increased search engine traffic and sign-ups by 15%.
|850ms faster → 7% more conversions
COOK reduced average page load time by 850 milliseconds which increased conversions by 7%, decreased bounce rates by 7%, and increased pages per session by 10%.
|1 seconds slowness → 10% less users
The BBC found they lost an additional 10% of users for every additional second their site took to load.