Qwik Fundamentals: Resumability, Signals & the $ Convention

Qwik's defining feature is resumability: instead of hydrating (re-executing component code client-side to rebuild state and reattach listeners, as React/Vue do), Qwik serializes state and listener references directly into the server-rendered HTML, letting the browser resume exactly where the server left off -- without replaying component logic.

The $ Convention & Fine-Grained Lazy Loading

import { component$, useSignal } from '@builder.io/qwik'

// component$ marks a boundary the Qwik Optimizer uses to split code
// into a separate, independently-loadable chunk
export const Counter = component$(() => {
  const count = useSignal(0)

  return (
    <button
      // onClick$ becomes its own lazy-loadable chunk too -- only
      // fetched when this specific button is actually clicked
      onClick$={() => count.value++}
    >
      Count: {count.value}
    </button>
  )
})

Where most frameworks split code per-route, Qwik's Optimizer splits at the level of individual event handlers and component boundaries -- even within a single page, unrelated interactive pieces load independently, keeping the initial JS payload small regardless of overall application size.

Reactive State: useSignal & useStore

// useSignal: a single reactive primitive value, accessed via .value
const count = useSignal(0)
count.value++

// useStore: a reactive object, useful for grouping related state
const state = useStore({ name: '', age: 0 })
state.name = 'Alice'

// Both feed into Qwik's fine-grained reactivity system -- only the
// specific DOM nodes depending on the changed value re-render,
// not the whole component

Resumability vs. Hydration

• Hydration re-downloads and re-executes component code client-side just to reattach event listeners -- a cost that scales with app size.

• Resumability skips that re-execution: enough state/listener metadata is serialized into the HTML that the browser can resume interactivity directly.

• The practical result: event listener code is only fetched exactly when a user actually interacts (e.g. clicks), not upfront on page load.

• This targets a specific problem -- large, interaction-heavy apps where hydration cost with a traditional framework becomes significant.