Building WebApps That Light Up the Internet with QwikCity

Rate this content
Bookmark
Github

Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.


QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.


Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.

This workshop has been presented at JSNation 2023, check out the latest edition of this JavaScript Conference.

FAQ

Builder.io is a headless visual CMS that allows users to design websites using a drag-and-drop editor. It enables marketing teams to make changes to the website without needing to constantly involve the engineering department. The CMS runs on your infrastructure, allowing you to register your own components.

Misko Hevery is the CTO of Builder.io. He has also worked on projects like Angular JS, Karma, and now focuses on a project called Quick.

Quick is a project developed by Misko Hevery and the team at Builder.io. It aims to improve website performance by reducing the amount of JavaScript that needs to be executed, thereby enhancing user experience and Core Web Vitals scores.

Party Town is a project for running third-party code like Google Analytics inside web workers. Mitoses allows you to create design systems and components that can be translated into all major frameworks, such as React, Angular, and Quick web components.

Existing websites often suffer from poor performance due to the heavy use of JavaScript. Quick aims to solve this problem by designing a framework that only loads JavaScript as needed, rather than overwhelming the browser with all the code at once. This improves website performance and user experience.

Core Web Vitals are metrics created by Google to measure the performance of websites. These metrics are used to encourage the creation of faster and more interactive websites by providing a PageSpeed score and Lighthouse score.

Quick improves website performance by breaking up the application into smaller pieces and only loading the necessary JavaScript as needed. This reduces the amount of JavaScript that needs to be executed, making the website faster and more responsive.

In Quick, JavaScript only loads when it is required. For example, if you have a counter component, the JavaScript for the counter will only load when the user interacts with it, rather than loading all the JavaScript upfront.

Quick has a variety of integrations, including deployment platforms like Cloudflare, Netlify, and Vercel, as well as tools like Cypress for testing, Storybook, Prisma for database ORM, Tailwind, and more. It also supports running React components within Quick.

Route loaders in Quick allow you to fetch data on both the server and client sides, providing a unified mental model for data fetching. Actions, on the other hand, enable you to perform server-side operations like authentication and updating databases, even allowing forms to work without JavaScript.

Miško Hevery
Miško Hevery
170 min
12 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Quick is a framework that focuses on performance optimization and reducing JavaScript overload in websites. It allows for lazy loading of components and efficient downloading and execution of code. Quick integrates with various tools and platforms, including Auth.js, Superbase, and headless CMS. It provides features like client-side navigation, route loaders, and the ability to fetch and update data. Quick's rendering paradigm makes every application instantly interactive, and React-Quickify allows for the use of existing React components in Quick applications.

1. Introduction to Quick and Performance Optimization

Short description:

Hello, my name is Misko and I'm the CTO of builder.io. I work on projects like Angular JS, Karma, and Quick. Builder.io is a headless visual CMS that allows for a drag and drop editor. We focus on open source projects like Party Town and Mitoses. The world needs a new framework because existing websites have poor performance due to the amount of JavaScript. We need a framework that doesn't overwhelm the browser with JavaScript. Service site rendering and reasonability are two approaches to improve performance by reducing duplicate information and downloading less JavaScript.

Hello, how's it going? Hi, my name is Misko. I'm the CTO of builder.io and I work on other projects, Angular JS and Karma and now I work on a project called Quick.

And so, before I tell you about Quick, just a little quick overview. So builder.io is a headless visual CMS. Basically what we allow you to do is to have a drag and drop editor for your application so that your marketing people can design the website without constantly bugging the engineering department about all the changes they have to do. And the cool thing about it is that it's running on your infrastructure rather than being hosted somewhere else. Because it's running on your infrastructure you can register your own components. Anyways, here is kind of their open source theme. So builder is about 50 people. Actually, we're probably pushing 55 at this point. And we love open source. And so we have a couple of projects besides Quick which is Party Town and Mitoses. Party Town is for running your third-party code like Google Analytics inside of web workers. And Mitoses allows you to make design systems, existing components that your company needs. And then it translates them into all major frameworks for you so you can have a native version of React, a native version of Angular components, and Quick web components, React Salt, whichever one you can imagine. So this is our team working at it. Adam Bradley used to work at Ionic. And Manuel also worked in Ionic and created Gin. And we have some Jabber who also worked at Mitoses. So that's kind of the open source we focus on.

