Qwik is one of the next generation front-end frameworks that tries to do something new again. At a high level, the framework is very similar to other frameworks such as Next.js, for example. The strength of Qwik does not lie in what they do and what they want to achieve, but in how they do it. You can read more about how Qwik holds up against other frameworks in this post.
Yet another JavaScript framework?
What does Qwik do differently from other frameworks/libraries like React? Qwik is a framework that renders a tree structure of components, resulting in an interactive application. Qwik applications use Server-Side Rendering (SSR) / Static Site Generation (SSG) out-of-the-box.
- SSR: Rendering components on the server and sending them to the browser to make the static HTML interactive.
- SSG: Generating completely static HTML pages based on templates or components.
These two concepts are important as Qwik differentiates itself in them. Qwik tries to address pain points of the current generation front-end frameworks.
What problem is Qwik trying to solve?
Almost all front-end JavaScript frameworks have a way to pre-generate content as HTML via server side rendering (SSR) or static site generation (SSG). The result is that the site appears in the browser almost immediately.
However, there is a problem. HTML is static, while websites are mostly dynamic and interactive. How do the frameworks make pre-rendered HTML interactive on the browser? The current generation of frameworks solves this through a client-side process called hydration, a resource-intensive process that adds significant overhead to page startup time. Qwik has come up with something for this and calls it resumability.
Hydration vs Resumable frameworks
The terms hydration and resumability appear when we talk about SSR/SSG. To understand what makes Qwik special, it is important to look at what exactly hydration does.
How does a framework make a page interactive?
Every front-end framework needs three things to make a page interactive:
1) Associating event handlers: The framework must have a way to associate DOM elements with their associated event handlers, which are the functions that respond to user input and enable interaction with the website.
Unfortunately, the JavaScript bundle download size and execution time is proportional to the complexity of the page. A small demo page will download and run a small amount of JavaScript quickly, but for complex applications this can result in several seconds of Time To Interactive (TTI). This is the time you have to wait for the web application to be interactive.
2) Handle application state: As soon as a user triggers an event handler or the backend pushes a state change, the application state must be updated throughout the application. State changes need to be handled to represent the new application state in the Component Tree Hierarchy.
3) Recreate the component tree hierarchy: When the application state updates, the framework must re-render the application and its components to reflect the change(s) to the user interface.
Each step requires downloading and running code, which is less efficient. A solution to this problem is to eliminate the code needed to restore page interactivity. Here’s what Qwik solved with resumability.
The Qwik way: Resumability
Hydration frameworks repeat all application logic in the browser. Qwik pauses execution in the server, then resumes execution in the browser. With resumability, the focus is on transferring all the necessary information from the server to the client without downloading the JavaScript. Only upon user interaction is the browser told to download the JavaScript code required for that specific interaction. Qwik makes this possible by serialising the application and framework state on the server.
React and Next.js
The React library and its relative Next.js framework are well known in the frontend development world. For example, React has its own goals and Next.js builds another layer on top of this to achieve specific goals and results. You can read more about this below.
As quickly as possible
Web applications built in React are very fast and the library is known for its speed. This is partly due to the use of a DOM (Document Object Model) and also a Virtual DOM.
Using the Virtual DOM, which is a minimal copy of the real DOM in working memory, is an effective way to handle rendering the DOM. Without the Virtual DOM the entire DOM needs to be rendered again. This is not efficient at all.
When an update needs to take place in the DOM, React updates the Virtual DOM and quickly compares this to the actual DOM and only the parts that are needed are updated there. This saves a lot of time and makes the web application much faster.
The purpose of Qwik
Qwik’s main goal is to achieve maximum performance and shorter loading times. They do this in a number of different ways, as follows.
Less is more
Qwik tries to use JavaScript as little as possible. They do this by storing the state as HTML attributes instead of JavaScript objects, as is the case with other frameworks like Next.js.
Instant on
With other frameworks that use Server Side Rendering (SSR), there are two possibilities. Either the JavaScript that is required is already loaded on the server and then sent to the client, or the server only loads the HTML and allows the client (the browser) to load the required JavaScript.
This concerns, for example, event listeners and event handlers. Qwik, on the other hand, stores event listeners as HTML attributes and then sends an HTML page with minimal JavaScript to the client. This ensures maximum performance during the first page load, regardless of the size of the application.
Fine grained lazy loading
In addition to superfast initial loading times, Qwik’s goal is to achieve fine-grained lazy loading. This means that (as with the first page) all JavaScript code that is not immediately needed will not be downloaded immediately. Only when the user interacts with the website, the necessary JavaScript is loaded for this.
Performance
Qwik is a next-gen framework that mainly focuses on shipping less JavaScript and achieving the fastest possible loading times. For both desktops and mobile phones. You can read below how Qwik tries to achieve this.
Asynchronous Lazy Loading
Unlike (most) other frameworks, the Qwik framework is completely asynchronous. This means that Qwik always takes into account the fact that certain callbacks are not immediately available and have to be loaded lazily.
import { component$, useStore } from '@builder.io/qwik';
const Counter = component$(() => {
const store = useStore({ count: 0});
return <button onClick$=(() => store.count++)>{store.count}</button>
});
In the code above a Counter component is defined. The dollar sign (component$) indicates that this component may only be downloaded when necessary. Also, inside the component is a dollar sign next to the onClick$() function. This tells Qwik to not download the implementation of the onClick$() function until the user clicks the button.
Everything in the DOM
Qwik is a stateless framework. This is because the entire state is stored as HTML attributes in the DOM. This ensures that the state with the DOM is also serialised to HTML, so that it can be sent quickly to a client (the browser). An attribute also keeps track of whether a DOM element must be rendered again or not.
React/Next.js VS Qwik
| Parameter | React/Next.js | Qwik |
|---|---|---|
| The state is saved as | JavaScript Object | HTML Attribute |
| When will code be downloaded and made available | Immediately upon page load (unless using dynamic import/streaming with Next.js) | On demand when the user interacts with a page |
| Size of JavaScript start code | From a few 100kB to a 1MB | <1KB |
| JSX/TSX | Yes | Yes |
| Loading times | From 1 to multiple seconds (depends on the complexity of the page) | Almost 0 (immediately) |
Popularity and future
Qwik has introduced a new concept to the front-end framework world, and this requires a different mindset for developers. If you look at the latest stateofjs survey and the history of Github stars you can see that Qwik has quickly become popular and its popularity is still growing.
Despite the growing interest in Qwik, it is still little used. So whether the framework actually has a future where it can compete with better-known frameworks such as React remains to be seen.
Qwik is investigating the possibility of using components from other frameworks (React, Vue, Svelte, Angular, Solidjs) within the Qwik framework in the future. Whether resumability will become the new standard of front-end frameworks is uncertain, but it certainly is an interesting innovation.
Conclusion
Qwik is one of the new kids on the block and really does something “new”. With resumability It tries to fix the “issues” with hydration, for example. Nevertheless, the lazily loading of the code at the point when the user’s request it has some drawbacks too. It can take time to download the needed JavaScript and execute it. This can result in a less snappy experience when clicking buttons or other components which have a lot of functionality behind it.
A big plus for Qwik is the initial loading time for web pages. And if there is a lot of focus on Time To Interactive (which will result in getting better SEO scores for Google), Qwik is the way to go. It also uses the same JSX/TSX syntax as other frameworks do. And in the future they want to support components from other frameworks like Vue and React.
Qwik is still under development and there is a lot more to come for Qwik in the future. Whether Qwik will be used more and whether it will really become a big player on the market is still the question. But for now it seems like a very promising framework.
