跪拜 Guibai
← Back to the summary

Qwik 2.0 Deletes HTML Comments to Defend Resumability, and the Bundle Pays for It

A Framework Deleted HTML Comments to Avoid Hydration

At 15:49 UTC on October 1, 2026, Qwik 2.0 RC was published to npm. Within less than seven hours, SvelteKit 3 and Remix 3.0.0 followed. Three mainstream frameworks colliding on the same day felt like an unplanned collective overhaul.

But the most worth-reading part of the Qwik 2.0 RC release notes is not the new features. It is about what a framework is willing to give up in order to hold the line on "Resumability". One answer: HTML comments.

1. First, clarify: what is Qwik's "Resumability" actually arguing against

Most frameworks' SSR flow looks like this: the server generates HTML, and after the browser receives it, the same component code is loaded and executed again, reattaching event listeners and rebuilding the component tree and state. This process is called hydration.

The problem: the larger the application, the more JavaScript has to execute at startup. Time-to-interactive on first load is not decided by "how big the page is" but by "the total amount of your component code".

Qwik does not do this. Its official documentation describes execution as "paused" on the server and "resumed" in the browser. Listeners are written directly into HTML attributes, such as on:click="./chunk.js#handler"; component boundaries, application state, and the subscription relationships between state and components are all serialized into the HTML. The only thing that runs first in the browser is a small script called Qwikloader. It attaches a global listener and waits until the user actually clicks an element, then loads the corresponding chunk according to the attribute.

The cost of first-screen JavaScript is designed to be independent of the number of components. This is Qwik's core promise, and the one it will not compromise.

2. The cost of v1: those "cute little comments" are actually heavy

In Qwik v1, "serializing state and boundaries into HTML" depended on an unremarkable carrier: HTML comments.

v1's HTML looked like this (simplified example):

<main>
  <!--qv q:id=7 q:key=counter-->
  Count: <!--t=8-->123<!---->!
  <button on:click="...">+1</button>
  <!--/qv-->
</main>

<!--qv--> marks a component boundary, and <!--t=8--> marks which signal drives updates for a text node.

The Qwik 2.0 RC announcement calls these comments "cute little comments", but the same announcement lists their costs very bluntly:

The last two are fatal. The 2026 web platform is pushing hard toward streaming rendering that "delivers content as soon as it is ready", while Qwik v1's comment-marker mechanism physically requires HTML to be written out in order, all at once. This contradicts the story Qwik wants to tell, that the browser should "do less extra work", at a deeper logical level.

3. The v2 answer: throw away the carrier of the markers

Qwik 2.0's choice: stop using HTML comments to carry this information.

v2's HTML becomes this:

<main>
  Count: 123!
  <button on:click="...">+1</button>
</main>
<script type="qwik/state">[...]</script>
<script type="qwik/vnode">...</script>

Comments in the body drop from 60 to 0. All information about boundaries, state, and text-update locations is compressed into two script blocks at the end of the HTML: qwik/state and qwik/vnode.

This is not simply "moving them somewhere else". It brings a chain of structural liberations:

v2 also continues a series of detail-level decisions previewed in the 2024 "Towards Qwik 2.0" design article: vnode information is encoded into strings of about 9 characters; element references use depth-first sequence numbers instead of ID attributes; vnodes are generated on demand and stored as arrays rather than objects to help JIT optimization.

All of these decisions point at the same goal: don't make the browser do extra work.

4. What was sacrificed? The community is not all applause

Qwik 2.0 RC is not a "pure upgrade". It carries a cost the community has already noticed: bundle size increased. Although the "JavaScript that runs before loading" dropped from 59 KB to 9 KB, the overall bundle size went up.

This is a tradeoff worth taking seriously. Qwik v1's comment markers were "heavy", but they let the framework need fewer extra data structures at runtime. v2 concentrates the information into script blocks at the end, producing structural gains in streaming and update efficiency, at the cost of more bytes transferred at once.

The Qwik team's choice implies a judgment: for "Resumability", "how much JS runs on first screen" matters more than "how many total bytes are downloaded". The "jank" users perceive often comes from the main thread being blocked by JavaScript execution, not from downloading a few extra KB. v2 shifts the cost from "runtime" to "transfer time", and in exchange gets streaming and sliceable long tasks.

Whether this judgment is correct depends on your user scenario. For environments with very poor networks but decent device performance, a larger bundle can be a real cost. Qwik 2.0 is not a free lunch; it is a tradeoff made in a clear direction.

5. Released on the same day: three different kinds of "framework subtraction"

Qwik 2.0 RC's release date happened to collide with SvelteKit 3 and Remix 3.0.0. On the same day, three frameworks made three different kinds of "subtraction":

Qwik 2.0 does "remove runtime markers". It deletes HTML comments and concentrates state and vnodes at the end, aiming to make "resuming" cleaner at the streaming and scheduling level.

Remix 3 does "remove framework dependency". It is no longer bound to React. It becomes a single package built on Web primitives (Request/Response), decoupling "full-stack framework" from "UI library".

SvelteKit 3 does "remove the runtime itself". The compile-time framework route goes to its extreme: the runtime is as small as possible, and logic is moved forward into the compilation phase as much as possible.

Three frameworks produced three different answers on the same day, but they asked the same question: in 2026, how much weight should a "framework" carry at runtime?

6. What does this mean for frontend developers?

First, a framework's "design philosophy" is becoming a quantifiable engineering tradeoff. Qwik deleted HTML comments for "Resumability" and paid with a larger bundle. This is not an abstract ideological dispute; it is a concrete tradeoff between "first-screen JS" and "total transferred bytes". When you evaluate a framework, looking at what it is willing to pay for matters more than looking at what it advertises.

Second, streaming rendering is moving from a "framework feature" to a "platform expectation". Chrome's declarative partial updates and Qwik 2.0's out-of-order streaming experiment point in the same direction: HTML should not be punished because of delivery order. When the platform layer starts solving this, a framework's "exclusive capability" in streaming will gradually be standardized.

Third, the "no hydration" route is still niche, but its pressure is pushing the whole ecosystem to think about startup cost. Qwik is not a mainstream choice. But spending two years and eight months polishing v2, and deleting its own most visible mechanism for a single goal, reminds everyone of this: time-to-interactive should not grow without limit as the application grows.

Closing

On October 1, 2026, Qwik 2.0 RC was released. On the same day, SvelteKit 3 and Remix 3.0.0 also arrived.

The most worth-reading part of Qwik 2.0 is not what it added, but what it was willing to delete. HTML comments went from 60 to 0, the bundle grew larger, but out-of-order streaming and 15 ms scheduling became possible.

A framework threw away its most visible mechanism to hold the "no hydration" line. This kind of tradeoff explains what a framework truly believes more than any benchmark number.

Reference links: