WebTransport

WebTransport

WebTransport gives the browser a realtime transport built on HTTP/3 and QUIC. The reason teams care is not novelty; it is that one connection can carry multiple streams, datagrams, and migration-friendly transport semantics that do not map cleanly onto WebSockets.

const transport = new WebTransport('https://api.example.com/session');
await transport.ready;

const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
const reader = stream.readable.getReader();

await writer.write(new TextEncoder().encode(JSON.stringify({ type: 'join' })));

When WebSockets Stop Being a Great Fit

If you need multiple independent flows with different priorities, unreliable delivery for some messages, or transport behavior that survives network changes more gracefully, WebTransport is the more interesting primitive.

Streams and Datagrams Are the Point

Bidirectional and unidirectional streams handle ordered application flows cleanly. Datagrams cover low-latency messages that do not justify retransmission. Putting both on one HTTP/3 connection gives you a far more expressive realtime contract.

Connection IDs Beat Sticky Assumptions

QUIC uses connection IDs so a session can survive certain network changes without pretending the client is still on the same 5-tuple. That is a real operational advantage for mobile and flaky-network environments.

Operational Guidance

Do not reach for WebTransport just because it is newer. Use it when your application genuinely benefits from multiplexed streams, datagrams, or transport migration. Otherwise, the simpler protocol probably wins.

---