Why is there a need for another framework? the current approach is not producing fast sites, and this problem will not disappear by waiting for a faster CPU.

Foreword

Qwik in Action

Introduction to the frontend development. Now, the responsibility of creating good or bad applications depends on you because the means available are all there.

Introduction

Overview of TypeScript. TypeScript introduced types into an untyped language like Javascript to ensure code consistency.

TypeScript

Overview of the frontend architectures. In this lesson you will understand the difference from Client Side Rendering and Multi Page Application.

Frontend architectures

Overview of the hydration. In this lesson you will understand the difference from Hydration and Island architecture/Partial Hydration.

Hydration

React Server Component. In this lesson you will understand the difference from Server Component and Client Component.

React Server Component

Qwik resumability will change the frontend ecosystem, In this lesson you will understand why is so great.

Resumability, the Qwik way

Wrap up of frontend architectures module.

Summary Chapter 2

In this lesson you will be able to understand more about performance and you will understand how improve your application with less JavaScript.

Qwik, the framework built on top of closure-extraction

Resumability is the core concept behind Qwik. In this lesson you will understand better the process.

Resumability

Code Extraction is a topic hard to master, you will understand how it works with different approaches.

Code Extraction

JSX syntax is the most famous one because of React, but what about the other frameworks, Vue, Angular?

Why Qwik use JSX syntax

Summary Chapter 3

Let's see together the fundamentals of Qwik. In this lesson you will compare Webpack and Vite.

Getting started with Qwik

The Qwik build process is so important because the resumability process requires correct and intelligent bundling.

Qwik compilation Process

Qwik CLI and amazing tool to have a great Developer Experience with Qwik.

Technical requirements to start a new Qwik application

Qwik Middleware an easy and clever way to expose your RESTful APIs or GraphQL APIs.

Middleware

Wrap up of Getting Started with Qwik module.

Summary Chapter 4

In this lesson you will learn the pillars of SEO. You will lean few new terms and metrics that can help you to measure your application.

In this lesson you will learn the some new things about SEO and crawler.

Sitemap and robots files

Partytown an amazing library to execute third scripts in the service worker.

Partytown

Core Web Vitals are so important for own application. You will learn in detail all the metrics.

Core Web Vitals

Core Web Vitals Labs Data vs Field Data. These two information are so different, let's figure out the peculiarity of those.

Labs data vs Field data

Summary Chapter 5

SEO and Core Web Vitals

There are many ways to deploy a Qwik application. You can have your own server and deploy your Qwik application easily with the Qwik CLI and integrations.

Deploy Qwik in production

Cloud solution are a good alternative for a low cost pipeline and host. Nowadays these kind of services are so smart and great, you should try them.

Cloud solutions

With different team and many developers, it's important to master branching strategies to avoid problems during your day by day.

Branching strategies

Progressive Web App approach can be an alternative to the stores. You can publish you application with a lot of benefit with PWA.

Progressive Web App

Wrap up of Deploy Qwik in Production module.

Summary Chapter 6

Style an application is so important let's see how engage your Stakeholders into this process.

Style and render data with Qwik

CSS is so huge, there are a lot of ways to style your application with Qwik, let's see them together.

CSS and Built-In Styling Methods

Tailwind is an amazing library, let's see together how master it. I will share you some tips and tricks to use Tailwind in a better way.

Tailwind CSS

In this lesson you will learn how manage data with Qwik. There are a lot of APIs to explore, let's jump into the code.

Managing data with Qwik

Summary Chapter 7

In this lesson you will learn how architect a modern frontend end application.

Creating an e-commerce with Qwik and Supabase

In this lesson you will learn the trade offs of technical decisions. I share with you some tips and tricks.

Technological spike

In this lesson you will explore Supabase. This is an amazing service to leverage your business.

Supabase for your backend

A custom authentication is too complex and risky to implement from scratch. Let's use the Supabase auth to optimize our goals.

Let's talk about the Authentication process

Summary Chapter 8

Supabase CLI an handy tool to improve consistency across environments.

Supabase CLI

Let's use the Supabase CLI to manage our database migrations and schemas.

Supabase db migrations

