Essay
B
Software architecture

The Two Webs

Domenico Giordano18 min · read

In January 2023, Ian Hickson — the man who co-edited the HTML5 specification — published a document arguing that, for applications, HTML should be optional. He proposed that browsers render pages compiled as WebAssembly directly to the GPU, bypassing HTML, CSS, and JavaScript altogether.

Read that sentence again. One of the architects of the modern web is now suggesting we route around the modern web for an entire class of software.

Hickson is not a fringe voice. He worked on HTML, on the WHATWG, on Flutter. He has spent two decades building exactly the platform he is now proposing to make optional. His document — titled, mildly, "Towards a modern Web stack" — begins like this:

"Web pages today are built on 25-year-old technology: a markup language for scientific documents from 1991, a scripting language from 1995 whose first version was implemented 'in ten days', a styling and layout model from 1996..."

When the people who built a thing start drafting plans to live without it, something is shifting. This essay is about what that shift is, who is already living through it, and why the open web should probably acknowledge it.

I write this as someone who has spent twenty years building user interfaces — from CRM consoles in the early 2000s, to latency-sensitive operator consoles where every millisecond feeds back into the product, to a feature flag SaaS where the DOM is friend. The frustration in this essay is not theoretical. It is what happens when an HTML page is asked to be a workstation.

These observations are not original. Alex Russell has been documenting the "performance inequality gap" between hardware and web apps for years. Andy Wingo at Igalia has been writing about the extensible web since 2014. Bret Victor's critiques of GUI development apply directly. What follows isn't a discovery — it's a synthesis of patterns that practitioners already see and standards bodies are slowly recognising.

How HTML Got Stretched Too Far

In 1991, Tim Berners-Lee created HTML to share scientific documents among researchers at CERN. It was text with hyperlinks. It worked beautifully for what it was designed to do.

Thirty-four years later, we use that same foundation to build banking applications, real-time collaboration tools, trading platforms, and design software that rivals Adobe's native applications. We've put a Formula 1 engine on a bicycle frame and spent three decades wondering why it shakes.

This isn't a criticism of HTML. HTML remains excellent for documents — articles, documentation, marketing pages, blogs. The problem is that we've stretched it far beyond its original purpose, and the web development industry has normalised the resulting dysfunction.

Every modern frontend framework exists primarily to work around the limitations of the DOM. React's virtual DOM, Vue's reactivity system, Svelte's compiler — these are all sophisticated workarounds for a fundamental mismatch between what we're building and the platform we're building on.

But something interesting is happening. Quietly, without manifestos or grand announcements, major companies are abandoning the traditional DOM-based approach for their most demanding applications. They're not waiting for standards bodies. They're building the future themselves.

The Evidence: Who's Already Building the Other Web

Figma: A Browser Inside a Browser

When Evan Wallace started building Figma in 2012, he made a radical bet: ignore the DOM entirely for rendering.

Figma's approach is instructive. The application is written in C++, compiled to WebAssembly, and renders everything through WebGL (now transitioning to WebGPU). As the Figma engineering team described it: "We've basically ended up building a browser inside a browser."

The results speak for themselves. When Figma migrated from asm.js to WebAssembly, they measured a 3× improvement in load times. But more importantly, they achieved something the DOM couldn't give them: pixel-perfect consistency across platforms, sub-millisecond rendering updates, and the ability to handle documents with thousands of objects without performance degradation.

Figma's architecture reveals the pattern:

  • C++ engine compiled to WebAssembly for computation
  • WebGL/WebGPU for rendering, bypassing the DOM completely
  • Custom text layout engine because browser text rendering is inconsistent
  • Custom compositor because the browser's compositor doesn't expose the primitives they need
  • React + TypeScript only for the peripheral UI (panels, menus)

The canvas — the core of the application — doesn't touch the DOM at all.

In September 2025, Figma announced their migration to WebGPU, the successor to WebGL. This isn't just a performance optimisation; it's a commitment to an architecture that treats the browser as a portable runtime, not as a document renderer.

Google Docs: The Quiet Revolution

In May 2021, Google announced something that received surprisingly little attention: Google Docs was migrating from HTML-based rendering to canvas-based rendering.

The announcement was understated: "We're updating the way Google Docs renders documents... to improve performance and improve consistency in how content appears across different platforms."

But the implications were profound. Google Docs — one of the most widely used web applications in the world — was abandoning the DOM for its core functionality.

Steve Newman, one of the original authors of Writely (which became Google Docs), explained the reasoning: "Word processors have extremely specific requirements for layout, rendering, and incremental updates... Modern browser engines are amazing feats of engineering, but the feature set they provide, while enormous, is unlikely to exactly match the exacting requirements of a WYSIWYG word processor."

