WASM - the future of Web Browsers

[zion-sati]

So I've had this idea since WASM was announced. In fact, before there was the concept of WASM, I long imagined a world without HTML/DOM/Javascript, that the web browsers should've always been a dumb display server and OS kernel. I waited and waited but nothing as I imagined ever turned into reality.

Meanwhile, I was playing toying around with iterations after iterations of failed experiments trying to realise this. And I gave up many many times due to many different reasons - wasm size was one, ARIA compliance was another... dev tools debuggability, sheer size of the surface area of what I need to work on, failure of Blazor and Flutter (or rather how much they're frowned upon in the industry), etc all made me give up over and over again.

But in the last year or so, I started again. This time, I've learned from my past mistakes and the failures of Blazor and Flutter. One thing that I realized was the fact that all the frameworks were never web native - they were ported from desktop/mobile etc. And that's the difference. Web is inherently harder and requires more engineering to make a framework feel web native.

What do I mean by this?

The expectations of people using the web are such as page loads almost instantly, responsive UI, nav links bring you to another page that loads nearly instantly too, dev tools with inspections, ARIA / a11y compliance (i.e. semantic tree) for accessibility, touch gestures / fling with momentum and friction etc. Basically WPF+SwiftUI+HTML+CSS+WebBrowser combined.

But let's revisit the core idea of web browsers being a dumb display server and OS kernel. To achieve this, we'd need to strip away HTML/DOM/CSS/Javascript. Today, there's no way we can do that, yet. But with the right abstractions, it'll enable us to swap out the legacy via the Strangler Fig approach.

With all these concepts in mind, I set out with a brand new experiment, and I'm happy to say I'm finally getting somewhere.

EffinDOM + FUI-AS solves all the engineering problems above. FUI-AS is the AssemblyScript UI framework SDK that binds to the C++ UI and Core runtimes (EffinDOM). I've got FUI-RS (Rust) and FUI-KT (Kotlin) planned in the near future - these are simply ports of FUI-AS, all sharing the same C++ UI and Core runtimes.

Being a C# and Microsoft tech stack veteran, I naturally want to see a FUI-CS port as well, but at this stage, dotnet runtimes even with AOT + browser-wasm end up a bit on the hefty side as compared to FUI-AS/FUI-RS/FUI-KT. But the idea is I want to see a world where all languages are first class citizens on the web, with Javascript and DOM/HTML/CSS fully deprecated.

I've written a lot more ideas and docs (e.g. OPEN_CANVAS_API) in the FUI-AS and EffinDOM repos. I'd love some thoughts and feedback. A lot more features are on the way (full dev tools support, long press with teardrops selection handle on mobile etc).

FUI-AS: https://github.com/zion-sati/fui-as
EffinDOM: https://github.com/zion-sati/EffinDOM

Note that it's a 3 tier architecture - everything other than FUI-AS is cacheable. Once the runtimes are stable, you'd expect this to be cached forever (at least until we need to version up, which hopefully is very infrequently). With ICU data, NotoSans fontstack, the runtime wasms, it comes in at around 7MB over the wire using Brotli. Once cached, the page itself is around 100kb over the wire - see the demo page https://fui-as-demo.effindom.dev/home/ (older version - lots of features that are in the pipeline not shown in the demo yet).

My vision: a future web browser is a display server + OS kernel. Hopefully this lines up well with WASM's vision long term.
Appreciate any thoughts, ideas, feature requests, questions etc.

[zion-sati]

A substantial update since the original post.

At the time, FUI-RS was still planned and EffinDOM was primarily a browser experiment driven through FUI-AS. FUI-RS now exists as a published retained Rust UI SDK, and the same application model runs both through WebAssembly and as a native desktop application without a WebView.

The native targets currently are:

• macOS ARM64 and x64 using Metal
• Windows ARM64 and x64 using D3D12
• Linux ARM64 and x64 using Vulkan

The browser side has also moved well beyond rendering pixels. EffinDOM now projects retained semantics and editor state into the browser so its canvas-rendered controls can support ARIA, keyboard navigation, selectable text, IME, clipboard behavior, password-manager extensions, touch selection handles and find-on-page. There is also a retained debug tree rather than expecting browser developer tools to infer application structure from the canvas.

A lot of this work confirmed the premise behind the original post: replacing HTML/CSS as the application UI model is possible, but rendering is the easy part. The difficult work is recreating the browser contracts that users, assistive technology and extensions already expect.

The architecture is now running outside the browser too. EffinDOM keeps layout, text, rendering, input and semantics in shared C++ runtime layers. FUI-RS provides the idiomatic Rust controls, ownership model, events, bindings, workers and application lifecycle. Browser and native hosts adapt that retained state to their respective platforms.

The tooling now supports creating a universal project and producing browser and native outputs:

  cargo install --locked cargo-fui
  cargo fui new my-app --target universal
  cd my-app
  cargo fui dev

FUI-RS live demo:

https://fui-rs-demo.effindom.dev/

FUI-RS source:

https://github.com/zion-sati/fui-rs

EffinDOM ecosystem and architecture:

https://effindom.dev/

Galaga-RS is also the first independent application built with FUI-RS:

https://jatm80.github.io/galaga-rs/

The current uncached browser runtime is approximately 7.6 MB transferred with Brotli, excluding demo images. That includes the renderer, ICU data, built-in fonts, browser bridge and application WASM. A warm load of the demo home route transfers under 500 KB.

This is still pre-1.0. Breaking SDK changes remain possible, Linux assistive-technology validation is early across the wider desktop ecosystem, and Android and iOS are not implemented yet. The remaining HTML, CSS and JavaScript on the browser target are host-boundary implementation details rather than the application programming model.

The original idea was a browser acting more like a display server and operating-system kernel for application runtimes. EffinDOM is now concrete evidence that this direction can work across both browser and native hosts, although there is still plenty left to implement.

I would still appreciate criticism of the architecture, particularly around semantic projection, browser integration and what capabilities a future WebAssembly-native application platform should expose directly.