So you want to build a browser engine

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.