Qwik: The Next Big Thing in the Frontend Ecosystem?
Published: Sep 25, 2022
Once again I find myself starting to write about something a little bit after the fact... I guess that's just the way I am. However, this time, it was a good thing, as I've' had to let some things settle in my head and around the the framework state (and not the kind of state that popped into your head 😜).
The framework I'm talking about (as you can tell by the headline) is Qwik which has just released it's initial beta along with "Qwik City", their own meta framework for building Qwik sites/apps. It's basically what Next.js is to React.
What is Qwik?
Qwik is the new buzz worthy framework in town, and rightfully so IMO. The 2 key features it brings to the table are:
It is built by the team at Buider.io , by an A-team of very well known and respected individuals of the dev community: Miško Hevery , Manu Almeida , and Adam Bradley .
Miško used to work at Google for 16 years, and is the man behing AngularJS and Angular . Adam and Manu are both behind projects such as Ionic , Stencil . Adam has also recently released Party Town 🎉 (also under the Builder umbrella) which helps contain 3rd party scripts on your websites.
The gist of what Qwik is trying to solve mostly, is the problem of SSR hydration. To better understand why this is one of the frameworks golas, I encourage you to read Miško's fantastic post: "Hydration is Pure Overhead" .
Why Should you care about qwik?
I was lucky enough to be a part of a small workshop that was held in Tel Aviv (curtosy of Shai Reznik 🙏🏽) with Miško. In this workshop, Miško dove deep into the motivations and implementations behing the framework. It was mind blowing. I was so enthralled by it, that I didn't take many notes, but I will try to share some inner insights he gave.
one single function which is under 1kb, and is in charge of resuming the
app on the frontend, right where the server stopped it. This allows the
framework to achieve
O(1) time complexity, while minimizing
TTI (Time To interactive).
The way to think about it, is like VM's (Virtual Machines). For example, you can start a VM that runs windows, open up a Word doc, and then close the VM. When you restart said VM - you resume from the same place - the open doc.
Qwik starts on the server, does the work, seralizes the app state and
framework state into HTML (in earlier versions with the help of
data-attributes, now it's all seralized JSON at the bottom of the HTML). Then when the
response goes down the wire to the browser, all the data is inside the
HTML and that tiny JS file can resume the excution where the server
The problem with most frameworks like Angular, React, Vue, etc. is that SSR (Server Side Rendeting) was an after thought. The initial bootup is the main issue. In a nutshell, all current frameworks do the same work twice - once on the server and then on the client to attach all the listeners and stuff it needs to actually be interactive. This is what hydration actually is, the client needs to "hydrate" with the framework bindings.
One key way Qwik circumvents this hydration overhead is the "lazy
loading" strategy. It can also be found natively in the browser on
tags (request the image only when it's close to the viewport). The basic
idea is not to load something until you need it. However, it's something
to tinker with and think about. Other frameworks have lazy loading but:
- They can only lazy load components not currently in the render tree so they have to do it eagerly.
- Their lazy loading can happen only after the framework is loaded where as Qwik can do it with just 1kb.
- They can only lazy load functions not closures .
Qwik aims to do most of the work automatically, as lazy loading is at it's core. Code is splitted by default and only loaded on interaction. Qwik lazy loads closures but only when they are needed for execution. Other frameworks lazy load functions to register listeners even if no one will ever trigger the listener.
In the React ecosystem, to achive code splitting you'd have to do it intentionaly by dynamically importing, and need to use something like:
In the past -
React Lazydoes the trick.
In Next.js -
Let me try and re-emphasise this point... Let's say you use React Lazy for every component, when you build the whole app, these components still have to load. Meaning, these components aren't bundled with the main app code, and they need to load and hydrate. This actually degragades performance.
Reduced Rendering: reactivity baked in, minimized rendering and code dowload, starts at server - restored in client.
Scalability: the only downloaded code is code the user uses.
- Code once: No need to separate server logic from client logic on the component level. DOM listeners are setup on server render, and are ready on client interactive.
What's the biggest kick though? Qwik uses
JSX, so if you
know React or Solid, you are going to feel right at home. On top of
that, reactivity and state managment are baked in.
So, if you're fed up with moving around code, adding lazy load boundries, and knowing that each feature you write is degragading the user experiece of your app - Qwik is definitly something to look into.
The Buzz, Excitment and wizardary
These are early days for Qwik, but it sure seems that a lot of folks are excited and hyped about it, myself included. The frontend scene has only started playing around with the framework, and the Builder team are doing some excellent work promoting, explaining, and getting the word out.
They have an aspirational mission:
The magic of resumability:
Even Alex Russell is excited:
Something I got really pumped about is that with this new paradigm shift things like micro-frontends (on the edge! ⚡️) might be easier to acheive. I highly recommend watching this conversation Steve Sewell (Builder.IO CEO) and Miško had with Pete BD from Cloudflare about running SSR on the edge:
Being a new Astro user , I got really gitty when I saw this tweet:
I'm pretty stoked about Qwik, and I hope I was able to convey why you should be as well. It seems like the team behind this awesome tehcnology has set to fix a lot of the performance problems the web has nowadays. Even if you aren't sure or ready to take on learning yet another frontend framework, at least know that this sort of endevour is what pushes the web forward.
It's at least important to remember where we came from and where things are going, so I'll end with one more slide from Miško's deck: