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:
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.
Qwik's approach is to load almost 0 JavaScript. They do this by having
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
left.
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 img
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.
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:
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.
Moar Fetures...
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.
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:
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:
