Client Boundaries

Vango is server-driven by default. Client capabilities exist, but they are meant to be explicit ownership boundaries, not generic escape hatches.

Choose The Smallest Boundary

browser behavior on server-owned DOM	`Hook(...)`
client-owned subtree	`JSIsland(...)`
client-local Go execution	`WASMComponent(...)`

Hooks

Hooks are the right tool when:

the server still owns structure
the browser only adds behavior
you need a small bridge for focus, drag-and-drop, measurement, or integrations

Validate hook payloads server-side. A hook can observe browser-local behavior, but it does not become a trusted authority.

Islands

Islands are the right tool when:

the client runtime should own a subtree
a rich editor or widget already expects client control
trying to force server ownership would create brittle DOM repair work

WASM

WASM is the right tool when:

Go itself should run client-side
offline or local compute matters
a hook or island would be too narrow

Avoid the wrong fix

Do not use inline scripts, ad hoc DOM mutation, or client-side repair code to patch around server/client mismatches. If ownership is unclear, fix the boundary instead of layering hacks on top.

The Launch Default

For most new app code:

keep the DOM server-owned
use hooks sparingly
reach for islands or WASM only when product behavior clearly requires them
use the standard hook wrappers when they fit before building bespoke browser code