And so the question then becomes, why does the world need a new framework? And the answer for that is, well, because if you look at the existing websites, the performance of these websites is not that great. So Google has spent a lot of time making sure that kind of trying to encourage the world to create faster websites. The way they do this is they create something called Core Web Vitals and a Lighthouse score, a PageSpeed score, and they're trying to basically show you how performant your website is. Core Web Vitals is actually instrumenting in Chrome. So it's a real world user experience. And it basically shows how interactive, you know, how well the user experience is. And as you can see, most websites don't have a very good Core Web Vitals numbers. And even the companies that try really, really hard, like Amazon, you know, they get much, much better, but they don't have the best numbers. And so the question is, like, why is this? You know, why are we having so much trouble? And the thing I'm gonna try to convince you is that it really comes down to the amount of JavaScript. And so the more JavaScript you have on your website, the slower the website becomes. And that's kind of obvious. You know, it's not really that difficult to imagine why that would be the case. And so the thing we're trying to figure out is how do you build, I mean, you need JavaScript, right? Because JavaScript is the thing that makes the webpages interactive. And so if you don't have JavaScript, your pages are not interactive. So the question becomes, like, how do you, oops, how do you design websites so that you can use JavaScript to build them, but at the same time don't overwhelm the end user with all of the code. Rather don't overwhelm the browser. And so this graph really shows that, like, over the years, we just keep shipping more and more JavaScript because we expect more out of our websites today than we had ten years ago. We expect a lot more interactivity, a lot better user experience. And all of that requires JavaScript, right? I'm here saying that we need less, but not in the form of like, you know, write less JavaScript and go back ten years. That's unrealistic. Instead I'm saying, hey, let's keep writing JavaScript, but like, how about we design a framework so they don't overwhelm the browser with all this JavaScript? So instead of dumping all the JavaScript all at once on the user, you know, could we have framework where the JavaScript kind of shows up on an as needed basis rather than overwhelming the whole system all at once? Okay. And so this is another chart. And it basically shows the same information. So it shows that on the left-hand side, you can see the scores and on the right-hand side, you can see the amount of JavaScript that is being shipped. And what you can see is that there is an inverse relationship, right? The more JavaScript we ship, the worse the performance is. And the less JavaScript we ship, the better the performance is. And so it all comes down to shipping less JavaScript. And if you look at the Core Web Vitals that the Google page speed gives you, it's the same kind of a story in the sense that the Google will oftentimes recommend that, hey, you know, can you ship less JavaScript. The hard part is how exactly do you do that? And so the thing I'm trying to convince you or rather kind of share with you is that if look at history of how we got here, you're going to realize that hydration is a bit of a workout. Here's what I mean by that. So first we sent HTML and then we originally had blank page. And the blank page had a script inside of it that downloaded JavaScript which then executed the application, which then rendered the application and this is where you had your app shown and you can interact with it. And so the problem is there's this white blank page. And people said, you know what, we really like the fact that it's super interactive, but this white page over here is problematic. So can we do something about it? And so what they created is a service app. So in the service app rendering, the HTML is much bigger, but as a result, instead of having a blank page, you actually have the page that you see. And so the site appears faster, but this site is not interactive. You can't click on it. So you still have to download the JavaScript. You still have to execute the application and you still have to render it, except this time we're going to call it reconciliation because we're trying to reuse the DOM elements. And then so at this point, you actually have a site that you can click on. And so service site rendering has this interesting contradiction where the site appears faster, but it actually is slower to get it to interact with. And so this is kind of the situation we have. And so instead oh, yeah, I want to point out that there's a lot of duplicated information. If you look at this visually built on your text stack, this string is found both inside of the HTML and inside of JavaScript. There's duplication going on. And so we'd like to have something some other way of doing it. And so I'm going to skip a couple of slides and I'm going to show you what reasonability is. So reasonability, basically, does something differently. So you start with the HTML. The HTML is big. And as a result, you have the page here. But the unique thing about reasonability is that there is a listener that knows how to interact with the page. So already you can interact with the page at this moment. Now you still need JavaScript. So the application appears faster. And so you eagerly start to download the JavaScript immediately as you show up. But here's the thing. Notice all this missing JavaScript. So the amount of JavaScript you download is a lot less. And that's because reasonability can actually remove duplicate information. Right here you have JavaScript for interactivity. But all of this was basically the static information that's already found in the HTML. And so this removing of duplication means that you don't have to re-execute the application. You don't have to re-render the application. And so you can just interact it way, way faster. Okay, I think this is kind of a good introduction. So I'm going to pause here. And then we're going to use this to build some application. But first, I want to see if people have questions.

2. Introduction and Workshop Setup

Short description:

We have a person from Slovakia. Any questions or should we jump in and try to build something with Quick and see how different? Here is the URL for the workshop. You can follow along and ask me questions. The link is also available in the chat room and the discord channel.

Oh, there's somebody in the chat. There we go. Is the darkness. OK, so we have a person from Slovakia. Awesome. Any questions or should we jump in and try to build something with Quick and see how different? All right. I'm going to take the silence. It has no questions. So here is the URL. the URL inside of the the I can paste it here instead of the chat window. But I also pasted it inside of the good nation. Discord channel so you can follow along. OK, so all of the steps for this workshop you can find this URL and we're going to go over it together. You're welcome to follow along and ask me questions, etc. Somebody says again, I'm not sure I understand. Which mean by again? Oh, the link again. Oh, I see. Oh, because I only sent it to a specific person. Oops, sorry. So here's the link in the chat room. And the link is also available if you go to the discord right here.