In this lesson you will create the e-commerce homepage with the Supabase client to read the data.

Show products on our homepage

Every e-commerce has a detail page, let's create our product detail page with Qwik.

Product Detail

Cache is really useful and in this lesson I will explain in the detail how it works. I will share my experience in this topic with some cool analogies.

Cache-control headers

Summary Chapter 9

Rendering products with Orama full text search

Let's improve out application with a useful "Add to favorites" feature.

Add a product to your favorites list

In this lesson you will learn how to use Stripe to manage your payments in a secure way.

Adding cart and checkout process with Stripe

Let's try the Supabase database function. This is an easy way to allows us to do several things and also add some logic to our procedure.

Page views tracking

A real-time database with Supabase is so simple to implement, let's build together a new functionality with this great feature.

Real-time database

Summary Chapter 10

Let's explore together the benefit of testing. In this lesson you will explore the various types of tests, Unit Test, E2E, Visual regression tests and more.

Overview of application testing

Let's discuss together how and when testing is valuable for our business. 3X Explore/Expand/Extract can help us is this reasoning.

How much testing is enough? When do I write tests?

In this lesson you will lean the Test driven development TDD flow. It's a really good practice to put in place.

Test-Driven Development (TDD)

In this lesson you will lean how test your components with Cypress.

Let's add some tests with Cypress

Do you need a Qwik component library? Qwik UI is the project for you because can give you a lot of Qwik accessible components out of the box.

Qwik UI

Summary Chapter 11

Adding tests to our Qwik application

Let's explore a bit of history of Qwik. A new framework with a great past.

Final thoughts

Qwik and React together, no problem, qwikify$ is the API to solve your problems.

qwikify$

Qwik and Astro together, no problem, @qwikdev/astro is the library to solve your problems.

Qwik inside Astro application

Qwik and micro-frontends together, no problem, out of the box Qwik can manage this scenario with no external dependencies.

Micro-frontends with Qwik

Summary chapter 12

Enter your name and email address below, then click the **"Send my free chapter"** button to get started

250+ page PDF

EPub

newline Access with Replits

All Code Samples

Discord Community Access

One-time price of $69

( the primaryDescriptionMarkdown is long - several lines, include images, as long as you want )

In this course we <headline of what we do>. <why this technology is good> but <here's how learning it is problem>. 

In <the length of these lessons> we cover <three salient points about what we cover. Your BEST points>. Its <however long it is> and comes with <these bonus features, and reasons to buy. code, etc.>

It's taught by <author name> who <credibility, reason you should listen to them>. <social proof, if you have it yet>

<then you can list other supporting stuff you want to add, anything you want here>

-------
Example:
-------

We created a free course to create your first GraphQL server (from scratch) using Node and TypeScript. TypeScript and GraphQL are a powerful combo, but there's a lot of confusing edges if you're getting it setup the first time.

In this course we cover the basics of getting TypeScript setup with Node, how GraphQL works, and how to set up a GraphQL server using Apollo server. It's two hours long, it comes with complete code examples, and we walk through the code step-by-step.

It's taught by my friend, Shopify-engineer Hassan Djirdeh and he's integrated what he's learned using GraphQL in production as an engineer at Shopify. We've already had over 1,300 students enroll and it's been getting great reviews so far.

// ... and so on

Harness Qwik Resumable Architecture for Lightning-Fast Startup Times

In this course we <headline of what we do>. <why this technology is good> but <here's how learning it is problem>. 

( the summary is short - one or two lines )

Complete Guide to Qwik

To Marzia, my wife, because she is an extraordinary and patient life partner.

The short answer is that the current approach to framework design is not producing fast sites, and this problem will not disappear by simply waiting for a faster CPU and network.

The core problem is that the industry has become very proficient at building complex applications to solve complex needs. The web applications of today are more capable than those of yesterday. Code bases are larger than ever. All of this is fantastic and a sign of the maturing industry.

However, tools (frameworks) still need to catch up with codebases. All frameworks need to know about the application before they can run. Frameworks need to know about component boundaries, state, and event listeners. However, how the frameworks obtain this information has a significant impact on how much code needs to be downloaded to the client on application startup.

Most frameworks use a technique called hydration. Hydration recovers all of the framework state (component boundaries, application state, event listeners) by re-executing all of the components on the page, starting with the root component and recursively visiting all components on the page. This is fine for small codebases, but as the applications become more complex, the amount of code needed to be executed by the browser on page startup becomes overwhelming, resulting in slow startup performance. This is the current O(n) approach to interactivity.

Qwik does not use hydration but instead employs resumability. Resumability takes advantage of the fact that the application has already been executed on the server as part of SSR/SSG, and the framework can serialize component boundaries, application state, and event listeners into the resulting HTML. On the client, the framework can deserialize the information instead of executing the code again. Resumability does not require running any code on application startup. This creates constant startup costs, regardless of the application complexity. This is the O(1) approach to interactivity.

The use of resumability opens up the possibility of lazy loading. Hydration requires eager execution of all components on the current page, which means that none of the components on the page can be lazy loaded. Only components not currently in the render tree can be lazy-loaded. Without hydration, loading all components on the page lazily is now possible. Now, the amount of code that the browser needs to execute is proportional to the interaction's complexity rather than the page's complexity.

But CPUs and networks are getting faster. Won't this problem go away?

In short, no. CPUs get faster in three ways:

The limit on clock speed has been reached, and it is about 3.5 GHz. Why? At 3.5GHz, light can travel about 8.5cm, which is less than one order of magnitude to the size of a silicon die. Getting close to the theoretical limit of what Physics will allow for a signal to travel from one end of the chip to the other explains the stagnation of clock speeds.

Modern CPUs try to parallelize many instructions concurrently. But more parallel designs are more complex. In addition, code is sequential, so parallelizing instructions is difficult and relies on speculative execution. So, it is unlikely that instruction parallelism can ever be more than a handful of instructions at a time.

Almost all growth in performance in recent years has been due to multiple CPU cores running applications in parallel. It is common for phones to have half a dozen cores. But there is a catch: JavaScript is single-threaded, which means it can only run on one core at a time. So, websites do not benefit from multiple CPU cores.

If sites require ever more JavaScript, then it is unlikely that growth in processing speed will be able to fix the startup performance problem. The solution to JavaScript bloat must come in the form of spreading the cost over time rather than requiring all of the JavaScript to run on startup, as is currently the case.

People have been trying to solve the hydration issue for a while, but none of the solutions have really caught on at scale because they all have trade-offs.

The real issue is that hydration-based frameworks were designed as client-side rendering (CSR) frameworks, with server pre-rendering as an afterthought. This design choice forces the framework to re-run the application code on hydration. The framework only knows how to CSR the application. The fact that the CSR can reuse the DOM elements is incidental and does not lower the JavaScript requirements.

Everyone stands on the shoulders of others. Qwik is not the first resumable framework, but it is the first open-source resumable framework. Google has Wiz that has been resumable for the past ten years; it runs Google Search, Photos, and many other properties. These apps are fast!

I really tried to integrate resumability into existing frameworks with a good Developer Experience (DX). I tried every rendering engine I could think of, but no luck; the assumptions that existing frameworks make and presumably requirements are not compatible. Through a process of elimination of existing solutions, a new solution was born.

Many frameworks have great DX. They also have escape hatches. These escape hatch APIs are used once the codebase becomes large to "optimize" the application for speed. Ways of pruning the render tree to minimize the blast radius of framework rendering. The implication is that there are two ways of writing components. The DX-friendly/simple way and the performant way. It was ensured that Qwik only had one way. There will not be optimization APIs to "memoize" things to limit the framework rendering; instead, in Qwik, everything is memoized all the time. That is not to say that a slow application can't be written in Qwik; developers are a creative bunch, but rather that the happy path in Qwik is the performant path. There is no alternative. This philosophy permeates through Qwik. Here are a few things that don't need to be done in Qwik:

In places where Qwik can't ensure the right solution, it provides guide rails:

There are a lot of frameworks to choose from! They differ on API. Do components need to be in a separate file? Are components markup with behavior or behavior with markup? But even though there are many choices for DX, it can be argued that if one zooms out, all of these frameworks work the same way. They are all CSR frameworks, with server rendering and hydration bolted on.

