Qwik starter CLI is a simple starter for you to try experimenting with Qwik first hand and to get a better understanding of just how different it is.
The CLI consist of these four examples, that will be expanded in the near future:
starter: A basic hello world.
starter-builder: A basic hello world integrated with Builder's Qwik API.
starter-partytown: A basic hello world showing how expensive tasks can be run on web-worker with Partytown
todo: A classic TodoMVC application.
- Network bandwidth: If our site has a vast amount of JS code, it would take a long time on a slower network to be downloaded on the client’s device.
- Startup time: The start-up time of the site is affected as the entire JS code needs to be executed as part of hydration whenever the page is loaded.
As mentioned above, by eliminating the bottlenecks in the loading time, Qwik claims to achieve two important goals.
- Instant load: Unlike other frameworks, quick is “resumable”, a new paradigm coined by the Qwik team to provide 0 hydration. This allows Qwik apps to have instant load interactivity, regardless of the size of the app or complexity. This means the app would load instantaneously without any lag on any network.
How does Qwik achieve this?
Qwik basically achieves this through two important strategies:
- Serialize the execution state of the application and the frame on the server and resume it on the client.
Let’s understand how Qwik implements these strategies.
You might think if we are not shipping the JS code then how our app would become interactive? Actually, Qwik does ship it but not at the application startup but instead on the interactivity. Qwik uses a lot of information during SSR to start prefetching only the bits of interactivity of the current page as soon as possible, this way when the user clicks or interacts, the JS is already downloaded.