Qwik has been defending a concrete idea since 2022: hydration is debt, not functionality. A well-built site should be able to resume server state in the browser without re-executing the entire component tree.

Behind the project is Miško Hevery, the creator of Angular. He started Qwik as a personal project in January 2021 and moved it full-time to Builder.io from June 2022, as he told The New Stack in an interview[1]. The code lives in the QwikDev repository on GitHub[2], where you can follow the pace of each release.

Two and a half years after its first stable release, the 1.x series is settled and there are real cases published by companies that aren’t the original author. It’s time to review whether that idea holds at a real keyboard, whether it’s worth the learning curve, and in what kind of product the client-side JavaScript savings matter most.

For the frontend framework selection context, the analysis of HTMX in enterprise describes the no-client-JavaScript alternative, and the post on TypeScript 5.5 advanced types covers the typing ecosystem where Qwik operates. Client-side performance also connects with the topic of basic WCAG accessibility, where initial load impacts the experience.

Key takeaways

  • Qwik serializes state and event handlers inside the HTML itself; the client resumes from where the server stopped without reconstructing the component tree.

  • A Qwik site ships 20–50 KB of initial JavaScript, versus the 200–500 KB common in a medium Next or Nuxt application.

  • Fits well in e-commerce, media, and B2C applications where time-to-interactive is a commercial metric.

  • Young ecosystem with visible gaps and a real mental model change are the two main brakes.

  • Qwik City covers 80% of what a product needs without looking elsewhere.

What resumable means in practice

Most modern frameworks like React or Vue hydrate: the server renders HTML, sends it to the browser, and when the JavaScript arrives, the client re-executes the entire component tree to attach event handlers. This works but has a visible cost on modest devices and slow networks.

Qwik does something different. The server renders HTML and, instead of sending a serialized component tree, it serializes state and event handlers inside the HTML itself. When the user clicks, a small loader downloads only the handler code it needs and executes it. There’s no tree reconstruction, no hydration pass, no initial JavaScript cost beyond the minimal loader.

The word they use is resumability and it describes precisely what the architecture does. The server executes once, pauses, serializes; the client resumes from where the server left off. What in other frameworks means executing twice (once on server, once on client), in Qwik means executing once, with a long pause between steps.

The official Qwik documentation on resumability[3] describes it as serializing three things into the HTML: event listeners, component boundaries, and application state. Builder.io’s comparison of resumability versus hydration[4] details why that shift skips the re-execution hydration forces you to pay for.

What pushes toward using it

What pushes toward Qwik is one concrete thing: applications where time-to-interactive is a measurable business problem:

  • E-commerce stores where each extra second costs sales.

  • News sites where the time until the user can scroll is a central metric.

  • B2C applications where abandonment has cost.

For these cases, a Qwik site ships 20–50 KB of initial JavaScript, versus the 200–500 KB you see in a medium Next or Nuxt application. That difference is palpable in Lighthouse, in Web Vitals, and in perceived experience especially during the first minute of a new visit.

Where it’s less worthwhile

What pushes away from Qwik is the ecosystem size. React has thousands of mature libraries: tables, charts, rich text editors, calendars, accessible components. Qwik has a young ecosystem with visible gaps.

If your product depends on a rich text editor with twenty plugins, you’ll have an easier time with React. If your product is forms, routes, and some state, Qwik covers that without effort. The State of JS 2025[5] survey confirms that small-ecosystem feeling. The other frontend frameworks stay stable year over year, and Qwik is the exception that keeps losing ground in the satisfaction reported by surveyed developers.

The second brake is the team. Qwik changes the mental model enough that a React developer won’t move fluently in the first month. The dollar-suffixed functions, the way server and client code is separated, the optimizer warnings about non-capturable dependencies: all this requires understanding how serialization works. A six-person team invests two or three sprints in getting comfortable, no more, but that investment is real and must be counted.

Common paths in 2025

The most common path in 2025 is starting with Qwik City, which is to Qwik what Next is to React. It brings file-based routing, server data loading, declarative forms, and integrations with deployment platforms like Vercel or Cloudflare Pages. Qwik City is stable and covers 80% of what a product needs without looking elsewhere.

