Building Flutter for the Web (Hummingbird): Architecture, Rendering Pipeline, and Current Status

At Flutter Live the team announced the effort to run Flutter on the Web, outlining the challenges and the current state of the project.

Flutter is a multi‑layer system where higher layers are easy to use and lower layers provide more control. The lowest layer, dart:ui , handles pixel‑level rendering and is wrapped by the Dart‑written framework, while engine code is written in C++, Java (Android) and Objective‑C/Swift (iOS). Plugins can be written in Java/Kotlin or Objective‑C/Swift to access native APIs.

Web Platform Requirements

To run Flutter on the Web we need to compile Dart to JavaScript, select a subset of Flutter that can run on browsers, and choose a matching subset of Web technologies (HTML, CSS, SVG, Canvas, WebGL).

Prototype Approaches

Widgets only : Implements the widget framework using native Web layout features such as flexbox, grid and overflow:scroll.

Widgets + custom layout : Adds Flutter's RenderObject‑based layout system, mapping render objects directly to HTML elements.

Flutter Web Engine : Retains the full dart:ui stack and provides a browser implementation of dart:ui .

The third prototype was chosen because it offers the highest level of code reuse across platforms.

Rendering Pipeline

Each frame Flutter builds widgets, performs layout, and then paints them. The widget build process is platform‑agnostic; the Dart compiler (dart2js) translates widgets and frames to JavaScript.

Layout

Layout is straightforward for core widgets (Center, Row, Column, etc.) but text layout is challenging because browsers lack a direct API. Flutter measures text by inserting a paragraph into the DOM, reading offsetWidth, offsetHeight, and using a probe element to obtain baselines via getBoundingClientRect.

Painting

Widgets are ultimately rendered as a combination of HTML/CSS, Canvas, SVG, and WebGL. Two strategies are explored:

HTML + CSS + Canvas (DomCanvas and BitmapCanvas)

CSS Paint API (experimental, runs in a paint worklet similar to a web worker)

HTML + CSS is preferred because browsers optimise the display list, allowing transformations and opacity via standard CSS properties such as opacity and transform. When HTML/CSS cannot express an image, Canvas 2D is used, with a custom overflow: hidden implementation for clipping.

CSS Paint API

The CSS Paint API, part of the Houdini project, lets custom paint worklets draw graphics without creating bitmap canvases, offering 2D‑canvas‑like performance without pixelation. At the time of writing only Chrome and Opera fully support it, and text painting is not yet available.

Embedding and Interop

Flutter Web can call any Dart library available in the browser and fully supports JavaScript interop via package:js and dart:js. CSS usage is limited to a small, performance‑guided subset to keep layout predictable for the Flutter engine.

Embedding Flutter into existing web pages (e.g., via <iframe> or Shadow DOM) and embedding non‑Flutter components (React, Angular, custom elements) are future work, with concerns about performance and CSS side effects.

Portability and Limitations

While Flutter aims for maximum code reuse, not every Flutter app will run on the Web unchanged; plugins that rely on unavailable native APIs (e.g., ARCore) cannot be used, and file‑system or low‑level network access is restricted.

Current Status

The Web engine can render most of the Flutter Gallery, including all Material widgets and the Shrine and Contact Profile demos. Cupertino widgets are not yet ported.

Flutter running in desktop Chrome – video: https://www.youtube.com/watch?v=5IrPi2Eo-xM

The source code will be open‑sourced soon, initially as an internal Google project and later moved to the public github.com/flutter repository.

In conclusion, the article outlines the problems being solved to make Flutter run well on the Web and invites feedback from the community.