Newman's observation cuts to the heart of the problem. The DOM is a general-purpose tool optimised for documents. When your requirements differ even slightly from what it was designed for, "you start tipping over into complex workarounds which impact performance and are hell on developer productivity."

Google Sheets had already made this transition years earlier. Google Maps uses canvas rendering. The pattern is clear: for Google's most demanding applications, the DOM is a liability, not an asset.

Flutter Web: Google's Explicit Bet

If Figma and Google Docs quietly bypassed the DOM, Flutter Web does so loudly and explicitly.

Flutter's web renderer doesn't generate HTML elements. It compiles Dart code to JavaScript (or WebAssembly), and renders everything to a canvas using either CanvasKit (Skia compiled to WebAssembly) or the newer skwasm renderer.

In 2024, Google announced they were deprecating Flutter's HTML renderer entirely, leaving only the canvas-based renderers. The message was unambiguous: for application development, canvas rendering is the future.

Flutter Web's approach has tradeoffs. SEO is essentially impossible since there's no HTML for crawlers to index. Accessibility requires extra work since screen readers can't parse canvas content natively. The initial bundle size is larger due to the Skia runtime.

But for applications — internal tools, dashboards, productivity software — these tradeoffs are often acceptable. And the benefits are substantial: true cross-platform consistency, smooth animations at 60fps, and freedom from the quirks of browser CSS implementations.

WebAssembly: The Escape Hatch Becomes Mainstream

WebAssembly was released in 2017 as a compilation target for languages like C++, Rust, and Go. Its original promise was near-native performance in the browser.

By 2026, WebAssembly has become something more significant: an escape hatch from JavaScript's limitations for performance-critical code.

The adoption numbers tell the story. WebAssembly usage has grown from 0.04% of websites in 2021 to 5.5% across Chrome users in 2026. But this understates its impact, because the most significant deployments are inside major applications rather than standalone sites.

AutoCAD runs in the browser via WebAssembly. Unity games compile to WebAssembly. Adobe's tools increasingly rely on it. Photoshop for web, Lightroom for web, Premiere elements — all leverage WebAssembly for their computational cores.

What WebAssembly doesn't have — and may never have — is direct DOM access. As the Communications of the ACM has observed: "Wasm might never get direct DOM access." The WebAssembly-JavaScript boundary requires serialisation, which creates overhead.

This limitation reveals something important: WebAssembly isn't designed to replace JavaScript for DOM manipulation. It's designed for computation. The emerging architecture is hybrid: JavaScript for the DOM and orchestration, WebAssembly for heavy computation.

One reasonable objection arises here: if Figma already bridges Wasm and DOM successfully, why not standardise that bridge instead of inventing a new runtime? The answer is that Figma's bridge is bespoke. Every team that wants Figma's architecture has to rebuild it. Standardisation is not about whether the pattern works for one team. It is about whether it works for the next thousand teams who cannot afford to build their own browser inside a browser.

Servo: Reimagining the Browser Engine

While companies build applications that bypass the DOM, the Servo project asks a different question: what if we rebuilt the browser engine itself with modern principles?

Servo is a web rendering engine written in Rust, originally developed at Mozilla and now hosted at Linux Foundation Europe. Its distinguishing feature isn't just the language choice — it's the architecture.

Unlike every other major browser engine (all written in C++), Servo uses parallelism throughout. Layout is parallel. Style computation is parallel. Rendering is parallel. The engine is designed from the ground up to exploit modern multi-core processors.

In 2025, Servo remains experimental — it can't yet serve as anyone's daily browser. But its architecture proves a point: the single-threaded assumptions baked into current browsers aren't fundamental laws of physics. They're implementation choices that could be revisited.

Parts of Servo have already shipped in Firefox. Stylo (the parallel CSS engine) and WebRender (the GPU-based renderer) originated in Servo. The ideas are migrating into production, even if the complete engine isn't ready.

TC39 Signals: Reactive State as a Primitive

One of the most telling developments in web standards is the TC39 Signals proposal, which reached Stage 1 in April 2024.

Signals are reactive primitives — cells of state that automatically propagate changes to dependent computations. They're the foundation of reactivity in frameworks like Vue, Solid, Svelte, and Angular.

The proposal emerged from an unusual collaboration. The authors include maintainers of Angular, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Svelte, Vue, and more. These are competing frameworks, yet they agreed on a common reactive model.

Why? Because they're all implementing the same thing. Every major framework has invented its own reactivity system, and they're all fundamentally similar. The duplication is wasteful — as one contributor noted, "Billions of lines of code have been duplicated across these ecosystems solely because the reactive systems are separate."

The Signals proposal acknowledges something that practitioners have known for years: reactive state should be a platform primitive, not a framework feature. The fact that framework authors — competitors in the marketplace — are collaborating on a standard reveals how strongly they agree on this point.

