DEV Community: Zion Sati

HTML, JavaScript, CSS should have died long ago

Zion Sati — Mon, 10 Aug 2026 08:56:32 +0000

EffinDOM: https://effindom.dev/
Rust UI Framework - FUI-RS: https://github.com/zion-sati/fui-rs
FUI-RS Live Demo: https://fui-rs-demo.effindom.dev/

Ever since WebAssembly (WASM) was just a JavaScrpt file, I've already dreamt of the death of HTML, CSS and JavaScript itself.

Death. Gone from the face of the earth.

Okay, that's a bit much - but the dream was it should never have been the de facto stack of Web Apps.

HTML, CSS and JavaScript won. There are millions of developers, libraries for everything, answers on forums and AI trained against existing them.

But ask around and you'll quickly find all good developers hate them. These are three historical accidents that turned into a badly mashed up application model. The world is now tightly coupled with these accidents, making replacing them extremely difficult.

You'll find bad UX every time HTML quietly gives up. A workflow graph is a good example; so is a tmeline, waveform editor, diagram surface, node editor, etc. Let alone a combination of them on the same page. The page itself remains HTML. The difficult bits that HTML can't do becomes canvas, SVG, WebGL or a stupid pile of absolutely position divs...

Sure, we see the pixels appear and at first glance it looks great. Until someone tries to use it.

Does the mouse wheel scroll the page, pan the surface, or zoom it? Does trackpad pinch mean browser page zoom or graph zoom? What happens when a drag leaves the surface? Which layer owns the pointer capture? What about keyboard? Does keyboard focus enter it and tab across its inner elements? Can a screen reader understand them? Does its hover state look the same as the one next to it?

The custom control provider decides and every provider invents a different answer. Sure, you might be thinking that they'd have all sorts of knobs for you to fine tune all of these. But that simply leads to a combinatorial explosion, and prohibits unified design systems.

The custom control surface has become a second UI system embedded inside the first one.

This is why beautiful and sophisticated HTML5 controls often feel so wrong. The control simply has no knowledge of the application - mouse handling, wheel momentum, pinch-to-zoom, pull-to-refresh, touch arbitration, focus, selection, keyboard shortcuts, context menus, accessibility, gestures, etc etc etc are rebuilt inside an island. That is if they go as far as that to begin with.

Even if they do. You could argue, sure, it works. But so does a lot of tech debt.

The hack inside a hack

HTML is excellent at documents (do we need to be reminded what DOM stands for? No, not the latex kinda DOM... the document kind). It was also pretty good for building conventional forms (also a document). Somewhere along the way, we turned it into a general application platform because it was already everywhere, not because a document tree, a cascade and a scripting language somehow formed a brilliant UI architecture.

When the document model runs out of vocabulary, the supposedly "clean" way is to insert a custom rendering surface and rebuild what's missing in JavaScript. However, that creates two owners for the same interaction:

The browser owns page scrolling, page zoom, focus traversal, text input, text rendering, accessibility and platform conventions.
The embedded surface owns its own hit testing, gesture state, inner scrolling, inner page zoom, inner focus traversal, inner text input, inner text rendering, inner... you get where this is going... But the point is, everything "inner" is often just an approximation of the browser's look and feel.

The boundary is where applications become uncanny. GitHub Actions workflow diagram is a good example - it's so bad no matter how long you spent using it, it still feels uncanny. Wheen input is captured when the user meant to scroll. Pinch changes the wrong scale, drag gets stuck because the release happened elsewhere. Keyboard commands work until focus crosses into the island. The graph is themed, but separately so - chances are they'd be sutbly different.

None of this is impossible to fix. Pointer events, touch actions, ARIA, DOM overlays and a crazy amount of JavaScript can reproduce almost anything.

BUT. Once a custom widget has implemented all of that fully polished, it has built a small UI framework. The next control builds another one, often by another provider. Good luck convincing them what the middle wheel button's meant to do...

A canvas is not a UI framework

So I hear you say - what if the entire page is one enormous canvas? It doesn't solve anything - a canvas gives us pixels. It doesn't give us retained control identity, layout, focus, text editing, IME, selection, clipboard behavior, password-manager integration, browser find, semantics, accessibility, touch conventions, or platform-aware shortcuts.

This is where most canvas UI arguments go off the rails. A canvas is a framebuffer, not an application platform.

EffinDOM exists to provide the missing application model. Canvas is simply one presentation surface used by the browser host.

The runtime owns one retained tree for layout, controls, rendering, input, text, selection, scrolling and semantics - yes that's like exactly what the browser currently does. Except the bet is browsers will no longer have to do this in the future.

We then project the parts that the host platform must own. In the browser, that includes a semantic DOM, mirrored editor state, IME integration and browser-facing behavior. On native desktop, it includes the OS accessbility and input adapters.

       Your retained application
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       FUI-RS              FUI-AS
    Rust application    AssemblyScript web
         SDK                  SDK
          └─────────┬─────────┘
                    ▼
                EffinDOM
    layout | text | input | semantics
           ╱                  ╲
          ▼                    ▼
   Browser/WASM             Native desktop
  canvas + host         Metal | D3D12 | Vulkan

The normal application path would share most of the UI code. Genuine platform-specific capabilities would remain available behind clean boundaries.

Native:

Web:

Why start with the browser?

Most custom-rendered UI frameworks start natively and add a WASM target later.

That makes complete sense. Native is easier.

You own the window. You own the event loop. You own rendering, input, clipboard, accessibility adapters and file access. There isn't a browser sitting around your application with thirty years of behaviors users expect you to preserve.

I started with the browser precisely because it is harder.

Drawing some buttons onto a canvas is easy. Drawing them while pretending text selection, IME, password managers, browser navigation, pull-to-refresh, trackpad gestures, accessibility, keyboard focus and find-on-page don't exist is even easier.

But that's not a web application. That's a screenshot that responds to mouse clicks.

For EffinDOM to be credible on the web, it had to participate in browser behavior:

Keyboard, mouse and touch text selection.
IME composition and CJK input.
Clipboard operations and platform-specific shortcuts.
Password-manager and form integration.
ARIA and semantic inspection.
Browser and retained find-on-page.
Routing and independently loaded WASM pages.
Async fonts and fallback.
Page zoom, trackpad pinch and nested scrolling.

And yes, a lot of these are the boring things nobody puts in the first demo.

They are also the difference between a demo and a UI framework.

Once those worked, taking the same retained model to macOS, Windows and Linux was still a lot of engineering work.

Metal, D3D12 and Vulkan did not wire themselves up while I slept.

But architecturally, the direction was much cleaner.

The runtime already knew what a button meant. It already knew what text selection meant. It already knew about focus, scrolling, semantics, editing and accessibility. The native hosts only had to connect that meaning to another platform (I used SDL here which gave me a leg up on unifying the 3 major platforms).

EffinDOM isn't a native UI framework that happens to compile to canvas. It was born in the browser.

The hybrid route is still a hybrid

Cross-platform UI reminds me of the car industry.

Electron and WebView applications are conventional hybrids. They put a native body around a browser drivetrain.

It works. It is incredibly practical. It also means every application drags a browser around just so we can pretend a website became a desktop application. That's your average Slack, GitKraken, VSCode etc. * cough give me back my RAM * Those things are more expensive than gold bars by weight these days!

There is now a cleverer middle ground: remove the WebView and render an HTML-oriented application model natively.

That's a pretty substantial engineering achievement. But it's still a hybrid - the equivalent of a plug-in hybrid.