Qwik is very familiar with the DX and other popular frameworks. This is intentional to make developers feel at home. But don't be fooled by its familiarity. It works on fundamentally different principles. It is an SSR-first framework that focuses on startup performance by delivering nothing but HTML + CSS out of the box. This is in stark contrast to other approaches.

The hope is that Qwik will become successful, but no one can predict the future. However, it is certain that the next big framework will not rely on hydration.

I express my sincere gratitude to the Qwik community. Qwik is more than just an open-source project; it is a venture designed to be operated and owned collectively by the community. The Qwik community actively engages in supporting one another, responding to inquiries, prioritizing and resolving issues, crafting solutions, and determining the project's future trajectory. The existence and success of Qwik owe much to the dedicated involvement of the community.

---
title: Foreword
description: Why is there a need for another framework? the current approach is not producing fast sites, and this problem will not disappear by waiting for a faster CPU.
---

# Dedication

To Marzia, my wife, because she is an extraordinary and patient life partner.

Giorgio Boa

* * *

# Foreword by Miško Hevery

## Why another framework?

The short answer is that the current approach to framework design is not producing fast sites, and this problem will not disappear by simply waiting for a faster CPU and network.

## What is the core problem?

The core problem is that the industry has become very proficient at building complex applications to solve complex needs. The web applications of today are more capable than those of yesterday. Code bases are larger than ever. All of this is fantastic and a sign of the maturing industry.

However, tools (frameworks) still need to catch up with codebases. All frameworks need to know about the application before they can run. Frameworks need to know about component boundaries, state, and event listeners. However, how the frameworks obtain this information has a significant impact on how much code needs to be downloaded to the client on application startup.

Most frameworks use a technique called hydration. Hydration recovers all of the framework state (component boundaries, application state, event listeners) by re-executing all of the components on the page, starting with the root component and recursively visiting all components on the page. This is fine for small codebases, but as the applications become more complex, the amount of code needed to be executed by the browser on page startup becomes overwhelming, resulting in slow startup performance. This is the current O(n) approach to interactivity.

Qwik does not use hydration but instead employs resumability. Resumability takes advantage of the fact that the application has already been executed on the server as part of SSR/SSG, and the framework can serialize component boundaries, application state, and event listeners into the resulting HTML. On the client, the framework can deserialize the information instead of executing the code again. Resumability does not require running any code on application startup. This creates constant startup costs, regardless of the application complexity. This is the O(1) approach to interactivity.

The use of resumability opens up the possibility of lazy loading. Hydration requires eager execution of all components on the current page, which means that none of the components on the page can be lazy loaded. Only components not currently in the render tree can be lazy-loaded. Without hydration, loading all components on the page lazily is now possible. Now, the amount of code that the browser needs to execute is proportional to the interaction's complexity rather than the page's complexity.

## But CPUs and networks are getting faster. Won't this problem go away?

In short, no. CPUs get faster in three ways:

1.  By increasing the clock cycles
2.  By increasing the number of instructions per clock cycle.
3.  By adding more CPU cores and parallelizing the applications.

