Introduction and why Qwik matters
I don't know about you, but these days I feel like we get new big releases in the front-end space on a weekly basis. Despite being always mocked by its ever-changing ecosystem and the constant hype train, the web dev world is more alive than ever. Anyhow, let's not waste any more time and talk about one of the big releases of this week. Qwik JS just reached version 1.0. I know, I know—yet another JavaScript library, you probably grew tired of all of them by now. Hear me out though: Qwik really deserves your attention, and in the next few minutes I'm going to show you why.
Compared with alternatives such as React, Vue, the Wilder Solid, Qwik is built and architected differently from the ground up. To clarify this idea we should probably define two important concepts slowly shaping the front-end development space. On one hand you have these things called UI libraries—think of the likes of React, Vue, or Solid. In short, these are tools allowing you to add interactivity on a static web page. These are the libraries which popularized the idea of single-page applications and when used will rely on client-side rendering to convert JavaScript objects and methods into DOM elements and event handlers. You probably worked with such tools in the past and got a chance to see them in action with both their pros and cons. One of the main disadvantages of JavaScript UI libraries is, funny enough, their heavy reliance on JavaScript: rendering HTML via JavaScript implies slow loading times and worse performance over time. Thus the second term we need to define is meta-frameworks, the tools used to address some of the pitfalls brought up by UI libraries. Think here of Next.js for React, Nuxt for Vue, or Solid Start for Solid. Among other various benefits, these frameworks have one big task: alleviate the worst of client-side rendering by engaging the server in the process of converting JavaScript objects into HTML. Of course, once the HTML reaches the browser the JavaScript still needs to be sprinkled in via a process called hydration, so you'll still get a couple of seconds when the app is visible but not interactive. This process is called the uncanny valley. But enough with the rendering theory—we are here to discuss Qwik. If you are interested in details regarding rendering strategies, please check the video in the top right corner.
Qwik's resumability and HTML-first architecture
So what makes Qwik so different? Let me explain. Instead of going the usual hydration route, Qwik employs an approach called resumability, which in short means that at any point an application lifecycle can be stopped, serialized, and moved to a different environment—either a server or a browser. Once the app is in the new environment it simply resumes from the point where the serialization stopped. This is the cornerstone of Qwik's take on building full-stack apps. Yes, you heard this right: full-stack apps. Take a mental note because we'll get back to this one in the second part of the video. As you would expect there are a bunch of other features and architectural decisions in play here. For instance, your app will get instant loading time since all Qwik apps are HTML-first. This means that static HTML is sent from the server and then the needed JavaScript is streamed to the client only when needed. This approach is combined with speculative code fetching and lazy execution so that the framework delivers only the JavaScript code needed, only when it's needed. Just like with most things in life this is usually easier said than done. There is a lot of heavy lifting happening in the background to support this resumable architecture, and during the process Qwik has to solve three problems correctly: attach listeners to static pages efficiently, rebuild component trees between resume processes, and reliably handle app state across sessions.
Developer experience and component model
For the past couple of minutes you've seen me writing some Qwik component, so you should get a feeling about the dev experience by now. The code should look pretty familiar, especially if your background is in a library such as React, since Qwik uses features already accepted by the front-end community as established solutions for various problems. In here you'll have function components to group together related code and business logic, hooks to handle effects, state or the lifecycle, and JSX for templating purposes. One big difference compared to a library such as React is that Qwik components run both on the server and on the client by default. However, in real world scenarios there are various situations when you'd like to run code only on the server or only on the client. Don't worry though—Qwik provides simple yet powerful mechanisms to accomplish such things.
Server functions, endpoints, and Qwik City
Take the server function for instance. This one is an interesting case study since it allows you to create a function that always executes on the server while providing an RPC mechanism so that the client can retrieve the information resulting from the server function call. How is Qwik achieving this complex task in such a seamless manner? The server function wraps a function and returns an async proxy to the function. The server directly calls the route function and an HTTP endpoint is created and exposed to the client. Then on the client, using the endpoint, the proxy function invokes the wrapped function via fetch call. A little bit earlier I mentioned that Qwik allows you to build full-stack apps. Again, if you are up to date with the most recent trends in web development they should not come as a surprise. Just like most meta-frameworks, Qwik exposes an endpoints-based implementation that allows you to pretty much create complex REST APIs running seamlessly on a Node environment. The path listeners are defined via a directory-based routing solution—another industry standard at this point—and they can be consumed by your components. By the way, these advanced routing and data endpoint capabilities are part of a meta-framework built on top of Qwik called Qwik City. This is rather an opinionated tool with a bunch of other useful features such as nested layouts or file-based menus, and the chances are you'll work with the entire Qwik City framework whenever you want to get started with this stack.
Practical notes, optimizer symbols, and lazy loading
Just as an FYI though, these endpoints are not a one-size-fits-all solution. While powerful and flexible, they are best suited for prototyping and smaller projects. When developing for large applications my suggestion is to still stick with a proper back-end technology in order to better address topics such as security, performance, and scalability. One thing that might have caught your eye in the code is the heavy use of dollar signs. I'll explain the role of this in a second, but first I'd like to ask you to help me fight the big bad YouTube algorithm by liking this video and subscribing to the channel. Ok, so one of the more annoying bits about Qwik, especially for devs first looking into the framework, is the use of dollar signs. While inconvenient at times, this is the mechanism that allows Qwik to do all its under-the-hood work and optimizations to reach such impressive performance metrics. In short, the Qwik optimizer splits your application into many small lazy-loadable chunks called symbols. The dollar sign suffix is used to signal both the optimizer and the developer when such a transformation occurs. So a component can be divided into multiple such symbols, and these symbols will be loaded on the client lazily, only on demand. To better visualize this, consider a component with a non-key input and a click listener. When the component is first rendered and sent to the browser, there is no reason for Qwik to send the event handlers as well—maybe the user will never trigger any of the events. Therefore the two listeners will become two separate symbols stored in separate files. The component shipped to the browser will contain special links called QRLs pointing to those files, and whenever one of the events is triggered the chunk of the data is downloaded and executed on the client. Don't worry though—it has been asked before and now the initial download of the chunk will not cause lag or slowness in the app. Of course, besides original features such as resumability or the QRLs, the framework comes back with all the features you would expect from a professional production-ready tool. I have a couple of other videos on my channel looking at other features in detail, but please let me know in the comments if you are interested in more content on this subject, especially now that Qwik provides various stable integrations with libraries such as Auth.js or the Builder.io visual headless CMS. Until next time, thank you for watching.
