Qwik - HiRez Tutorial notes

The SPA process

1. Build (optimizing)

   1. Dead code elimination (static tree-shaking) making a smaller bundle size of only the code that is needed, and this phase also generates an empty index.html file. JavaScript and empty index.html file is the result of build phase.

2. Server (serving)

   1. Browser issues request for a route (virtual route usually) and server returns the empty index.html and the user sees nothing because we still do not have any JS code but there is a script tag that then loads up the JavaScript code.

3. Client (rendering)

   1. JavaScript builds up the entire page and renders all the templates into html and then we see the application rendered. (We render interactive and non-interactive elements (we shouldn’t need to render the non-interactive elements because they do not require JS) Eagerly JS Loading & Execution

The Hybrid process

1. Build (optimizing)

   1. Tree Shaking

2. Server (rendering)

   1. Rendering the HTML (user asks for virtual route) virtually routed on the server and files are being rendered on request and the framework takes the templates and renders them into HTML. The server then sends the HTML to the client and the page shows up but you cannot interact with anything.

3. Client (hydration) - Hydration is a way of taking a static piece of html and turning it into an interactive application

   1. Eager loading happens where the server serves and downloads the JS file.

   2. Eager execution framework renders the JavaScript and creates all the info the framework needs in order to figure out what to do. This is what gives us a fully interactive application.

Issues with Hydration

The client does a replay (the server does all this work to figure out what the page is and now the client needs to replay or redo everything the server has just done in order to get itself in the same state the server was when the server took a snapshot of the HTML. This does not always happen perfectly sometime there is a “Cumulative Layout Shift” (CLS) where pixels can be off and you go to click something after it has become interactive and the element shifts. The main problem with hydration is it can be slower. Any time between the html showing up and the interactivity that is the hydration taking time.

Lazy loading helps by loading chunks of JS based on routes (server serves only required chunks of JS), but this has to be setup manually and is often lost when a team is working on something, and developers forget or do not know how to do this properly.

Resumability

Server loads html and writes everything down and sends to client and framework just picks up where it left off. Qwik is like video streaming vs a normal application which is video downloading.

1. Build (optimizing)

   1. Static tree shaking.

   2. Code splitting by closures by routes (“closure chunking”). Takes JS bundles and extracts it into tiny JS chunks. This is done by Qwik optimizer which is a build time tool which knows how to extract all the component functions and event handlers into their own JavaScript file.

      1. Classic frameworks know how to lazy load on route change Qwik knows how to lazy load on every single little click, mouse move etc.

2. Server (rendering)

   1. Server renders the page (TSX files) using Qwik renderer then pauses and takes a snapshot of all the information that the framework created on the server.

      1. Snapshot takes component boundaries, event listeners, page’s app state and writes all this into the HTML it sends to the client and the framework there does not have to rebuild it all. (Smart HTML). Has Qwik loader. In the html it uses pointers (URLs) to where to get the code from for interactivity. This means there is much less JS being sent to the client.

   2. Code sent to client only has JS for the interactive bits and does not need to bring down the code for non interactive bits because it has already been done on the server and the none interactive bits are just pure HTML. The goal is that “you should only download the code that you plan on executing now.”

      1. As soon as the browser renders the HTML Qwik gives the browser a list of URLs to start prefetching so by the time you click on a button the code needed to execute the function/interactivity is already there.

3. Client (streaming)

   1. Prefetching (buffering) - service worker and browser cache - service worker starts to prefetch all the possible interactions points that a user might execute and puts it in the cache so they are ready to go.

   2. Lazy execution - for example if a user clicks a button the Qwik loader will fetch the correct code out of the cache and load and execute it just in time. This is called lazy execution. This means a 100mb app will take the same time to load as a 100gb app because either way it is only loading the code that is needed for execution. Qwik resumes the state from where the server paused after the initial render.

Dynamic Tree Shaking

1. Static tree shaking looks at the code and says “is there any possibility you could need to execute this code?” if the answers is “yes” then you have to include it.

2. Dynamic tree shaking can throw out larger chunks of code because it has already rendered on the server and the static items do not need to have code downloaded again on the client because we already know they are not interactive before sending the html to the client. This means much less JS has to be sent to the client.

File Based Routing:
Starts from the entry.ssr.tsx → root.tsx → layout.tsx → index.tsx

Creating components:

Whenever you a dollar sign $ that is a “Lazy Loading Boundry” which means that function is asynchronous. Its an asynchronous lookup.

Two components means we have successfully broken our application into at least two chunks:

The Qwik loader is a global listener for all events. This is inlined into the HTML (only 1kb). In this screenshot below it is finding the code for the on click event on the button and loading the chunk of JS from the cache to execute the code.

For state you need to use a const or a signal to change values across $ boundaries:

Slots

Slots are used for content projection like this:

Use props for reusable components and useContext for contextual components (this will avoid prop drilling and make it easier to handle state)

Props example:

useContext example: