Let’s take a look at the following:
- Why Qwik’s approach is promising.
- How other frameworks have inspired Qwik.
What is the problem Qwik is trying to solve?
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.
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.
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?
A few things are worth noting here. First, like React and Solid, Qwik uses the JSX syntax to define the HTML output.
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.
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: 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: 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.