If Signals becomes a JavaScript standard, every framework could share a common reactivity core. Framework-agnostic libraries could integrate with any reactive system. The ecosystem fragmentation that plagues frontend development would partially heal.

But Signals addresses only one piece of the puzzle. It doesn't solve the DOM bottleneck, the single-threaded rendering model, or the lack of component primitives. It's a step toward the application web, not the whole journey.

Web Components: The Slow Burn

Web Components have been "the future" for over a decade. In 2025, they're finally approaching mainstream adoption — not as a replacement for frameworks, but as a foundation for framework interoperability.

The technology stack — Custom Elements, Shadow DOM, HTML Templates — is now fully supported in all major browsers without polyfills. Libraries like Lit (from Google) have made Web Components practical to write.

The killer use case isn't replacing React or Vue. It's building design systems that work across frameworks. A company with teams using different frontend stacks can share a component library if those components are Web Components. They're the lowest common denominator that every framework can consume.

Web Components are also becoming the standard approach for micro-frontends — architectures where different teams own different parts of a frontend, potentially using different frameworks. By 2025, over 60% of enterprises are expected to adopt micro-frontend architectures, and Web Components are the interoperability layer that makes this practical.

But Web Components aren't a complete solution. They don't solve the performance problems of DOM-based rendering. They don't provide native reactivity. They don't enable true parallelism. They're a better version of the document web, not a new application runtime.

The Pattern Emerging

Looking across these developments, a clear pattern emerges:

For documents, the DOM remains appropriate. HTML, CSS, and traditional rendering work fine for articles, marketing sites, and content-heavy pages where SEO and accessibility are paramount.

For applications, the industry is systematically bypassing the DOM:

  • Rendering: Canvas (2D) or WebGL/WebGPU (GPU-accelerated) instead of DOM manipulation
  • Computation: WebAssembly instead of JavaScript for performance-critical code
  • State management: Reactive primitives (Signals) instead of manual DOM updates
  • Architecture: Component-based with explicit boundaries instead of global DOM soup

The question isn't whether this separation is happening. It's whether it will be standardised or whether every company will continue building its own version of "a browser inside a browser."

Critics Will Object

Three objections are worth addressing before going further.

"React + DOM scales fine with proper architecture." True for many applications. The DOM is sufficient for most CRUD interfaces, dashboards, marketing-adjacent products, and internal tools. The argument here is not that the DOM should disappear. It is that for a specific class of applications — real-time collaborative tools, design software, performance-critical interfaces, anything that approaches a workstation in feel — the abstraction tax is real and growing. Different problems need different tools. Saying "React is fine" inside a banking trading desk and inside a kanban board is not the same statement.

"Standardisation kills innovation. Let the market decide." The market has been deciding for fifteen years. The outcome is fragmentation: every major application building its own runtime in isolation, none of which compose. Standardisation wouldn't constrain Figma or Google Docs. It would lower the cost of being the next Figma or Google Docs. Standards don't kill innovation — they make it accessible.

"Figma is an exception, not a pattern." If it were Figma alone, perhaps. But Google Docs migrated to canvas. Flutter Web deprecated HTML rendering. Photoshop and Lightroom for web run on WebAssembly. AutoCAD runs in WebAssembly. Internal tools at banks and brokerages run on custom runtimes that never see public scrutiny. The exception argument doesn't survive contact with the list.

What's Still Missing

Despite all this progress, the application web remains a collection of workarounds rather than a coherent platform.

No standard component model for applications. Web Components provide encapsulation but lack lifecycle hooks, typed interfaces, and runtime guarantees that application components need. Every framework invents its own component model.

No standard communication protocol. Micro-frontends need to communicate, but there's no standard message bus. Teams resort to CustomEvents, postMessage, or global state — all fragile approaches that break when implementations change.

No native parallelism. JavaScript remains fundamentally single-threaded. Web Workers exist but require message passing and can't share memory safely without SharedArrayBuffer (which has complex security requirements). The main thread remains a bottleneck.

No composition standard. How should independently-developed components discover each other? How should they negotiate dependencies? How should they coordinate rendering? These questions have no standard answers.

Figma solved these problems for Figma. Google Docs solved them for Google Docs. Every large application solves them independently, differently, and incompatibly.

The Possible Future

Imagine a web platform that acknowledged the distinction between documents and applications at the runtime level.

For documents, everything stays the same. HTML, CSS, the DOM, SEO, accessibility — all working exactly as they do today.

For applications, a different runtime:

  • Components as first-class citizens: identity, lifecycle, typed interfaces, guaranteed isolation — not as framework optionals, but as platform primitives
  • Reactive state built in: change a value, observers update, no library required
  • Parallel by default: rendering and computation distributed across cores without developer intervention
  • Standard communication: a typed message bus for component interaction, with explicit contracts
  • Composition rules: how to declare, mount, communicate, and isolate — specified, not reinvented

