Bez: Generating a browser engine from specs and tests

📝 Discussion Summary (Click to expand)

Summary of prevalent themes

Desire for fully programmable browsers and the potential to displace Chromium/Blink
fouc: "I'm looking forward to the day when we have fully functioning web browsers that we have full programmatic control over in all aspects."
Tade0: "I'm afraid internally they would still look like chromium/blink anyway."
Prospect of generating browsers from web specifications, possibly with AI/LLM assistance
Alacart: "In theory we should be able to generate a browser from those specs, it just took a massive amount of effort before."
Alacart: "Maybe if things like this get some traction, some of the human time spent implementing the spec could be spent on creating more/better specs, allowing for even better generation too."
Significant obstacles: specs not machine‑readable, current AI limitations, and performance/security complexity
troupo: "No, not really. The absolute vast majority of those specs are human technical and technical-adjacent language, not machine-readable specs."
nicoburns: "They'll give you something that passes the tests, but it will do it a ridiculous way be far too slow to be useful (and is wrong architecturally such that it's not going to converge on a better solution)."
wslh: "I think browser performance (and security) improvements are really difficult to tackle at the scale of browser complexity, and are both art and engineering."

🚀 Project Ideas

Transforms machine‑readable web specs (WebIDL, JSON schema) into a minimal, embeddable browser engine written in Rust.
Core value: eliminates manual re‑implementation of standards, letting teams generate standards‑compliant rendering cores on demand.

Key	Value
Target Audience	Browser engine researchers, embedded‑device vendors, open‑source projects wanting a lightweight runtime
Core Feature	Spec‑driven codegen that outputs HTML/CSS parser, layout tree builder, and DOM APIs, pluggable with QuickJS or WASM‑based JS engine
Tech Stack	Rust, procedural macros, webidl‑rs, cssparser, tree‑sitter, optional WASM, CLI built with clap
Difficulty	High
Monetization	Revenue‑ready: SaaS build service (pay per generated engine) + optional enterprise support license

HN commenters expressed frustration that specs are not machine‑readable and that building a browser from scratch is a massive effort (Alacart, Tade0, troupo). This tool directly addresses that pain.
Enables rapid experimentation with new layout algorithms or spec features, fostering discussion about spec evolution and reducing duplicated engineering effort.

Provides a cloud‑hosted, fully controllable browser instance via an extended DevTools‑like API that lets users swap layout modules, inject custom paint worklets, and hook into spec‑compliance callbacks.
Core value: gives developers the programmatic browser control they crave without needing to maintain a fork of Chromium.

Key	Value
Target Audience	Web‑app developers, QA automation engineers, framework authors building hybrid native/web apps
Core Feature	API to replace/layout‑engine components, run custom rendering pipelines, and receive granular events (layout, paint, script execution)
Tech Stack	Node.js backend, Chromium headless via Puppeteer‑core, WebAssembly plugins, gRPC for API, Docker‑isolated sandboxes
Difficulty	Medium
Monetization	Revenue‑ready: subscription tier based on concurrent instances (e.g., $0.05/min per instance)

Users like fouc and Alacart longed for “full programmatic control over all aspects” of a browser; this service delivers that via API rather than requiring a custom build.
Enables novel use‑cases such as A/B testing layout engines, prototyping new web features, or creating thin native wrappers with web UI—topics frequently mentioned in the thread.

VS Code extension that analyzes browser engine source (Servo, Blitz, Chromium) and uses an LLM to suggest performance, security, and spec‑compliance improvements.
Core value: accelerates the optimization loop for engine contributors who feel AI today can’t write good engines but can help improve them.

Key	Value
Target Audience	Browser engine maintainers, open‑source contributors, performance‑focused developers
Core Feature	Real‑time suggestions for layout bottlenecks, redundant style recalcs, and unsafe DOM patterns, with one‑click patch generation
Tech Stack	Python/LLM (Llama 3 or CodeLlama), Language Server Protocol, Rust‑analyzer integration, optional WASM sandbox for testing suggestions
Difficulty	Medium
Monetization	Hobby (open‑source) – can be extended with paid private‑repo tier for enterprise teams

nicoburns noted that current AIs generate “ridiculously slow” and architecturally unsound engine code; RenderBoost sidesteps that by focusing on optimization rather than code generation.
Provides tangible value for the community discussing AI limits, turning LLM hype into practical engineering assistance while inviting discussion on AI‑assisted performance tuning.