Runtime Architecture

WebF embeds a browser-grade rendering pipeline directly inside the Flutter engine. Understanding the moving pieces helps you decide what should live in Flutter and what should ship as web code.

High-level flow

1. Asset bootstrap — Your Flutter app ships a zipped web bundle (HTML, JS, CSS, fonts) or downloads one from your CDN. WebF mounts it into a virtual file system and resolves relative imports just like a browser would.
2. JavaScript runtime — A persistent JS context (powered by QuickJS) runs for the lifetime of the Flutter process. There is no tab/page lifecycle, so global state stays alive across navigations and deep links.
3. DOM & CSSOM — WebF implements W3C/WHATWG specs (DOM, CSS parsing, layout, painting). Layout primitives such as Flexbox, Grid, and absolute positioning are mapped to Flutter’s render objects.
4. Compositing — The final render tree becomes a Flutter LayerTree. You can stack it with native Flutter widgets, apply transforms, or show it inside a Navigator route.

Perf characteristics

• Cold start < 100ms in production builds by streaming assets directly into the runtime.
• Incremental layout keeps mutations cheap; WebF tracks dirty nodes and schedules microtasks like a browser event loop.
• Shared GPU context — Canvas, CSS filters, and animations are executed on the same surface as Flutter, so transitions remain 60/120fps.

Native bridges

WebF exposes typed channels so JavaScript can call into Dart (and vice versa):

• webf.bridge.invoke('nativeMethod', payload) to trigger Dart logic.
• WebFChannel in Flutter for sending events back into the DOM (for push notifications, deep links, etc.).

Because the JS context never dies, treat it like a singleton. Release resources manually when you tear down long-running workers.

When to stay native

Use Flutter for scenarios that depend on platform-specific views (Camera, Maps, AR). Everything else—marketing surfaces, dashboards, LOB workflows—can live entirely in WebF, letting the web team ship at web speed.