Skip to content

This Dot Blog

This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.

Newest First
Tags:Qwik
Announcing Qwik for starter.dev cover image

Announcing Qwik for starter.dev

Hello there! Today, I'm so excited to introduce our new Qwik starter kit, which comes with 4 different technologies configured, and is ready for use. These technologies are: Qwik City, Storybook, Tailwind CSS, and GraphQL. In this short article, we will talk about the core framework, the routing, example apps to get you started, the tools and technologies used in this kit, and how it is a great out-of-the-box starter for your next Qwik project. Qwik Qwik is a new JavaScript framework by Misko Hevery, creator of Angular, for building frontend browser applications. The major benefit of Qwik is its performance optimization, which features resumability and lazy loading. Today we will be focusing on the Qwik framework starter kit. Technologies Used in the Starter Kit - Qwik City The kit is configured to make use of Qwik City, which offers directory-based routing (you don’t have to worry about colocation) and much more. Qwik City is a meta-framework of Qwik. It brings an opinionated and performant way to build sites at scale. - Storybook Storybook is a frontend workshop for building UI components and pages in isolation, testing, and documentation. It is open source and free. It is a great tool for testing and visualizing your components in different states. Qwik currently doesn’t have out-of-the-box support for Storybook, but we have figured out a way to configure it for Qwik. For more information on how we set up Storybook in Qwik, visit here. - Tailwind CSS Because Tailwind CSS is one of the most loved CSS libraries, we also included in this kit. Tailwind CSS is an open-source CSS framework. There is no special configuration to use Tailwind CSS in your Qwik app. You can use module CSS, or follow along with the kit (i.e we export the CSS classes as a variable). We will still achieve the same result, and make our code a bit cleaner, unlike when we write the CSS classes in the JSX directly. - GraphQL GraphQL is another great tool that was added to the kit. This gives you an out-of-the-box configuration to start making API calls to your GraphQL backend. GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. How to Get Started To get started, visit the Qwik starter.dev page for all the steps needed to create a new application with our starter.dev CLI, and run the application on your local system. Example Apps in the Starter Kit In this starter kit, we have two main components; - Counter - Greeting In the Counter component, we see how we can utilize the useStore hook provided by Qwik to store our counter state. In the Greeting component, we made use of the GraphQL config in the starter kit. The app sends a query request with the value entered in the input field, which is then returned back as a response from the API. With all of these configurations and code samples, we believe that with this Qwik starter kit, you can start building your production-scale application. Conclusion Qwik is still in its early days, and we will continue to update as we learn more. We welcome everyone to take a look, and if you have any questions or run into any trouble feel free to join the discussions going on at starter.dev or on our Discord....

Unit Testing Qwik Components cover image

Unit Testing Qwik Components

Qwik offers a unique approach to building fast, efficient web applications. However, we shouldn't forget about the quality of our code. In this blog post, we provide a comprehensive guide on how to set up and write tests for your Qwik components....

Utilizing Browser Storage to Enhance User Experience in a Qwik Application cover image

Utilizing Browser Storage to Enhance User Experience in a Qwik Application