![CPU Clock Speed](https://d2uusema5elisf.cloudfront.net/courses/complete-guide-to-qwik/module_01/lesson_01.01/public/assets/cpu_speed.jpg)

Image from [Twitter](https://twitter.com/csgillespie/status/732532249325907968?lang=id)

The limit on clock speed has been reached, and it is about 3.5 GHz. Why? At 3.5GHz, light can travel about 8.5cm, which is less than one order of magnitude to the size of a silicon die. Getting close to the theoretical limit of what Physics will allow for a signal to travel from one end of the chip to the other explains the stagnation of clock speeds.

Modern CPUs try to parallelize many instructions concurrently. But more parallel designs are more complex. In addition, code is sequential, so parallelizing instructions is difficult and relies on speculative execution. So, it is unlikely that instruction parallelism can ever be more than a handful of instructions at a time.

Almost all growth in performance in recent years has been due to multiple CPU cores running applications in parallel. It is common for phones to have half a dozen cores. But there is a catch: JavaScript is single-threaded, which means it can only run on one core at a time. So, websites do not benefit from multiple CPU cores.

If sites require ever more JavaScript, then it is unlikely that growth in processing speed will be able to fix the startup performance problem. The solution to JavaScript bloat must come in the form of spreading the cost over time rather than requiring all of the JavaScript to run on startup, as is currently the case.

## Hydration alternatives

People have been trying to solve the hydration issue for a while, but none of the solutions have really caught on at scale because they all have trade-offs.

[Hydration sabotages the lazy loading.](https://www.builder.io/blog/hydration-sabotages-lazy-loading)

-   Islands - Extra work for the developer. Inter-island communication is a problem. Islands tend to grow over time.
-   Server Components - Server components can't have state and interactivity. If app requirements change over time, component boundaries may need to be refactored, which may not be trivial.
-   Progressive Hydration - Improves Time-To-Interactive (TTI) but does not improve the amount of code that needs to be executed.

The real issue is that hydration-based frameworks were designed as client-side rendering (CSR) frameworks, with server pre-rendering as an afterthought. This design choice forces the framework to re-run the application code on hydration. The framework only knows how to CSR the application. The fact that the CSR can reuse the DOM elements is incidental and does not lower the JavaScript requirements.

## Why another framework?

Everyone stands on the shoulders of others. Qwik is not the first resumable framework, but it is the first open-source resumable framework. Google has Wiz that has been resumable for the past ten years; it runs Google Search, Photos, and many other properties. These apps are fast!

I really tried to integrate resumability into existing frameworks with a good Developer Experience (DX). I tried every rendering engine I could think of, but no luck; the assumptions that existing frameworks make and presumably requirements are not compatible. Through a process of elimination of existing solutions, a new solution was born.

## Easy is the same as performant

Many frameworks have great DX. They also have escape hatches. These escape hatch APIs are used once the codebase becomes large to "optimize" the application for speed. Ways of pruning the render tree to minimize the blast radius of framework rendering. The implication is that there are two ways of writing components. The DX-friendly/simple way and the performant way. It was ensured that Qwik only had one way. There will not be optimization APIs to "memoize" things to limit the framework rendering; instead, in Qwik, everything is memoized all the time. That is not to say that a slow application can't be written in Qwik; developers are a creative bunch, but rather that the happy path in Qwik is the performant path. There is no alternative. This philosophy permeates through Qwik. Here are a few things that don't need to be done in Qwik:

-   Memoize state (all state is always memoized)
-   Lazy-load components (all code is automatically broken down into functions and available for lazy loading)
-   Prefetch code (Qwik service worker automatically prefetches code)
-   Bundle optimization (Qwik-insights uses AI to optimize bundling, minimize waterfalls, and determine the order of prefetch.)

In places where Qwik can't ensure the right solution, it provides guide rails:

-   Notify early of images that are missing size and cause CLS.
-   Suggest image optimization by auto-fixing the code.
-   Highlights which areas of the UI experience layout-shift

## Not just another framework

There are a lot of frameworks to choose from! They differ on API. Do components need to be in a separate file? Are components markup with behavior or behavior with markup? But even though there are many choices for DX, it can be argued that if one zooms out, all of these frameworks work the same way. They are all CSR frameworks, with server rendering and hydration bolted on.

Qwik is very familiar with the DX and other popular frameworks. This is intentional to make developers feel at home. But don't be fooled by its familiarity. It works on fundamentally different principles. It is an SSR-first framework that focuses on startup performance by delivering nothing but HTML + CSS out of the box. This is in stark contrast to other approaches.

The hope is that Qwik will become successful, but no one can predict the future. However, it is certain that the next big framework will not rely on hydration.

## Qwik loves the community

I express my sincere gratitude to the Qwik community. Qwik is more than just an open-source project; it is a venture designed to be operated and owned collectively by the community. The Qwik community actively engages in supporting one another, responding to inquiries, prioritizing and resolving issues, crafting solutions, and determining the project's future trajectory. The existence and success of Qwik owe much to the dedicated involvement of the community.

Miško Hevery
