The web browser landscape has long been dominated by a handful of major players, making any new entrant noteworthy. Vaev, a self-described lightning-fast, lightweight, and secure HTML/CSS engine, has recently emerged and sparked significant discussion within the developer community about the future of browser technology, security considerations, and the viability of alternative approaches to web rendering.
The Vaev Project and Its Purpose
Vaev is being developed by a team of four contributors and currently supports a subset of web standards including most display types (excluding grid), standard CSS cascade behavior, pagination using @page rules, print-to-PDF output, and various CSS units including percentages, var(), and calc(). While its networking capabilities are currently limited to HTTP and file protocols, the project represents an ambitious attempt to create a new browser engine from scratch.
One of the project's main developers revealed that Vaev has a specific practical application beyond being a learning exercise. It's being developed to serve as the core of paper-muncher, a PDF rendering engine intended to replace wkhtmltopdf at Odoo, a popular open-source business software suite. This focused use case helps explain the project's emphasis on print-to-PDF capabilities and pagination features.
Vaev's Current Feature Support:
- Most display types (excluding grid)
- Standard CSS cascade behavior
- Pagination using @page rules
- Print-to-PDF output
- All CSS units, including percentages, var(), and calc()
- Loading of HTML and XHTML documents
- Basic networking (http:// and file:// only)
Project Contributors:
- Lou!
- LuneMercier
- Paulo Medeiros
- Sleepy Monax
Primary Use Case:
- Core of "paper-muncher" PDF rendering engine
- Intended to replace wkhtmltopdf at Odoo
Language Choice Controversy
Perhaps the most heated discussion surrounding Vaev concerns its implementation in C++. Many commenters questioned this choice, arguing that browsers are essentially RCE vulnerabilities by design and that C++ has historically been the source of numerous security issues in browser codebases.
I'm interested in why C++ was chosen for this? Browsers are notoriously hard to secure, they're effectively meant to be RCE vulnerabilities! Securing C++ binaries is hard and has in recent years been called out by numerous organisations and companies as being the root cause of many classes of security vulnerability.
Defenders of the choice pointed out that the developers likely have extensive C++ experience, and that writing a browser engine requires deep language proficiency. Some also noted that the codebase demonstrates high-quality modern C++ practices, with smart pointers and RAII patterns that can mitigate many traditional C++ security concerns.
The Vaev team has responded to security concerns by noting that they're exploring compiler-enforced safety features in Clang, including lifetime checking attributes and restricted pointer usage outside designated blocks - approaches that provide some of the safety benefits found in languages like Rust.
The Smolweb Discussion
Vaev's arrival has reignited a recurring conversation about standardizing a minimal subset of web technologies. Many developers expressed interest in defining a smolweb standard - a consistent, limited subset of web standards that alternative browsers could implement without boiling the ocean of full web compatibility.
Suggestions for this hypothetical standard ranged from adopting older specifications like HTML 4.01 and CSS 2.1 to focusing on modern but essential features like CSS Grid while eliminating unnecessary complexity. Some proposed using email HTML compatibility as a baseline, while others suggested starting with the minimal requirements needed for Markdown rendering.
This discussion highlights a growing desire for simpler, more focused web technologies that could enable greater browser diversity without requiring the enormous engineering resources currently needed to compete with dominant browsers.
Challenges and Future Prospects
Building a new browser engine is an extraordinarily complex undertaking, with many commenters noting that browsers have effectively become operating systems in their own right. The sheer volume of code required for even basic functionality (with Vaev already containing numerous files of 500+ lines) demonstrates why so few new browser engines emerge.
While Vaev's immediate future seems focused on document rendering and PDF generation rather than general web browsing, the developers haven't ruled out eventually supporting JavaScript and more comprehensive web features. The project's architecture is designed to be cross-platform from the start, unlike some other alternative browser projects that began as operating system-specific implementations.
As web technologies continue to grow more complex, projects like Vaev provide valuable exploration of alternative approaches and specialized use cases. Whether focusing on document rendering, minimal web standards, or security improvements, these experiments contribute to the broader conversation about the future direction of web technologies and browser diversity.
Reference: skift-org/vaev