Another JavaScript framework? Qwik
What is Qwik?
Much like React, Qwik is a framework that renders a tree of components resulting in an interactive application.
Qwik's goal is to be fast.
This is achieved using:
- delaying execution and download of JavaScript for as long as possible.
- snapshot the state by serializing the execution state of the application on the server and resume it on the client.
- being very light, a Qwik application only needs about 1KB of JavaScript to become interactive.
Qwik is fast because if its simplicity and the focus towards keeping things small
It serializes listeners, internal data structures, and application state into the HTML on server to browser transfer. Because all of the information is serialized in HTML, the client can just resume execution where the server has stoped and this snapshot like feature 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 from the server to browser transition. As a result, the framework's data structures need to be rebuilt in the browser. The rebuilding of data structures and attaching of listeners is called hydration.
In simpler words, Qwik becomes attracive because of the reduced bandwith required when serving the data in comparison with "the competitors". The design decisions are subservient to keeping the application as small as possible.
Qwik is not about creating less JavaScript. Qwik is about not having to ship all of that JavaScript to the client at once on application startup. Qwik is what you end up with when you take the idea of delay loading of JavaScript to the extreme.
All sounds good so far but how does it work?
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 is 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.
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).