We got together with Miško Hevery @mhevery to learn about Qwik during a JavaScript Maration event which you can go and view here
Why Qwik?
Qwik is a new kind of JavaScript framework with the goal of more quickly starting up applications. Many studies show that if you can deliver the content faster to the user, you'll have better conversions, better profit, and your website will be more highly rated. Existing frameworks have a hard time getting there, and the reason for that is hydration. Qwik focuses on another method called Resumability.
Here is a photo to show the process:
What is Hydration?
Hydration is when your content pre-renders on the server side. Before you interact with the content, you actually have to download your application itself, and then, the application has to execute. When the application executes, it has to do reconciliation.
In reconciliation, the application figures out where the listeners are in your page, and attaches the listeners to your DOM. When you navigate to a classical web page, you will see content delivered to you through server-side rendering.
Then, a huge amount of JavaScript has to execute before the page is actually interactive. Hydration can be very expensive, and on a mobile device, it can take several seconds before the page is interactive.
Qwik Goes for Resumability
Resumability aims to deliver HTML, and have the application interactive immediately after delivering the HTML, basically skipping all the work involved with hydration.
This allows for faster startups, and Qwik uses this with the same component mental model as other frameworks. When you're developing a Qwik application, you should think about the whole thing in pretty much the same way you would building any other web application up to now. What changes is what happens on the other side with rendering.
Rendering with Qwik
Existing frameworks usually care about rendering on the client side, and because of that, there are limited kinds of things that they can do. While Qwik does care about rendering on the client, it also cares about rendering on a server, serializing the data, creating and prefetching bundles, and delivering all that content to the client.
Qwik tries to think about the problem of rendering end to end, and it can deliver things that other frameworks cannot.
Demos
Miško goes through some demos to show off the capabilities of Qwik.
Simple App
He starts with a very simple page:
With this simple page, he shows how Qwik will only deliver JavaScript to the client if there is actually a need for it. This, he explains, is "dynamic tree shaking", and it can remove a lot of behavior that you don't normally need with such a simple page.
Counter App
Since there isn't much rendering to do with a simple page, Miško shows us how a counter app would work. He does this to show how Qwik would work with a more interactive page.
What's interesting about this part is when you look at the kind of code that's downloaded, you'll see that the only thing downloaded is only what was necessary to process this particular event.
Here, he also shows the difference in how Qwik did this process, and how other frameworks would frontload and execute everything ahead of time. This shows how it is faster at startup than other frameworks.
He goes further into this app by showing the importance of Qwik, not only downloading the funciton of what the code is doing, but also, downloading the initial state. This allows Qwik to serialize the information about the button into the HTML, and it knows what piece of code to download and what state to restore.
If you look at a normal framework, it lacks any infomation to tell you where the listeners are. Because of this, the framework has to download the application, and figure out where the listeners are.
By flipping the way things work around, Qwik is able to serialize the information about which piece of code needs to be downloaded by lazily downloading and executing that piece of code.
ToDo App
Miško shows a more involved app, and progressively shows how more code downloads as you make changes, and edits within the app. He shows how instead of the code downloading eagerly, it instead only downloads as he makes changes.
How does Qwik know to lazy load in the code?
Qwik breaks things up into pieces. Let's say there is an app that has to render both a child and grandchild component. It starts by only re-rendering a child component at first and then, two seconds later it re-renders a grandchild component.
This is a common theme for Qwik, and a developer doesn't have to write anything specific in order for the app to render in this way. The developer doesn't have to write any lazy loading behavior or relationships between components.
The magic happens any time you see a $ inside of the url. It is both a development optimizer, and hint that a lazy loading event should happen. This allows the app to offload huge amounts of work from the client, and makes sure that when we navigate to the application, they have a very quick startup performance.
The ways existing systems work
Miško goes on to show how other common frameworks use hydration for loading apps.
Monolith
With this system, you get a pre-rendered application where everything is grayed out, meaning that it's not interactive. Because everything is grayed out, the browser needs to download the application code. Once everything is downloaded, the browser can execute the application, and as it is being executed, it can attach to listeners.
The term hydration comes from everything turning blue once you are able to interact with these particular components. Steps two and three in this process can be expensive. So to save time, you want to skip these steps.
Lazy Monolith
Lazy monolith takes an SSR HTML from the server and renders it to the browser. But instead of downloading everything at once, it creates a lazy loaded boundary.
The component is visible on the other side of the lazy loaded boundary, but you still have to download it. The browser has to go back, download even more JavaScript, and execute all the JavaScript.
This makes lazy loaded boundaries in existing framworks useful only for components that are not currently visible on a page. If a component is already visible on a page, lazy loaded boundaries are actually detrimental because now you have to make two round trips to the server instead of one.
Island
This is a great improvement because, intead of having one expensive thing that has to happen all at once, you have smaller things that have to happen later.
The downside is that it is still using hydration. The first interaction might still be slow, and there are independent islands. Because of the independent islands, there is no easy way to communicate between them, and so you would need to sovle the island communication problem.
Resumable
Qwik is different than these other methods. It is still in a server-side mode where everything is pre-rendered, but it's also inactive. However, when you interact with a particular component, Qwik knows how to wake up just that component and nothing else on the page.
It allows you to surgically go in and select the specific component and allow it to wake up and nothing else. It also understands relationships. If you go in and interact with a particular component, it knows to wake up another component.
As you interact with specific pieces, it downloads just the necessary code and nothing else.
Responding to Questions
Miško then takes the opportunity to respond to questions that are asked during the streaming event. He takes time to answer the questions by showing how Qwik is different and useful from other common frameworks.
Wrapping Up
The website for Qwik is a great resource for anyone wanting to learn Qwik.
They also have a discord community with lots of examples and tutorials on how to use Qwik. There is also a place to try things out as well.
Qwik is a very different approach to how applications are built, and it should have a huge impact on startup performance of existing applications.
Are you planning on trying Qwik today?