A Mental Model

This isn't a blueprint — it's a visualisation of how these principles might fit together. Real implementations would differ in details while respecting the same architecture.

Application Runtime — mental modelThree application components, each owning its own isolated state, communicate through a typed native message bus. A parallel rendering engine distributes rendering across multiple threads.APPLICATION RUNTIMECOMPONENTASTATECOMPONENTBSTATECOMPONENTCSTATENATIVE MESSAGE BUStyped contractstwo parallel subsystemsPARALLEL RENDERING ENGINETHREAD 1THREAD 2THREAD 3THREAD 4

Each component owns its state. Communication happens through a typed message bus with explicit contracts — not CustomEvents or postMessage hacks. Rendering is distributed across threads by the runtime, not managed by the developer.

This isn't science fiction. Every piece of this exists today, scattered across frameworks, compiled into WebAssembly modules, or implemented behind proprietary APIs. The technology is proven. What's missing is standardisation.

Why This Matters

The cost of the current situation isn't obvious until you add it up:

  • Every framework reimplements reactivity. That's engineering effort duplicated thousands of times.
  • Every large company builds its own component communication system. That's infrastructure that could be shared.
  • Every application that needs performance bypasses the DOM differently. That's knowledge siloed inside organisations.
  • Every developer learns one framework's way of doing things, and that knowledge is non-transferable. That's career lock-in.

The web succeeded because it was open and standardised. A link works everywhere. An HTML page renders in any browser. That interoperability is the web's superpower.

But the application web isn't interoperable. A React component doesn't work in Vue. A Figma plugin can't run in Google Docs. The innovations happening inside these applications aren't accessible to the broader ecosystem.

Standardising the application runtime wouldn't constrain innovation — it would accelerate it. Frameworks could compete on ergonomics and tooling rather than reimplementing primitives. Components could be shared across ecosystems. The collective intelligence of the web development community could compound instead of fragment.

A Realistic Assessment

Will any of this happen? The honest answer is: slowly, partially, and with compromise.

Standards processes are slow. TC39 Signals has been in development for years and remains Stage 1. WebAssembly took a decade from concept to widespread adoption. Any new application runtime standard would face similar timelines.

Browser vendors have competing interests. Google, Apple, Mozilla, and Microsoft don't always agree, and any standard requires consensus.

The existing ecosystem has enormous inertia. Millions of applications depend on current approaches. Migration is expensive.

I don't have a clean answer for who drives this. W3C? WHATWG? A new consortium of application vendors? The honest position is that I don't know — and I think the people calling for standardisation (myself included) should be more transparent about not knowing. The point is not that the path is obvious. The point is that the technical pieces exist.

But the pressure is building. The companies building the most demanding applications have already voted with their code. They're not waiting for standards. They're building the application web themselves, proprietary and siloed.

The question is whether the open web will eventually provide what they need, or whether the application web will remain permanently fragmented — a collection of brilliant but incompatible solutions, each trapped inside its creator's ecosystem.

Conclusion

The two webs already exist. One is the document web — open, standardised, accessible, the web we've known for three decades. The other is the application web — powerful, performant, but fragmented and proprietary.

Figma, Google Docs, Flutter, and countless internal applications have demonstrated that the document web's limitations aren't acceptable for serious software. They've built something better, but they've built it alone.

The patterns are converging. Reactive state, canvas rendering, WebAssembly computation, component isolation — these aren't competing ideas. They're complementary pieces of a coherent vision that nobody has fully assembled.

The web development community has a choice. We can continue treating the application web as a series of clever hacks on top of document primitives. Or we can acknowledge that applications and documents are different things, and build accordingly.

The separation is already here. Whether it gets standardised is the only open question.

References

  • Figma Engineering Blog: "WebAssembly cut Figma's load time by 3x" (2017)
  • Figma Engineering Blog: "Building a professional design tool on the web" (2015)
  • Figma Engineering Blog: "Figma Rendering: Powered by WebGPU" (September 2025)
  • Google Workspace Updates: "Google Docs will now use canvas based rendering" (May 2021)
  • Flutter Documentation: "Web renderers" (2025)
  • TC39 Proposal: "Signals" (Stage 1, April 2024)
  • Servo Project — servo.org
  • Ian Hickson: "Towards a modern Web stack" (January 2023)
  • Communications of the ACM: "When Is WebAssembly Going to Get DOM Support?"
  • The New Stack: "Google Docs Switches to Canvas Rendering, Sidelining the DOM" (May 2022)
  • Igalia: "Servo: A new web engine written in Rust" (September 2025)
  • Lit Blog: "Bringing Signals to Lit Labs" (October 2024)
  • Alex Russell: "The Performance Inequality Gap" (infrequently.org)
  • Andy Wingo / Igalia: writings on the Extensible Web (2014→)