So you want to build a browser engine

Original Article ↗ Hacker News Discussion ↗

Building a modern browser engine from scratch is portrayed as an immense, often impractical undertaking, rivaling or exceeding the complexity of OS kernels and compilers. Commenters highlight the huge security, compatibility, and performance burdens required to be competitive with Chrome, Safari, or Firefox, arguing that forking existing engines or targeting narrower use cases (like Electron/WebView replacements or embedded renderers) is far more realistic. Even so, some see value in “insane” greenfield efforts such as Ladybird or alternative rendering models, both for engine diversity and for experimenting with ideas that today’s web standards and dominant implementations make hard to explore.

Scope and Purpose of New Engines

  • Many see the article as a warning: building a Chromium‑class engine from scratch is enormous in cost and scope.
  • Others argue there’s a spectrum: from toy engines and niche embedded engines to full browsers; you don’t have to target “the whole web.”
  • Some think the post is implicitly a response to current clean‑room engine efforts, even if not named.

Security, Sandboxing, and Dependencies

  • Strong concern that an “Electron/WebView but lighter” engine still needs serious security: apps bundle huge JS dependency trees and interact with external services.
  • Even for embedded use, lower‑trust content (iframes, extensions) tends to appear eventually, so designing without isolation is seen as risky.
  • Memory‑safe languages don’t mitigate speculative‑execution attacks; process/site isolation is still argued to matter.

Complexity and Comparisons

  • Browsers are likened to multiple compilers plus OS: they handle parsing, optimization, GC, GPU pipelines, isolation, storage, and networking.
  • Some note: writing a compiler or OS kernel is relatively easy; making them competitive mirrors browser difficulty.

Feasibility and Who Should Build One

  • Strong skepticism: from-scratch engines are called “insane” or “nonsensical” in 2020s given existing open-source engines and massive catch‑up cost.
  • Counterpoint: a few independent projects exist; the post is seen as guidance for them and as educational material for understanding browsers.

Performance, JIT, and Spectre

  • One view: modern hardware reduces the need for ultra‑aggressive JIT optimization; UX may remain acceptable without it.
  • Reply: competitors can weaponize benchmarks; some use cases (e.g., emulators) still need JIT speed.
  • Disabling JIT might change the Spectre threat, but it’s unclear whether that meaningfully weakens the case for site isolation.

Standards, Compatibility, and “Modern‑Only” Web

  • Suggestion: implement only “modern HTML5/CSS3” to cut scope.
  • Pushback: these specs extend, not replace, older behavior; complexity (e.g., HTML5 parsing, CSS inline layout) remains.
  • Modern standards are praised for precision but criticized as huge, ever‑changing, and full of rarely used features.

Alternative Targets: Embedded / Electron Replacement

  • Several see value in engines aimed at a narrow, controlled content set: app UIs, Electron replacements, protocol‑specific or “toy but useful” engines.
  • Existing niche engines (e.g., for line‑of‑business apps) are cited as proof this space is viable.

Engine Diversity and Ecosystem Effects

  • Some advocate new engines primarily for experimentation: different approaches to selectors, layout, parsing, etc.
  • Others argue differences are minor compared to what specs force everyone to share; real innovation may require leaving web standards behind.
  • Concern: without significant user share, alternative engines have little leverage; dominant engines still dictate reality.

Escaping HTML/CSS and New Rendering Models

  • Ideas floated: engines based on vector‑graphics specs, Figma‑like models, or WebAssembly+WebGPU with site‑provided renderers.
  • This could enable radically different app/document models but would need new standards and answers for caching, ad blocking, and security.

Accessibility and Ethical Concerns

  • Some alternative graphics‑driven approaches lack accessibility trees, text selection, and zoom support.
  • This is criticized as morally problematic and, in some jurisdictions, legally non‑viable; “Flash‑like” canvases are viewed as a regression.