For the UI layer, the community has settled on few options: Qwik UI for unstyled components and Tailwind for appearance. Tailwind doesn’t depend on the framework; classes live in HTML and Qwik serializes without surprises. Other component systems relying on CSS injection at runtime fit worse.

Data loading is done with server routes returning serialized objects. The common pattern is using routeLoader$ to read data on the server before render, and server$ for functions exposed as RPC to the client. These two primitives cover most communication cases and have a reasonable error model.

Integration with existing services

Integration with external services is rarely a problem. Qwik serves like any standard web server, speaks HTTP, can consume REST or GraphQL APIs with no difference from React.

What changes is how work is split between server and client. In React it’s more common to fetch on the client and show a loading state. In Qwik the default pattern is to fetch on the server and ship complete HTML, with the client resuming only interactivity.

One point requiring thought is authentication. If the application depends on an OAuth flow with Authentik or Keycloak, Qwik City includes mechanisms to manage cookies and sessions in server routes similar to what Next would do. No surprises, but the pattern is a bit different and documentation must be read once before not having to read it again.

What appears with months of use

With months of use, details emerge that documentation doesn’t tell:

  • State serialization enforces discipline: anything that can’t go to JSON triggers optimizer warnings. This forces simpler state, which ends up being good for maintenance, but costs at the start.

  • Error traceability in production is different: because code downloads in chunks, browser stack traces are more fragmented. Sentry and similar tools work, but the first time you debug such an error you take longer than expected.

  • Production compilation is slow because the optimizer analyzes all lazy boundaries: in medium projects, one to two minute compilations. Not drama for CI but worth knowing.

My reading

Qwik is a coherent bet on a real problem. Client-side JavaScript cost is a silent debt that almost every modern site carries, and resumability is the first architectural response I’ve seen able to reduce that debt without paying for it elsewhere. It’s not magic: there’s discipline to accept, a young ecosystem to live with, a short but real curve. But the benefits are measurable and visible.

I don’t think Qwik will displace React, because React has inertia and ecosystem. I think it will occupy the niche of products where client-side performance is a commercial metric: e-commerce, media, high-traffic landing pages, B2C applications where abandonment has cost. My practical criterion: if the team has appetite to learn and the product suffers from JavaScript weight, Qwik is a sensible bet. If the team is large, the product is complex, and performance isn’t a hard metric, React or Svelte remain the default.

This article is also available in Spanish.

Frequently asked questions

How much JavaScript does a Qwik site ship compared with Next or Nuxt?

A Qwik site ships 20 to 50 KB of initial JavaScript, versus the 200 to 500 KB common in a medium Next or Nuxt application. The difference comes from resumability. The server serializes application state, component boundaries and event listeners inside the HTML itself, and the client downloads only the handler code when the user interacts, with no hydration pass. The savings show up in Lighthouse, in Web Vitals and especially during the first minute of a new visit.

How long does it take a React team to become fluent in Qwik?

A six-person team invests two or three sprints in getting comfortable, no more, but that investment is real. The mental model changes enough that a React developer will not move fluently in the first month. The dollar-suffixed functions, the way server and client code is separated and the optimizer warnings about non-capturable dependencies all require understanding how serialization works. Anything in state that cannot go to JSON triggers warnings, which forces simpler state.

What problems show up with Qwik after months in production?

Three that the documentation does not mention. Serialization enforces discipline, because anything that cannot be converted to JSON triggers optimizer warnings. Browser stack traces are more fragmented, since code downloads in chunks; Sentry and similar tools work, but the first time you debug such an error takes longer than expected. And production compilation is slow because the optimizer analyzes all lazy boundaries: one to two minutes in medium projects, fine for CI but worth knowing.

Sources

  1. The New Stack in an interview
  2. QwikDev repository on GitHub
  3. official Qwik documentation on resumability
  4. Builder.io’s comparison of resumability versus hydration
  5. State of JS 2025