Qwik v2 beta: resumability instead of hydration, and what it costs you

The problem Qwik targets: hydration cost on first interaction

Most component frameworks ship a server-rendered page and then rebuild the component tree in the browser to attach event handlers. That rebuild is hydration, and its cost scales with the size of the page rather than with what the user actually touches. Qwik's README frames the goal as the opposite: pages that are "fully interactive" with "almost no JavaScript", and a client that can "pick up from where the server left off".

The audience is therefore specific. It is teams whose first paint and time-to-interactive are dominated by JavaScript execution on large, content-heavy pages, and who are willing to accept a different component model to remove that cost. It is not aimed at teams who want to keep an existing React component library unchanged. Qwik ships its own @qwik.dev/react package, but the framework's own mental model is a separate thing to learn, and the README links to a "think-qwik" page rather than claiming drop-in compatibility.

Resumability: what actually crosses the network boundary

The mechanism the README points at is resumability, contrasted with replayable applications. In a replayable model the client re-executes component code to reconstruct state. In Qwik's model the server leaves behind enough serialized information that the client can continue without re-running that work, and the README describes the client as picking up where the server left off.

The second half is precision lazy-loading. The README states that as users interact with the site, only the necessary parts load on demand, and calls this the reason Qwik is quick. So the data flow is: server renders and serializes, client downloads a small bootstrap, and each interaction pulls the code for the part it needs. That is a real architectural difference from a framework that hydrates the whole tree on load, and it is the claim worth testing on your own pages rather than accepting from a tagline.

The repository shows where the build-time work happens. Cargo.toml defines a Rust workspace with members packages/optimizer/napi, packages/optimizer/wasm and packages/optimizer/core, and the release profile sets lto = true with opt-level = "z". The optimizer that transforms your components is compiled Rust, shipped both as a native addon and as WebAssembly. That is why a local build pulls the Rust toolchain: the Makefile has install-rust and install-rust-deps targets, and the latter adds the wasm32-unknown-unknown target and cargo-insta.

Installing Qwik v2 beta and getting a first page running

The README gives one scaffolding command with four package-manager variants. Note the @beta tag: this branch is Qwik v2, and the README states plainly that it is currently in beta and that v1 lives on the v1 branch. Running the command below creates a starter rather than installing a library into an existing app.

npm create qwik@beta
# or
pnpm create qwik@beta
# or
yarn create qwik@beta
# or
bun create qwik@beta

After scaffolding, the README points at two concept pages before you write components: resumable versus replayable, and the high-level mental model. Read those two before porting anything, because the component rules are not the same as in a hydration-based framework.

If you want a build that tracks main rather than a published version, the README documents pkg.pr.new URLs for per-PR and per-branch builds. These are used in place of a version string:

https://pkg.pr.new/QwikDev/qwik/@qwik.dev/core@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/router@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/react@main
https://pkg.pr.new/QwikDev/qwik/@qwik.dev/devtools@main

Working on the framework itself is a different path. CONTRIBUTING.md is where the README sends contributors, and the Makefile exposes the Rust side directly, for example a single test target scoped to the optimizer core:

cargo test --manifest-path packages/optimizer/core/Cargo.toml

The Makefile comment next to that target says it is scoped to core because the other crates have no tests and the napi package breaks the build. That is a useful signal about where the tested surface sits.

Where Qwik v2 beta will cost you time

The first limitation is in the README itself: this branch is v2 and it is in beta. The recent releases listed for the repository are all 2.0.0-beta.43 artifacts (eslint-plugin-qwik, create-qwik and @qwik.dev/utils), so the tooling around the framework is on the same beta cadence as the framework. If your project cannot pin to beta packages, this is the wrong branch.

The second is the build toolchain. The Dockerfile installs the Rust toolchain via rustup, runs make install-rust-deps, then pnpm install and pnpm build. A contributor or a CI image therefore needs Rust plus the wasm32-unknown-unknown target, not just Node. The Dockerfile itself is pinned to node:16.12.0-buster, which is old enough that you should not copy it as your own base image without checking it against your Node requirements.

The third is ecosystem gravity. Resumability is not a drop-in replacement for the hydration model, so component libraries written for React, Vue or Svelte do not carry over unchanged. Qwik's own ecosystem links in the README (Partytown, Mitosis, Builder) are adjacent projects, not a compatibility layer. If your application is mostly an existing component library with modest interactivity, the migration cost is likely larger than the load-time win.

Qwik compared with React on the hydration question

The relevant comparison is Qwik versus React, because the two sit on opposite sides of the hydration line. React renders on the server and then hydrates: the client runs component code again to attach handlers and rebuild state, so the JavaScript executed on load grows with the size of the rendered tree. Qwik's README describes the alternative as picking up from where the server left off and loading only the necessary parts on demand.

The practical difference shows up in two places. On a large content page with few interactive islands, Qwik's model has less to do at startup by construction, while React's startup cost is tied to the tree it must hydrate. On the other hand, React's model is the one your team, your component library and your hiring pool already know, and the README offers no compatibility promise that would let you reuse that investment. Qwik also ships @qwik.dev/react, so React interop exists, but the README lists it as one package among several rather than as the primary story.

A second contrast worth naming is within Qwik itself: the README distinguishes resumable from replayable applications, and points readers at that page before the mental model page. That ordering is a hint about which concept causes the most confusion for newcomers.

Maintenance, releases and the licence terms

The repository is not archived, and the last push was on 2026-09-19, so the codebase is being changed. The published artifacts at the time of writing are beta releases under the 2.0.0-beta.43 line, and the README states that v1 continues on its own branch. For an adopter, that means an upgrade path exists but it runs through a beta series, and the version you pin matters more than usual.

On licence: the repository is MIT. That permits commercial use and modification, and it requires that the copyright notice and permission notice be preserved in copies or substantial portions. It does not grant trademark rights, and it comes with no warranty. This is a description of the licence text, not legal advice; if you redistribute Qwik inside a product, have your own counsel read the LICENSE file in the repository root.

Upgrade cost is mostly a function of the beta cadence and the Rust optimizer. Because the optimizer is compiled Rust with a wasm target, a toolchain mismatch shows up as a build error rather than a runtime one, and the Makefile's install-rust-deps target is the documented way to bring the environment up to date.

Editorial conclusion

Adopt Qwik v2 beta only if you can tolerate beta packages and want to evaluate resumability on a real page: scaffold with npm create qwik@beta, confirm which @qwik.dev/core build you land on, and read the resumable and progressive concepts pages before committing a production route. If you need a stable dependency set today, stay on the v1 branch, which the README names explicitly. Before anything ships, verify the beta status of create-qwik and eslint-plugin-qwik against the releases page, and check that your team can read the Rust optimizer sources under packages/optimizer when a build error comes from there.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. QwikDev/qwik on GitHub
4. README
5. Releases