Introduction As front-end developers, we are always looking for ways to enhance the user experience of our applications. One of the ways we can achieve this is by utilizing the browser storage to store data, and implement some form of caching. Our web browser has provided us with different storage options to store data such as cookies, localStorage, and indexDB. In this article, we will be looking at how we can use storage to enhance a Qwik application. We are going to also explore hook technology in implementing this. Hooks 🪝 We will be extracting our storage function into a hook function that we can use in any part of our application. What are Hooks? Hooks are JavaScript functions that manage a component’s state and side effects by isolating them. That means we can isolate all the stateful logic into a hook and use it in any component. And just like in ReactJS, Qwik also allows us to create our own custom hooks. Project Set Up To get started, we need to create a new Qwik app. We can do this by running the following command in our terminal: ` You can also get additional tools and configurations using our starter.dev kit by running the command in your terminal: ` After the project is created, we can run the following command to start the development server: ` Now we can open our browser and navigate to http://localhost:5143 to see our app running. The demo app we will be building is a simple form with an input field and a button. The input field will be used to enter a value, and the button will be used to reset the form and the storage state. We will also see how we apply this functionality in our Qwik GitHub showcase app to persist/catch data we fetch from the GitHub API. Storage Hook After the project is created, we can create a new folder in the src folder and name it “hooks”. In the hooks folder, we will create a new file and name it useLocalStorage.ts. In this file, we will create our useLocalStorage hook. ` Let me explain what is happening here: - The useStore hook is used to store the value. We initially set this value to the initial state value passed to our custom hook. - In the useClientEffect$ hook, which runs on the client, we try to update our store value with the value from the localStorage based on the key passed to the hook. If the value is found, we set its parsed value to the store value. If not, we set the store value to the initial state passed to the hook. We also catch any error that might occur, and set the store value to the initial state. - We also have a setValue$ function that is used to set the value of the store and also save it to the localStorage. The setValue$ function is wrapped in a $ function, which is used to create a QRL function- a Qwik optimizer marker function. For more information on QRL, visit the docs. - We also return store and the setValue$ function. This exposes them to be consumed in our components. We don't want to return the value of the store or else it will lose its reactivity. Form Component In the components folder, we will create a new folder called form, which will contain an index file that will export our Form component. The form will be expecting two props; value and setValue, which are from the useLocalStorage hook. ` In our index file, we will import the useLocalStorage hook and the Form component, and our updated index file will look like this: ` We can now see what our simple app looks like in the browser, and we can interact with it. By entering a value in the input field and reloading the page, we can see that the value persists. Next, we want to implement this hook in our Qwik GitHub showcase app to persist the gists data we fetch from the GitHub API and persisting it in the localStorage. We transform our fetch gists logic from this: ` to this; ` So we check if we have cached gists in the Storage. If we do, we set the store data to the cached gists. If not, we fetch the gists from the GitHub API and update the store data with the response. We also pass the setGists function to the updateGists function, which is the setValue$ function from the useLocalStorage hook. This function is used to set the value of the store, and also save it to the localStorage. Conclusion In this article, we were able to understand why we need to improve user experience with a focus on persisting data. We also saw how to create a hook in a Qwik framework, and use our hook to persist data in the localStorage. A link to the project repo can be found here and for our Qwik starter.dev showcase app, here. If you have any questions or run into any trouble, feel free to reach out on Twitter or on our Discord....

How to Setup Storybook in a Qwik Project cover image

How to Setup Storybook in a Qwik Project

Introduction Storybook is a great tool for testing and visualizing your components in different states. In this article, we will see how to setup Storybook in a Qwik project. Qwik Qwik is a new JavaScript framework by Misko Hevery, creator of Angular, for building frontend browser applications. The major benefit of Qwik is its performance optimization, and this is achieved through zero loading, resumability, lazy loading, reduced rendering, scalability, and code once. For more information on Qwik, you can check out the docs, github repo, and discord. Project Set Up To get started, we need to create a new Qwik app. We can do this by running the following command in our terminal: ` Initialize Storybook Storybook, unfortunately, doesn’t have a Qwik template yet because it is a new Framework. So the work around is to use the html template . Using the command below, we can initialize Storybook: ` During the initialization, Storybook would ask to automatically install some optional dependencies such as; EslintPlugin and npm7, you can accept or reject it. To accept, type y and hit Enter to progress. Storybook would try to setup a default stories folder, which is based on the ` template we choose, which is `. It is not compatible with the Qwik compiler and will result in compilation errors, so we will have to delete it to avoid running into such errors. Project Structure Our project structure is already setup by Qwik, and Storybook initialization has created a .storybook folder. But we need to make some changes to the Storybook file extension since our project is in TypeScript. This is a snippet of the folders in our project: ` Configuring Storybook Since Qwik runs on Vite, we need to set up the viteFinal function in our main.ts file, which will give us the config that we will use to register our Qwik Vite plugin. Add this line of code in the configuration object: ` In the preview.ts file, this is where we configure how Storybook renders our stories. We need to execute Qwikloader. This will help in registering global browser events, and much more Qwik related benefits. We will replace the content in the file with the code below: ` This solution was found in this discussion: How to do component testing with Qwik?. I believe when the Qwik Storybook type template becomes available these configurations will be there by default. Now we are done with the configuration, let's run storybook and see what we have: ` Creating Stories We can create our first story, we will create a story for our Qwik app component. We will create this story for our default Qwik Header component. I modified the Header component to accept a menus props: ` Conclusion In this article, we saw how to setup Storybook in a Qwik project. We also saw how to create our first story. I hope you enjoyed this article. Thanks for reading. If you don't want to do these steps yourself, check out our starter.dev Qwik kit that already has Storybook enabled for your use here. A link to the project repo can be found here. If you have any questions or run into any trouble, feel free to reach out on Twitter....

How to Build Apps with Great Startup Performance Using Qwik cover image

How to Build Apps with Great Startup Performance Using Qwik

In this article, we will recap the JS Drops Qwik workshop with Misko Hevery. This workshop provided an overview on Qwik, its unique features and a look at some example components. We will also address some of the questions raised at the end of the workshop. If you want to learn more about Qwik with Misko Hevery, then please check out this presentation on This Dot Media’s YouTube Channel. Also don’t forget to subscribe to get the latest on all things web development. Table of Contents - What is Qwik? - How to create a Counter Component in Qwik - Unique features of Qwik - Directory Based Routing - Slots in Qwik - Very little JavaScript in production - Resumability with Qwik - Lazy load components by default - Questions asked during the workshop - Are all these functions generated at build time or are they generated at runtime? What's the server consideration here (if any) or are we able to put everything behind a CDN? - How do you access elements in Qwik? - Can you force a download of something out of view? - What is the choice to use $ on Qwik declarations? - Can you explain the interop story with web components and Qwik? Any parts of the Qwik magic that aren’t available to us if, say, our web components are too complex? - Is there an ideal use case for Qwik? - When to use useWatch$ instead of useClientEffect$? - Conclusion What is Qwik? Qwik is a web framework that builds fast web applications with consistent performance at scale regardless of size or complexity. To get started with Qwik, run the following command: ` The Qwik CLI will prompt options to scaffold a starter project on your local machine. To start the demo application, run npm start and navigate to http://127.0.0.1:5173/ in the browser. How to create a Counter Component in Qwik Create a sub-directory in the routes directory named counter and add an index.tsx file with the component definition below. ` Now navigate to http://127.0.0.1:5173/counter and you should see the counter component rendered on the page. Unique features of Qwik Directory Based Routing Qwik is a directory-based routing framework. When we initiated Qwik, it created a routes sub-directory in the src directory and added index and layout files for route matching. The index.tsx is the base route component and the layout.tsx is the component for handling the base page layout. The sub-directories in the route directory serve as the application’s structure for route matching with its index.tsx files as the route components. Every index.tsx file does a look up for the layout component. If it doesn’t exist in the same directory, then it moves up to the parent directory. ` Slots in Qwik Qwik uses slots as a way of connecting content from the parent component to the child projection. The parent component uses the q:slot attribute to identify the source of the projection and the element to identify the destination of the projection. To learn more about slots, please check out the Qwik documentation. Very little JavaScript in production In production, Qwik starts the application with no JavaScript at startup, which makes the startup performance really fast. To see this in action, open the browser’s dev tools, click on the Network tab, and on the Filter tab select JS. You will notice the Vite files for hot module reloading are currently the only JavaScript files served which will not be shipped to production. Go to the filter tab and check the invert checkbox then in the filter input type select Vite. Resumability with Qwik Qwik applications do not require hydration to resume an application on the client. To see this in action, click on the increment button and observe the browser’s dev tools network tab. You will notice Qwik is downloading only the required amount of JavaScript needed. The way Qwik attaches the event to the DOM and handles the state of components is that it serializes the attribute, which tells the browser where to download the event handler and its state. To learn more about serialization with Qwik, read through the Qwik documentation. By default, the code associated with the click event will not download until the user triggers that event. On this interaction, Qwik will only download the minimum code for the event handler to work. To learn more about Qwik events, please read through the [documentation] (https://qwik.builder.io/docs/components/events/#events)....

