4 Reasons Why I’m Buying Into Qwik
Qwik is a new web framework. It is fundamentally different from current web frameworks. Here are 5 reasons why I’m currently rebuilding my home page with Qwik.
Exploring Qwik
I first recognized Qwik about 6 months ago. Two main facts were directly drawing my attention to this library: First, It is really fast and second, Misko Hevrey, the creator of Angluar, was involved in the library development. Angular was a game changer back then, and from what I saw, I guess Qwik will be as well.
Since then, I learned a bit about its concepts by reading and watching related content. 2 weeks ago, I finally decided to get serious and rewrite my home page (mainly a blog by now), using Qwik.
By now, I have a rough understanding of how it feels like to develop an SPA with Qwik and how it differs from other web frameworks. Here are some of the main reasons why I will continue using Qwik.
Reason 1: Resumability
Qwik implements a fundamentally new approach to Server-Side-Rendering (SSR).
In current frontend frameworks, rendering is designed to be done in the browser. SSR libraries like Next, Nuxt, Svelte-Kit and Angular Universal can then be used to pre-render the pages on the server. On the client, hydration kicks in and the whole application is re-rendered from the root.
Qwik, on the other hand, directly starts with SSR in mind. It uses a concept, called “resumability”. This is quite different from hydration. The app starts running on the server. Then a snapshot is taken. This is done by serializing the state and replacing event listeners with references, which are called “QRL”s. The serialized state and the QRLs are then compiled into the HTML document.
With the HTML, a minimal runtime library is shipped to the browser, which then loads the required functions on demand. I.e., when events are emitted on elements that have a QRL registered for this particular event type.
This way, only as much JavaScript, as currently is needed, gets interpreted in the browser.
In production, there is also a service worker who eagerly fetches the modules of the functions that are referenced on the current page. This reduces latency for the execution.
Reason 2: True reactivity (aka. fine-grained-reactivity)
Signals have become very popular recently. They enable change-detection of small portions of state within components. When a signal value changes, only the necessary parts of the template are re-rendered and the related DOM is updated accordingly.
In Qwik, you will not use the useState() hook as in traditional React apps, instead, useSignal() and useStore() are the way to hold state. Where a Store is basically a map of signals.
This means, state in Qwik is completely done with signals. This is not only important for high-performance re-rendering, but also is an essential part to enable resumability: It allows reflecting state-changes that are happening by event listeners, without having to re-render the encapsulating component.
Reason 3: JSX + MDX
Of course, it’s a matter of taste, which templating language you prefer. Having used many of those, I consider myself not very opinionated when it comes to templating languages. What I like about JSX is the good IDE and TypeScript support. It’s also very popular, so many frontend devs immediately feel at home.
Markdown is also battle-proven, and it definitely simplifies your life if you have some static pages. The “X” gives you the opportunity to bake in existing components.
Combined with the simple router, you can easily use both formats.
Reason 4: File-based routing
Qwik comes with a simple file-based routing system. It is also quite tweakable: You can nest and reference random layouts. Defining named path parameters is as simple as calling a directory [parameterName] . By now, I don’t see that anything is missing.
Bonus: Dev tooling
While debugging may be a bit challenging at times, there is a nice feature directly baked into the dev mode. You can Alt/Option + Click on any component in the rendered app, and it will take you to the place directly in your IDE (at least it works for VS Code).
This little feature is enjoyable for maintenance, and I can imagine that it can also help in the onboarding process of new dev team members.
Conclusion
I think, Qwik is right now, ready to use. It is not relevant whether you are about to build a lean website or a whole application, Qwik enables you to do this efficiently.
As mentioned before, I am currently rewriting my blog on the side. Together with using Qwik for the frontend, I will migrate to use Notion as CMS and bun as the server runtime. I plan to release the new version within this month. There will be more details about this stack in my next post.
Never stop learning and have a nice day!