OpenWebF: a W3C-style web runtime that renders through Flutter instead of a WebView

What OpenWebF replaces, and for whom

The README is blunt about the positioning: WebF "is not a browser, it's an application runtime optimized for building native apps using web technologies." That sentence matters more than the feature list. A WebView embeds the platform's browser engine, so your layout, your JavaScript version and your rendering behaviour differ between iOS, Android and desktop. OpenWebF ships its own stack instead: QuickJS for JavaScript, its own DOM and CSSOM implementation, and a layout engine built on Flutter. The same code path runs everywhere Flutter runs, which the README lists as iOS, Android, Windows, macOS and Linux.

The audience is a Flutter team that already knows React, Vue, Svelte or Tailwind and would rather write that than Dart widgets. The README's build-tools list (Vite, Webpack, esbuild, Rollup, Parcel) and its styling list (Tailwind CSS v3, Sass, PostCSS, CSS Modules, Styled Components, Emotion) describe an existing frontend toolchain being pointed at a new target. If your team has no Flutter code and no intention of writing any, the project offers you nothing that a normal browser does not.

QuickJS plus a Flutter layout engine: the actual pipeline

The README describes two layers. The web standards layer is QuickJS with a single persistent JavaScript context per instance, a DOM implementation with capture and bubble event phases, and a CSSOM that parses rules. The rendering layer is Flutter's own pipeline: the project does not use the system WebView or a bundled browser engine.

The rendering pipeline is stated in five steps: JavaScript executes and mutates the DOM; CSS rules are calculated and applied; layout determines positions and sizes; paint produces the visual representation; Flutter widgets composite the output. Two optimisations are named. WebF tracks "dirty" nodes and recalculates only affected subtrees, which the README compares to React's reconciliation. It also batches DOM updates so they are processed on the next frame, which is how it avoids layout thrashing.

The integration point that separates this from a WebView is the reverse direction: Flutter widgets can be embedded as HTML custom elements, so a native widget sits inside the document tree rather than beside it. The README also mentions FlutterGestureDetector for touch handling and native plugins exposed to JavaScript as npm packages. That is a genuinely different architecture from a bridge that marshals strings across a boundary; the trade-off is that anything you embed this way is Flutter-specific and will not run in a browser.

Installing WebF into a Flutter project

The README points web developers at WebF Go first, a preview app for testing on real devices without building a Flutter app. Desktop builds are linked from openwebf.com/en/go, and mobile builds are on the App Store and Google Play. The prerequisite listed is Node.js, with the latest LTS recommended. That path needs no code at all, so start there if you only want to see how a page renders.

For the in-app route, the README links to a page titled "Add WebF to Flutter" and the repository publishes a Flutter package. The badge in the README points at pub.dev/packages/webf, so the package name to add to pubspec.yaml is webf. The most recent release listed for the repository is 0.24.19, published on 2026-03-20; pin whatever pub.dev actually resolves for you rather than trusting a version copied from an article.

Building the native bridge is a separate step from adding the Dart dependency. The repository's package.json defines a set of scripts per platform, and the name is the same across them with a suffix. The macOS universal build script is:

"build:bridge:macos:universal": "node scripts/build_darwin_dylib"

Prefixing the same script with WEBF_BUILD=Release produces the release variant, which the package.json shows as "build:bridge:macos:universal:release": "WEBF_BUILD=Release node scripts/build_darwin_dylib". Android, iOS, Linux and Windows each have their own script under the same build:bridge prefix, and the README does not claim one command covers them all. Expect to run the script for each platform you ship.

Where the runtime stops being a browser

The feature list says "Essential DOM APIs" and "Comprehensive CSS Support", not complete ones. Flexbox is called the recommended layout mode, with positioned layouts (absolute, relative, fixed, sticky) and flow layouts also supported. That phrasing implies a defined subset with a preferred path, and the README does not enumerate what falls outside it. If your stylesheet leans on grid, container queries or newer selectors, treat compatibility as an open question until you check the documentation site.

Deployment is the second boundary. Over-the-air updates are described as deployable "via CDN without app store reviews", and the README asserts this is compliant with Apple App Store and Google Play Store policies. That is the project's claim about policy, not a guarantee about your app. Reviewers have rejected update mechanisms before, and the README offers no guidance on what content is safe to push this way.

The third boundary is the licence. GPL-3.0 is a copyleft licence, and the README does not discuss what it means for a closed-source mobile app that links the runtime. That question needs your own legal reading; nothing in the repository answers it for you.

Finally, the performance numbers in the README (cold start under 100ms in production, 200 to 300ms in development, 60 or 120fps animations, a 10 to 30MB JavaScript heap, and DOM updates described as 20x cheaper than browser implementations) are the project's own figures. The README does not state the hardware, the test page or the method behind them, so treat them as targets rather than measurements.

How OpenWebF differs from a WebView wrapper

The obvious alternative is a Flutter WebView plugin, which hands rendering to the platform browser engine. The difference is not speed on paper, it is where the behaviour lives. A WebView gives you the real DOM, the real CSS engine and the real JavaScript engine of that platform, so anything that works in Chrome or Safari mostly works. You pay for it with inconsistency: iOS and Android run different engines, and desktop WebViews are a third thing again.

OpenWebF inverts that. One engine everywhere, at the cost of a smaller standards surface. It also changes what you can do at the seam. A WebView communicates with Dart through a message channel; OpenWebF runs JavaScript in a dedicated thread and lets you place Flutter widgets directly in the HTML tree as custom elements. If your UI needs a native map, camera or platform-styled control inside a web-designed layout, that is the case where the OpenWebF model is materially different rather than just faster.

For teams whose app is essentially a website in a shell, with no native widgets mixed into the page, a WebView is the lower-risk choice. You inherit a mature engine and a large body of compatibility knowledge, and you give up nothing you were using.

Release cadence, upgrade cost and the GPL-3.0 question

The repository is not archived. Its last push was on 2026-06-24, and the most recent release listed is 0.24.19 from 2026-03-20, with 0.24.18 and 0.24.17 both landing on 2026-03-11. The version numbers move in the patch position, which suggests frequent small releases rather than long-lived minor branches. The README does not document a support policy, a deprecation process or a migration guide between versions, so an upgrade plan has to come from your own testing against the changelog.

The upgrade cost has two parts that must move together: the Dart package from pub.dev and the native bridge you compile from the repository scripts. Nothing in the README states that they are version-locked, and nothing states that they are not. Verify that before you pin one and forget the other.

The licence is GPL-3.0. That is a strong copyleft licence, and the repository's LICENSE file is the authoritative text. Whether your distribution model is compatible with it is a question for your own counsel. What can be said from the README alone is only this: it does not address commercial licensing, dual licensing or an exception for app developers, so do not assume one exists.

Editorial conclusion

Adopt OpenWebF if you are building a Flutter app and want React, Vue or Tailwind output running on a runtime you control rather than a system WebView. Do not adopt it if you need a general-purpose browser, a fully documented CSS surface, or a permissive licence. Before committing, check the CSS compatibility notes on openwebf.com against your stylesheet, confirm the webf package version you pull from pub.dev matches the bridge you build, and read the GPL-3.0 terms for your distribution model.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. openwebf/webf on GitHub
3. Project website
4. README
5. Releases