Skip to content

why-async.md

Latest commit

 

History

History
31 lines (21 loc) · 1.57 KB

why-async.md

File metadata and controls

31 lines (21 loc) · 1.57 KB
Raw

Why Async

Async is for apps that want direct HTML, explicit state, and server-friendly fragments without adopting a render loop.

What it keeps

  • Native HTML remains the document contract.
  • ESM modules register behavior explicitly.
  • Server-led documents and fragments remain valid Async views, even when a non-JavaScript backend renders the HTML string.
  • Signals are the state boundary.
  • Server calls and route partials return simple response envelopes.
  • Boundary swaps rescan the inserted HTML for on:, signal:, class:, intersect:, and component protocol.

What it avoids

  • No virtual DOM.
  • No hidden hydration pass.
  • No implicit startup fetch.
  • No component rerender loop.
  • No server-only cache contents in browser snapshots.

Who it fits

Async fits pages that need server-led views, progressive reactive islands, server-backed actions, route fragments, streamed HTML, or a small runtime surface that can be understood from the markup.

It is also the base of L0-L7 abstraction layers, from htmx-style enhancement (L0) up through JSX transforms (L4) and a future whole-program compiler (L7). Build-required JSX and compiler tooling lower to the same HTML protocol, registries, route partials, and boundary patches, and capabilities land at the lowest layer the protocol allows: out-of-order streaming works from a no-build script tag. See the Layers guide.

Useful tradeoff

Async asks authors to name runtime behavior directly. That makes the markup more explicit, but it also keeps the browser path small and makes server output easy to inspect.