Qwik: the future of frameworks?

What is the problem Qwik is trying to solve?

As web developers, we want to develop the best User Experience (UX) possible. User experience is about two things: making websites interactive and making them responsive. But those goals are naturally contradictory: interactivity means downloading JavaScript and downloading JavaScript makes websites slower and less responsive.

React is a great solution for creating complex interfaces … but in standalone React, you have to download all the code before showing any interface. From the user’s perspective, your website is slow. And from a Search engine bot, your website is expensive to read.

The solution developed by Next JS in collaboration with React is to do the** initial render on the server** — this is what is called Server Side Rendering (or SSR). This way, the client sees the interface and the text before the app downloads any code, and Search Engine Bots have a much easier job indexing the page.

However, once the browser receives the HTML, it downloads the JavaScript from the server and re-starts the application in a phase called “Hydration”. Once hydration is complete, the browser takes responsibility for the rendering. And to do so, it re-renders the application, it synchronises itself with the server.

But this means that the browser does the same rendering work the server has just done before being interactive. The same work is being done twice. Once on the server, and once for the client to catch up with the server.

Instead of downloading the framework and running the same render the server has just run, Qwik does something different. Qwik’s output contains almost no JavaScript and doesn’t do any hydration, which results in blazing-fast performance.

How does Qwik achieve that?

Why is Qwik revolutionary?

Qwik has two tricks up its sleeve. It does Dynamic Tree Shaking and Resumable rendering. How? Let’s talk about how a page ends on the browser.

Dynamic Tree Shaking

Like Svelte, the first place where the magic happens is in the compilation phase. Here, Qwik breaks up all the application logic into small bundles. In Qwik, every closure — basically every block of code — can become a chunk. This is done using a compiler written in Rust, which identifies when each bit of code is called.

The bits of code that are never called, and stuff like comments, are discarded. This is basic Tree Shaking, which every compiler does.

However, the Qwik compiler also identifies which bits of code are only called in the initial render and which are required for additional interactivity. What does it do with those chunks? Well, first, it renders the page. How does Qwik do that?

Resumability

A few things are worth noting here. First, like React and Solid, Qwik uses the JSX syntax to define the HTML output.

However, unlike React, Angular, Solid, or Svelte, Qwik is a server-side framework. In a sense, Qwik is closer to Next JS than to React. Like NextJS, Qwik does a render of the HTML output using the JavaScript code.

However, unlike NextJS, Qwik doesn’t just care about rendering. It also cares about Lazy Loading, Chunks, Entry points, serialising the state and resuming it.

Let’s talk about that last bit. Compared to NextJS, Qwik sends more information in the HTML output and sends less JavaScript code. Qwik records the framework state in the HTML sent to the client. That’s the first step towards “resumability”. That state includes component boundaries, event listeners, and the application state.

The second step is that every interactive bit of the interface holds a reference to the small chunks of code we mentioned previously. That reference is a link to the JavaScript code.

The final piece of the “resumability” puzzle is a small 1kb Qwik Loader. This uses web workers to download the small chunks of JavaScript produced in the first phase by the compiler. The tiny bits that the page needs to be interactive. The Loader does this in the background without using up the main thread. This is basically how Partytown works. No surprises there since it is developed by Builder.io, as is Qwik. Not only is the JavaScript code Lazily Loaded, but it is also Lazily Executed.

It’s exactly as if the required JavaScript was streamed to the browser when it is needed, instead of as a big chunk. In fact, this reminds me of the difference between downloading and streaming a movie.

There is a streaming protocol called HLS. This works by cutting a movie into tiny pieces that are then served via HTTP. Streaming a movie means downloading this sequence of tiny bits of the movie. And you only need to download the bits coming after where you are at in the movie. You can resume playing wherever you’re at. The compiler, the “Optimizer”, is what produces the tiny bits. The Qwik Loader is the player that fetches the chunks it needs.

This is what allows Qwik to be so fast and responsive.

So… is Qwik worth learning?

We already have about a bazillion frameworks fighting for developer mindshare. Is there really any point in learning a new one? I mean, I’m already at something like a 97% score on my NextJS-based website. Do I really need 100?

I have two answers to this question.

First, I’m personally satisfied with 97%. Sure, Qwik will get me 3 percentage points more. But NextJS comes with a rich ecosystem. It’s the reference implementation of React. NextJS has plenty of libraries that allow me to do everything I need to do. The documentation goes deep, and there are numerous resources… All that is missing from Qwik. So I don’t think I will use Qwik for serious projects, at least for now.

However, and this is a big however: I do believe the way Qwik is doing things** is the future**. This means it is important to understand how Qwik works. How it is structured. Where the magic lies. And what it implies in terms of how we code — particularly, what happens when the code is split up into tiny bits.

However, I don’t think we will all be using Qwik in the future. But it’s likely that React and NextJS will be, shall we say, inspired by Qwik’s innovations. And learning Qwik will give you a head start. And a new perspective as to how frameworks … work.

So yes, I do believe it is a good idea to use Qwik. Which brings me to my next point:

How to learn Qwik

If (like me) you’re interested in learning more, I recommend the free course created by Qwik and featuring Miško Hevery, where he explains why Qwik exist, and how to use it. You can find it at qwikschool.com. The Qwik website documentation is also very instructive. The section on resumability vs hydration is particularly interesting. And there are also several interesting podcasts, one entitled Qwik is a new kind of framework, and another Qwik has the right amount of magic .

Frequently asked questions

Q: Hey there, what is Qwik? A: Qwik is a new JavaScript framework created by Miško Hevery and the Builder.io team. It's a resumable framework that renders server-side HTML to optimise performance and completely removes the hydration step that other frontend frameworks use.

Q: What's so special about Qwik? A: Qwik's core principle is to load as little JavaScript up front as possible and delay the execution of any other JavaScript on the page until it is needed. This allows the application to progressively download code, instead of a big initial bundle. This improves the “Time to Interactive” (TTI) metric.

Q: Can I use Qwik with Netlify? A: Absolutely! Qwik includes an Optimizer written in Rust to transform the code at build time and uses Vite for Hot Module Replacement (HMR) and bundling. You can deploy Qwik applications on Netlify using Netlify Edge functions with a Vite plugin.

Q: How do I get started with Qwik? A: The easiest way to get started with Qwik is to use the Qwik CLI tool. Simply type "npm init qwik@latest" into your terminal and follow the prompts to choose a blank starter app and Netlify as your hosting provider. The CLI will then automatically configure packages like Eslint, prettier, and TailwindCSS for you.

Q: Is Qwik still in beta? A: No, Qwik has just released version 1.0 and is no longer in beta.

Q: How does Qwik achieve “resumability”? A: Qwik uses both server-side and client-side rendering to avoid double taxation. The server sets up an HTML page as fully functional as possible, and the client performs the smallest amount of work possible to continue or resume the process for the user. This process is called “resumability”, and it means the client can pick up where the server left off without having to rebuild the app on the client.

Q: How does Qwik perform code splitting? A: Qwik performs fine-tuned code splitting by loading interactive code as required when the user demands it. This improves performance and reduces the amount of JavaScript loaded up front. Qwik uses an advanced reactive engine that defines reactive boundaries along state templates and listeners to improve performance as well.

Q: Is Qwik developer-friendly? A: Yes, Qwik has evolved to support a more developer-friendly React-like syntax, making it easier for developers to work with. Qwik uses a fine-grained model for isolating the segments of the app that are hydrated on an as-needed basis, and it starts from first principles to deliver remarkable performance.