Using React In Your Qwik Application cover image

Using React In Your Qwik Application

Introduction React, developed by Meta, is a JavaScript library for building user interfaces, and it is one of the most used UI JavaScript libraries in the world. React will be turning a decade old by May 2023. It has gained a lot of popularity over the years, and its latest version, React 18, was released in March 2022. Qwik is a new JavaScript framework by Misko Hevery, creator of Angular, for building frontend browser applications. The major benefit of Qwik is its performance optimization, which features resumability and lazy loading. As it stands now, there are virtually no Qwik third-party packages or libraries that currently exist, but luckily the Qwik team factored this in, making it easy for developers to easily integrate React libraries or your old React components into your Qwik project without too much difficulty. In this article, I will show you how to easily integrate React libraries or components into your Qwik project. Project Set Up To get started, we need to create a new Qwik app. We can do this by running the following command in our terminal: ` You can also get additional tools and configurations using our starter.dev kit by running the command in your terminal: ` You will be prompted to enter the name of your project (let’s call it qwik-react), choose the default option when asked to select a starter, and then install npm dependencies. Now we have our Qwik application ready to go. Let’s start the development server and see what it looks like; ` Now that our app is up and running we will see how we can integrate a React package and component into our Qwik project. Integrating React in Qwik Like most JavaScript frontend libraries or frameworks, React makes use of hydration, which has its drawbacks and might be more expensive than you think. Qwik needs no hydration on load. It’s just pure HTML. This makes Qwik qwiker to load UIs, with which users can start interacting. You should keep this in mind when considering to include React components in your Qwik applications. QwikReact is a tool that allows you to use React components in Qwik, including the whole ecosystem of component libraries such as Material UI, Threejs and React Spring. To get started, we need to run this command inside our Qwik app: ` This will install needed dependencies such as qwik-react, react, and react-dom. It will also add emotion and mui, which you can uninstall if you don’t intend to use them. If we check our project, we should now have some new folders generated. The most important is the src/integrations/react. This is where all our React components will be implemented or React packages will be used. Qwikify$ The qwikify$ function is exported from @builder.io/qwik-react, which converts React components into Qwik components that you can use across your application, and allows Qwik to implement partial hydration of React components. You cannot use React components in Qwik without converting them first to remove React’s hydration pattern, which is not supported in Qwik, using qwikify$(). Another important thing to remember is to make sure the file containing your React component has this; ` This needs to be imported at the top of the file as this serves as instructions to the compiler to use React as the JSX factory. This means you cannot mix your React components with a Qwik component. The code above is from the Qwik demo. You can see how the React components are wrapped with the qwikify$() function. If your React package requires some configuration, don’t try to pass it as a props. Instead, do every configuration right inside the file, ensuring only the dynamic data is passed through. The code above is from our Qwik GitHub showcase. Check out the full source code here. So once you are done with Qwikifying your React component, you can now import and use it just as you would normally do a Qwik component. Let’s run our application, and navigate to the React page at ` to view the default Qwik demo; ` Interactivity Qwik tries to reduce or completely remove hydrations, but React heavily depends on it. This means we have to find a way to hydrate our React Component without affecting the concept of Qwik. Qwik allows you to decide when to hydrate your components by using the client: JSX properties. This technique is commonly referred to as “partial hydration”. For more information on this checkout Adding Interactivity on Qwik Docs. Conclusion In this article, we saw how to convert React to a Qwik component. We also learned about the dos and don’ts of using React in Qwik, as well as how to handle hydration. I hope you enjoyed this article. Thank you for reading! If you have any questions or run into any trouble, feel free to join the discussions going on at starter.dev or on our Discord....

Starter.dev: Bootstrap your project with zero configuration! cover image

Starter.dev: Bootstrap your project with zero configuration!

Starter.dev: Bootstrap your project with zero configuration! Table of contents - Why Starter Kits? - Why Showcases? - Getting Started - What Kits Exist Today? - Collaborate with Us - What’s Next? We’re excited to present you with starter.dev, a set of zero-configuration project kits built with your favorite tools. Each kit is configured with the following so you can focus on building features instead of spending time on configuration: - State Management - Data Fetching - Testing - Storybook - Community standardized ESLint and Prettier We’re also launching starter.dev showcases which utilizes the kits and demonstrates how to build at-scale applications and go beyond the basic TodoMVC app, though we love a good TodoMVC! Why Starter Kits? This Dot Labs engages with its clients to build modern applications, and many of them are requesting greenfield projects using the latest and greatest technologies. While starting these projects, our architects found that they were repeating a bunch of the same steps each time they needed to start a new one. Most meta frameworks ship with the bare minimum, and don’t include features like testing or Storybook out of the box, and configuring these technologies can be time consuming. With this challenge in mind, we sought to create zero-config _starter_ templates to help kick _start_ projects. And thus, starter.dev was born! Why Showcases? During starter.dev’s development, Minko Gechev from the Angular team approached us about a project to help enhance Angular education tooling. You can learn more about this specific effort in the blog post announcing the GitHub Clone Showcases. Minko’s idea was to demonstrate building applications that utilize these key features of the Angular framework: Routing Forms State Management API interactions - REST or GraphQL Authentication This idea laid the groundwork for many of the starter kits we created. We’ve developed several GitHub Clone showcase to help developers understand how to best utilize the kits, and build at-scale applications that accompany our kits. Getting Started Getting started with starter.dev (pun intended) is as simple as running a scaffolding script: - Run npx @this-dot/create-starter to run the scaffolding tool - Select one of the kits from our library from the CLI - Name your project - cd into your project directory, install dependencies using the tool of your choice. After completing these steps, you can start building features in your new project immediately. What Kits Exist Today? This Dot is happy to ship starter.dev with the following kits: - Angular + Apollo Client + Tailwind CSS - Angular + NgRx + SCSS - Create React App + RxJS + Styled Components - Next.js + TanStack Query (formerly React Query) + Tailwind CSS - Remix + GraphQL + Tailwind CSS - Vue 3 + Apollo Client + Quasar - Qwik + GraphQL + Tailwind CSS - SvelteKit + SASS Each kit ships with the following out-of-the-box: - Testing via jest or vitest - Storybook - ESLint and Prettier Configuration - State Management - Data Fetching for either REST or GraphQL - Some starter components to demonstrate global state management and data fetching These starter kits don’t ship with E2E testing libraries, such as Cypress or Playwright, for now, because these tools come with amazing out-of-the-box configurations and do not require additional setups. However, the showcases use Cypress tests consistency which you can check out in the showcases repo. Collaborate with us Starter.dev began as an internal need, but anyone can benefit from the existence of these kits. While there is a set structure for building out new kits, This Dot welcomes requests for new kits. We’ll work with you to determine what the structure of your kit should be and then scaffold out all of the issues needed to complete the work. Our team will help build out new issues, but we encourage the community to jump in and help build as well. This is a great opportunity to collaborate with the community as both a learner and a teacher. At This Dot, two of our guiding principles are: Getting Better Together and Giving Back to the Community. We believe that starter.dev is a perfect opportunity for us to get better through collaborative efforts with community members, and helping the community through what we hope is a great open source resource. What’s Next? We want to get this tool into your hands, and improve what exists. Tell us what is working for you and not, and we’ll do our best to address those issues. Next, we want to expand our library of kits. Tell us what are some kits you would like to see. We’re looking into building out kits for SolidJS and Node backend technologies as part of our next iterations, but we’re sure there other tools people would like to see. Finally, we’ll be publishing some additional educational materials around some of the decisions and design patterns we’ve chosen for each kit and showcase. We’re excited to share our process with you....

Qwik: A no-hydration instant-on personalized web application cover image

Qwik: A no-hydration instant-on personalized web application

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 There was a framework called Astro that decided to try something different. It wanted to take the application, break it out into smaller chunks, and then delay the hydration until the event happens. 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?...