The browser engine may be gone, but the application still begins with concepts designed for the web, and written for devs who are now close to their fifties (I'm one of them).

EffinDOM and FUI are the EV bet.

I'm not trying to work out how to render HTML somewhere else. I'm asking what should replace it.

Of course, HTML has had three decades to install petrol stations on every corner. Component libraries, browser tooling, integrations, hosting, documentation, experienced developers etc.

FUI has a working drivetrain. Its charging network is young. The built-in controls, browser and desktop hosts, packaging, documentation, Agent Skills and access to the Rust ecosystem cover quite a lot. The third-party control ecosystem does not have thirty years behind it.

Early adopters may occasionally have to plan the route themselves.

That's the bet though. Useful applications create demand for more controls and tooling. Better tooling makes the next application cheaper. Eventually, if enough people use it, the ecosystem develops gravity of its own.

The control that nearly broke the dream

You might assume the hardest control was a graph, custom drawn surface or the interactive dancing yarn demo.

Nope.

It was the boring multiline text box everybody assumes the operating system simply gives you: TextArea. But remember, we are bypassing the browser altogether here.

Text editing exposes every shortcut a UI framework is tempted to take.

Monospaced fonts can use specialized paths. Fixed line heights can be optimized differently to variable line heights (yes unicode chars have different heights encoded by their fonts). Non-wrapping text is different from wrapping text. Static text is different from editable text. Large documents should process only visible lines, otherwise the app crawls to a standstill. Incremental edits should not reshape the entire document.

Then all of those optimizations combine.

Every combination must still preserve Unicode boundaries, caret geometry, forward and reverse selection, scrolling, hit testing, tabs, newlines, clipboard operations, undo, accessibility and font fallback.

On the web, EffinDOM renders the visible editor while keeping a mirrored DOM editor for IME and browser integration.

Text inputs also need the correct semantics for password-manager extensions.

Why retained FUI?

I didn't want another framework that repeatedly rebuilds a description of the UI so it can compare that description with the UI it already had (ok fine, I hate react).

FUI uses retained controls.

Construct the control once. Keep its identity. Change the property that changed.

Focus, selection, editor state, scroll position, subscriptions and overlays remain attached to the actual control the application created.

FUI-RS exposes that model to Rust. FUI-AS exposes the same controls and fluent conventions to AssemblyScript.

The syntax belongs to each language. The application model underneath does not change.

The shared EffinDOM runtime is written in C++ deliberately. Rendering, layout, text shaping, input and semantics are infrastructure for FUI-RS, FUI-AS and future language SDKs such as FUI-KT (Kotlin) and FUI-CS (C#).

A narrow ABI (Application Binary Interface) lets the runtime work with Skia, Yoga, HarfBuzz, ICU, SDL and native platform APIs without reimplementing the engine for every language.

FUI-RS is the idiomatic Rust application surface over a language-neutral runtime.

Is any of this real yet?

Yes.

EffinDOM currently runs in browsers through WASM (WebAssembly) and natively on:

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

No Electron, no system WebView for native apps.

FUI-RS covers browser and native desktop. FUI-AS currently targets the browser (with plans for native desktop in the future).

A universal routed FUI-RS application can compile each browser route into an independently loaded WASM MFE (micro-frontend) while composing the same retained page crates into one native application.

cargo-fui creates, builds and packages the application. It produces DMG, MSIX and AppImage packages. Native-only Rust developers do not need Node.js or npm.

The current uncached browser transfer (cold load) is roughly 7.6 MB compressed:

EffinDOM core: about 1.9 MB.
UI runtime: about 810 KB.
ICU data: about 2.4 MB.
Six built-in fonts: about 2 MB total.
FUI-RS home route: about 321 KB.
FUI-AS home route: about 122 KB.

Most of that is shared infrastructure rather than application code. Within the same top-level site, routes and FUI language SDKs reuse the content-addressed runtime and fixed assets.

A warm load of the FUI-RS demo home page transfers under 500Kb.

What doesn't exist yet?

This is feature-rich early access, not 1.0.

The APIs can still break if my work porting it to Android and iOS deemed it necessary. The third-party control ecosystem is young.

There is one independent community application so far: Galaga-RS, a space shooter with a live browser build.

The point

The web keeps proving applications need more than documents.

Our answer has been to place increasingly sophisticated private UI frameworks inside HTML and try to patch the differences one control at a time. In the world of AI we live in currently, that's a pretty good way to burn tokens.

I refuse to believe another layer of JavaScript is the best the human civilisation can do.

EffinDOM is my attempt to replace the application UI model without throwing away the browser and OS integration users expect.

FUI-RS is the flagship, FUI-AS is the AssemblyScript SDK, and FUI-KT and FUI-CS are early smoke-level language surfaces.

The project is far enough along to build real applications, but early enough that somebody using it can still influence where it goes.

Open the demo.

Scaffold an application.

Try to build something that isn't already in the showcase.

Then tell me where it breaks.

I built a 100KB WebAssembly UI engine that bypasses the DOM but keeps native VoiceOver accessibility

Zion Sati — Tue, 09 Jun 2026 04:52:58 +0000

It was a brownbag session. My colleagues were presenting MobX -- how it was superior to Redux, how it finally solved the state management problem. And my mind wandered.

Not because it wasn't interesting. But because I kept taking steps back.

Past React. Past the virtual DOM. Past JavaScript. All the way back to Delphi -- which if you used it, you know was Win32 done right. A beautiful retained-mode API sitting on top of a system layer, where you described what you wanted and the runtime figured out how to render it. No reconciler. No hooks rules. No "why did this re-render."

I pulled a colleague aside afterwards. Told him I thought we'd built the entire web application platform on the wrong foundation, and that someone should fix it properly.

He told me it was too hard. Impossible. Swimming against the tide.

Eight years of failing

I want to be honest about what "eight years" actually means here, because it wasn't eight years of solid focused work. It was eight years of dabbling, failing, giving up, then being pulled back in by another brownbag or another frustrated frontend conversation.

I've always called myself a backend engineer. I'd jump into frontend when I had to, and every time I did I'd come back with the same quiet frustration. Not because the DOM is bad -- it's genuinely excellent at what it was designed for. HTML is a document model. For content sites, blogs, marketing pages, e-commerce -- it's the right tool, and React and its ecosystem serve that use case well.

The problem is that we started building applications with it. Trading dashboards. Design tools. Kiosks. Data-heavy enterprise UIs. The kind of thing you'd build in WPF or SwiftUI -- retained-mode, stateful, performance-critical. And for that category, a document model is the wrong foundation. Some developers have never known anything else -- they were born into a world where React was already the default, where the reconciler mental model was just "how the web works." Like the Matrix: they can't see the document model underneath because they've never been outside it.

For those of us who remember Delphi, WPF, Qt, SwiftUI -- the mismatch has always been visible.

The moment that hit hardest was watching Blazor fail.

I had real hope for Blazor. Microsoft, serious engineering investment, the promise of writing C# for the web. And it failed -- not catastrophically, but it never became what it could have been. I stopped thinking about this problem entirely for a while after that. Years, actually.

But watching Blazor fail also taught me something. Every canvas framework that tried to target the web had the same fundamental problem. Flutter Web, egui, Blazor, Compose -- all ports, not designs. They were built somewhere else and shoved into the browser. They lost what the web actually offers -- the CDN, the browser cache, the URL distribution model -- and they fought the browser on everything else.

The insight, when it finally crystallized: the only way to do this right is to design for the browser from day one. Not port to it.

What I actually built

EffinDom is a POSIX-style display server for WebAssembly UI. The browser is our Win32. fui-as -- the AssemblyScript SDK -- is our Delphi.

The demo home page -- 100,000-item virtual list on the left, controls on the right. Three routed pages, all running in a canvas with zero DOM UI.

The architecture is a strict three-tier stack:

Tier 1 -- Core (effindom-core.wasm): A stateless C++ WebGL microkernel. Raw drawing instructions. Knows nothing about UI or text. Dumb, fast, memory-safe.

Tier 2 -- UI (effindom-ui.wasm): The retained-mode runtime. Yoga flexbox layout. HarfBuzz + ICU text shaping. Input routing, semantics projection, focus management.

Tier 3 -- FUI-AS: The app-facing SDK. AssemblyScript -- TypeScript-style, compiles to WebAssembly. SwiftUI-inspired fluent API. No HTML. No CSS. No virtual DOM diffing.

A minimal app looks like this:

import { Button, SelectionArea, Text } from "./Fui";

class HelloWorld {
  private count: i32 = 0;
  private readonly label: Text;

  constructor() {
    this.label = new Text("Clicked 0 times");
  }

  buildPage(): SelectionArea {
    return new SelectionArea()
      .fillWidth()
      .fillHeight()
      .child(
        new Button("Click me").onClickWith<HelloWorld>(this, (owner) => {
          owner.count += 1;
          owner.label.text(
            "Clicked " + owner.count.toString() + " time" +
            (owner.count == 1 ? "" : "s"),
          );
        }),
      )
      .child(this.label);
  }
}

export function createHelloWorldPage(): SelectionArea {
  return new HelloWorld().buildPage();
}

No JSX. No hooks. No useEffect. A retained scene graph that does what you mean.

The thing that makes it actually web-native

Every other canvas framework I looked at had the same payload problem. Flutter Web bundles the Skia engine, the Dart runtime, and your app into one monolithic blob. egui statically links its own text shaping and GPU rasterizer. Visit two Flutter apps, download the engine twice.

EffinDom's answer is the Web DLL model.

Tier 1 and Tier 2 are immutable, content-hashed WebAssembly modules served from a CDN. Once a browser downloads them, they're cached forever -- shared across every EffinDom app the user visits. The ICU data, the fonts, the HarfBuzz shaper: all cached, all shared.

Your app payload is just your business logic. Under 100 KB over the wire with Brotli -- even for feature-heavy apps. Your app payload is just your business logic.

This is what web-native actually means -- architecture designed for the browser's actual physics, not retrofitted onto them.

From a web native feel point of view, you have to play around with the demo -- a huge amount of effort have been put into this.

Accessibility wasn't an afterthought -- it was the architecture

Most canvas frameworks get accessibility wrong for the same reason: they design the rendering pipeline first and try to retrofit ARIA on top. Screen reader support becomes a feature request, not a foundation.

I built EffinDom the other way around. ARIA was a first-class architectural requirement before the first control was written. The browser bridge, the coordinate syncing, the real-time semantic tree -- these aren't features added later. They're load-bearing parts of how EffinDom works.

The result: a full ARIA-compliant hidden DOM projected behind the canvas, perfectly synced to GPU coordinates. Every time the layout changes, the semantic tree updates. VoiceOver reads the mirror; the user sees the canvas. They're in sync.

Every control ships with semantic roles and accessible labels baked into the constructor. Not bolted on. Not optional. Built in.

Try this on macOS

Open the live demo
Turn on VoiceOver (⌘F5)
Press ⌃⌥A (Control + Option + A) to read all

VoiceOver highlights canvas-rendered text with the native macOS ring as it reads -- pixel-perfectly synced to the actual GPU coordinates of what's on screen. The native macOS VoiceOver highlight, on canvas text, because EffinDom gives the semantic tree real coordinates.

Tab navigation works too -- that's a separate focus ring baked into the framework itself. Two independent accessibility systems, both working natively, on a canvas app with no HTML inputs anywhere.

Checkbox state changes announce in real time. Slider values are read out. The semantic tree updates as the UI updates -- VoiceOver always reads what the user actually sees.

Flutter Web still can't do this properly. Most canvas frameworks treat accessibility as out of scope. EffinDom treats it as infrastructure.

And since I'm showing off -- the theme system works properly too. This is the same app in light mode on the Advanced page:

Lock-step OS theme interpolation -- frame-by-frame color transitions synced to system theme shifts. Same app, different theme.

What it took

I started writing GUI code at 14 in 1992 -- selling an Editbox control for $1,000, manually programming VGA sequencer registers to switch between four 64 KB memory banks mid-draw. VGA's memory aperture was only 64 KB wide but 640×480×256 colors is 300 KB of pixel data. You had to program the sequencer to switch banks mid-operation, mid-line sometimes. Get it wrong and the screen turned to glitch-art. Get it right and you had a GUI.

That's the kind of problem EffinDom is built on. Thirty years of knowing what good software feels like at the hardware level.

I'll also say this honestly: WPF had a team of hundreds at Microsoft. SwiftUI had a team of hundreds at Apple. I'm one engineer building this at night while my kids sleep. Recent AI tooling is what made that gap closable -- not the architecture or the hard-won lessons, those were earned, but the grunt work that would have taken a team now takes one person. I think that's genuinely one of the most exciting things about where we are right now.

Where it is today

Here's the Text & Fonts page -- rich text with inline styling, custom font stacks, emoji, and live TextArea configuration:

Real HarfBuzz text shaping. Not bitmap fonts. Not CSS tricks. Inline styled spans, emoji, custom font stacks -- all rendered natively on canvas.

The SDK ships today with:

Full control set: Button, Text, TextInput, TextArea, Checkbox, RadioButton, Dialog, VirtualList, RichText, ContextMenu and more
Yoga flexbox layout with SwiftUI-style fluent API
HarfBuzz + ICU text shaping, RTL/BiDi, surgical font subset injection
Transitions and animations
Drag and drop, external file drop
Context-aware right-click menus, built-in Ctrl+F / ⌘F find engine
Automatic IndexedDB state persistence, seamless back/forward navigation
HTTP networking (GET, POST, PUT, DELETE) baked into the runtime
Adaptive 4-flavor WASM compilation (wasm64+SIMD, wasm64, wasm32+SIMD, wasm32)
npx scaffolder -- running in under 2 minutes

Is EffinDom right for you?

Use EffinDom if you're building: dashboards, editors, design tools, kiosks, data visualizations, trading UIs, simulators, enterprise web apps or anything that behaves more like a desktop application than a webpage.

Use HTML/React/Vue if you're building: content sites, blogs, marketing pages, e-commerce stores, anything where the document model is a natural fit.

This isn't a religious war. The DOM is the right tool for documents. EffinDom is the right tool for applications. Both can coexist -- they serve fundamentally different purposes.

Zero third-party runtime dependencies. Zero vulnerabilities.

Run npm install on a scaffolded fui-as app. Check the output:

found 0 vulnerabilities

The only runtime dependencies are EffinDom's own packages. No third-party code runs in the browser. Not a few dependencies -- none.

A typical React app has hundreds of transitive dependencies. Every one is a potential supply chain attack vector. Log4Shell, XZ Utils, the Polyfill.io compromise -- enterprises and banks have entire security teams whose job is auditing that graph. Some organizations can't ship to production without a full dependency audit that takes weeks.

EffinDom's answer is: there is no third-party runtime dependency graph to audit. The only code that runs in the browser is yours and EffinDom's own hermetically bundled, content-hashed packages.

The runtime is hermetically bundled inside the npm package. No external CDN calls at build time. No transitive packages. The WASM binaries are content-hashed -- you know cryptographically exactly what you're running. Air-gapped build environments work out of the box.

Your app is just your code. That's the entire attack surface.

Honest alpha status (v0.1.x)

Core rendering, the full control set, layout, theming, routing, accessibility, networking, and state persistence are all solid and heavily tested. No handle leaks -- incremental GC is running.

Mobile: the demo is responsive across screen sizes. Touch input, fling scrolling, and pull-to-refresh work. Find-in-page works on mobile too -- it draws a text overlay above the canvas rather than highlighting canvas text directly, which is a known limitation of the approach. Pinch-to-zoom and long press aren't there yet.

Layout edge cases: conflicting constraint trees produce undefined behavior. Two sibling columns both calling .fillWidth(), for example -- both asking to fill the parent's width, no defined winner. The framework won't crash but the result isn't guaranteed. Avoid ambiguous constraint trees and you'll be fine.

This is early alpha. The foundation is solid. The edges are still being polished.

Try it

npx @effindomv2/create-fui-as-app my-app
cd my-app
npm install
npm run dev

→ Live demo (pinch-to-zoom and long press not yet supported)
→ fui-as SDK (AssemblyScript)
→ (under construction) fui-kt SDK (Kotlin)
→ (under construction) fui-rs SDK (Rust)
→ EffinDOM runtime

On licensing and sustainability

The runtime is MIT -- use it freely forever. The fui-as/fui-kt/fui-rs SDKs are dual-licensed: AGPL for open source use, commercial license for proprietary products.

I'm a solo maintainer with a young family building this after hours. AGPL means open source use is genuinely free, and commercial use funds the project's survival. If you're at a company building something commercial on top of this and AGPL doesn't fit, that commercial license is how this stays alive long term. If you know someone who should be talking to me, reach out: zionsatidev@gmail.com

The web deserves better infrastructure than a 1995 document viewer. I've spent eight years and a lot of failed experiments believing that. I think I've finally built something worth believing in.