What Makes Qwik Different?
So there's a newest JavaScript framework on the horizon called Qwik and in this series I'm going to teach you how to get up and running with it pretty quickly to make your own websites. And before you start ripping your hair out thinking it's just another framework you need to learn, I want to quickly go over why this one stands apart from the crowd a little bit and why it's suitably called Qwik. And it's all to do with something called resumability, and we're going to talk about exactly what that is in this first lesson.
Introducing Qwik and Qwik City
So then Qwik is a JavaScript framework for creating interactive web applications, but it sets itself apart from other frameworks in its approach to how it renders the application. And that distinction is something that can have a really big impact on the performance of your sites. The clue is in the name, right? It's called Qwik, which definitely doesn't imply that it's going to be anything other than lightning fast.
So what is the difference and how does it make it quicker exactly? So when we make Qwik sites, we'll probably do that using a meta framework called Qwik City. And Qwik City is to Qwik what Next.js is to React, or what Nuxt.js is to Vue, or what SvelteKit is to Svelte. It's a meta framework built on top of Qwik that we use to make Qwik apps with built-in routing and other things.
The Hydration Model Explained
So first of all, let's talk a little bit about how those other meta frameworks like Next.js or Nuxt actually work. So in those applications, you might send a request to the server for a website and the server, whether it be for a Next site or a Nuxt site, would render an HTML page based on the components in that application, right? So it would build up an HTML template and then send that HTML page to the browser.
Now, that HTML page would be a static HTML page to begin with. There would be no interactivity or state or components involved in that HTML. It's just a template that's been generated on the server based on your component tree. So in order to add that interactivity and state to the app in the browser, the server also sends the JavaScript components for the page, which then run in the browser. And when this JavaScript runs, it's basically working its way through your component tree, recovering the application state, and injecting the interactivity into the HTML page by attaching event listeners. And it's only once that's been done that the page becomes fully interactive, right? And this process is called hydration in the client or, in the case of certain frameworks like Astro, partial hydration, which is a more component-level hydration rather than full-page hydration.
But essentially in either case, we're running the component JavaScript twice: once on the server to initially render the HTML page, and then a second time in the browser to recover the state and add the interactivity to the page. We're hydrating the static HTML page in the browser, right?
How Qwik's Resumability Works
So that's hydration, the method a lot of other JavaScript frameworks use to kickstart these applications in the browser. But Qwik or Qwik City applications don't use that hydration approach, and instead they do something completely different which results in a quicker load time in the browser.
So what Qwik does after we send a request to the server for a web page is run through the JavaScript components to render an HTML page, much like other frameworks do, but this time it also serializes extra information into the HTML document as well: the application state, component boundaries, event listeners, etc., something that other frameworks don't really do. And then once all that information has been serialized into the HTML, it sends it on to the browser.
Now, in the browser, we have this HTML page with the extra data serialized into it which describes the application state or event listener functions or component boundaries. And therefore, there's no reason to run any initial JavaScript eagerly in the browser to figure all of that out again. There's no need for that initial hydration process because everything that's needed has already been serialized into the HTML. So I guess you could say that it's a bit like a supercharged HTML file which contains all the initial information it needs.
This approach is called resumability because the application essentially resumes in the browser where it left off in the server. There's no need to run any more initial JavaScript. Everything's set up from the get-go in the browser, and we only need to run more JavaScript after a user starts to interact with the page and when it's needed.
So this resumability approach is quicker because of two reasons. First of all, we don't need to download the initial component JavaScript to the browser, and we can completely skip out the hydration step because all the data is already serialized into the HTML when it comes from the server. And this is the crux of what sets Qwik apart from other frameworks. And it does this with very little impact on the developer experience. So we don't have to think too much about this as we develop Qwik applications; it's the default behavior wired into the framework.
So just as a quick example, you can see here a page I've got back from the server which is using the Qwik framework to render the HTML page. And in the dev tools, you're going to see within the HTML template we have some of this extra serialized data and information. This was all generated on the server when the page was rendered, and it was sent back to the browser like this. This is all the stuff that makes the page instantly interactive and able to recover the application state without having to run any JavaScript. Unlike a framework such as Next or Nuxt, if you open the network tab, you can actually see that no JavaScript was initially downloaded from the server because it's not needed for the hydration process. We're only going to request any JavaScript as and when we need it, for example, by clicking on a button which toggles a modal component or runs some other kind of code.
Automatic Code Splitting & Lazy Loading
At this point, it will then only download that modal component JavaScript and execute it. So we're only running JavaScript in the browser on-demand as we need it, and not when the page first hits the browser. And Qwik handles all of that code splitting and lazy loading for us out of the box, which is really good because as developers we don't even need to think about this. It's the default behavior of Qwik. And it does this on the server; when the app runs, it splits our code into really fine-grained, separate chunks and only then sends those to the browser when they're absolutely needed, which is really cool. And we'll see how that works later on.
Qwik's Philosophy & Similarity to React
Another thing Qwik does is update any state in the template surgically without having to rerun the component code itself. So I really like this kind of approach that Qwik implements, this resumability, and I think especially for more complex applications, it's going to result in a much better performance.
That's not to say that this is better than React. I'm not here to say choose one framework over the other. At the end of the day, it's down to personal preference and what best suits your application. And for a lot of times, that's going to be React or Next or Nuxt or whatever it may be. But I do like what Qwik brings to the table and its whole ethos of delaying the download and execution of JavaScript until absolutely necessary, because generally speaking, sites with less JavaScript running perform better, right? And as you develop your Qwik apps, that's the kind of ethos you have to keep in mind, which is something we'll probably keep coming back to.
And on top of that, if you are familiar with React, then you're going to feel right at home with Qwik too, because how we work with Qwik components is very, very similar to how we work with React components at a high level.
Course Overview, Prerequisites & Resources
So in this crash course, I'm going to get you up and running with Qwik and teach you all of the basics so that you can start developing your own applications with it. And during this series, we'll be using what we learn to make this website. It's just a really, really simplified blog site.
Now, one thing I do want to mention is that at the time of recording this course, Qwik is still in beta, so there may be some small changes in the future before a stable release. That said, Qwik did also say that they're making everything backwards compatible as they go forward, and there shouldn't be any major breaking changes, so feel free to dive right in.
Before you do start, though, you will need Node installed on your computer, at least version 16. And to do that, just head to nodejs.org and download it. Now, to see the node version installed on your computer, open up any terminal and type node -v and press enter. If it is installed, you're going to see that version number right here.
And finally, as always, I've created course files for this entire series. You can find them at this GitHub repo right here: qwik-crash-course-first-look. And I'm going to leave this link down below the video. So this code for every lesson at this repo, you just need to select the lesson you want the code for like so. And then you can download it by hitting this and then downloading a zip folder.
Watch Ad-Free & Final Words
So that's all the course files. I hope you enjoy this course and I'm going to see you in the next lesson where we're going to take a look at how to set up a new Qwik application using Qwik City.
By the way, if you want to watch this entire course now without YouTube adverts, you can do. It's all up on the Net Ninja website, netninja.dev. You can buy the course for two dollars to get instant access to all of it, or you can sign up to Net Ninja Pro and get instant access to all of my courses without adverts, as well as premium courses not found on YouTube, including my Udemy ones. That's nine dollars a month and you can get your first month half price when you use this promo code right here. So I'm going to leave this link down below in the video description for you to sign up. And I really hope you enjoyed this series and please do not forget to share, subscribe, and like the videos. That really helps a lot, and I'm going to see you in the very next lesson.
