←back to thread

Show HN: Vaev – A browser engine built from scratch (It renders google.com)

(github.com)
233 points monax | 3 comments | 18 May 25 17:54 UTC | HN request time: 0.202s | source

We’ve been working on Vaev, a minimal web browser engine built from scratch. It supports HTML/XHTML, the CSS cascade, @page rules for pagination, and print-to-PDF rendering. It even handles calc(), var(), and percentage units—and yes, it renders Google.com (mostly).

This is an experimental project focused on learning and exploration. Networking is basic (http:// and file:// only), and grid layouts aren’t supported yet, but we’re making progress fast.

We’d love your thoughts and feedback.

Show context
khimaros ◴[18 May 25 20:30 UTC] No.44024102[source]▶
i find myself requesting this whenever i see a new minimalist browser pop up:

it would be great to standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that when building their websites and alternative browsers makers can target something useful without boiling the ocean

i personally prefer this approach to brand new protocols like Gemini, because it retains backward compatibility with popular browsers while offering an off ramp.

replies(7): >>44024337 #>>44024442 #>>44024575 #>>44024868 #>>44027725 #>>44036733 #>>44041548 #
1. graypegg ◴[18 May 25 21:11 UTC] No.44024337[source]▶
I think that would be really neat for small scale web publishing, but making it a subset of browser standards could be a really difficult sell to the people making browsers. While it's easier to build a browser to a subset of such a massive set of specs, the subset will drift towards a "similar but slightly incompatible standard" pretty soon after it's decided on. Following the development of Ladybird has given me an appreciation for just how often the "spec" for the web changes. (in small ways, daily.) That locks new browser implementations into a diverging standards track that would be very difficult to get off of.

I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too. "It's got to look good in Ladybird/Vaev/etc".

An idea: a web authoring tool built around libweb from Ladybird! (Or any other new web implementation that's easily embeddable) The implied standard-ness of whatever goes in that slot would just come for free. (Given enough people are using it!)

replies(2): >>44024480 #>>44024770 #
2. userbinator ◴[18 May 25 21:37 UTC] No.44024480[source]▶
small-web living standard

The phrase "living standard" is an oxymoron, invented by the incumbents who want to pretend they're supporting standards while weaponising constant change to keep themselves incumbent.

3. shiomiru ◴[18 May 25 22:29 UTC] No.44024770[source]▶
> I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too.

A "standard" should mean there is a clear goal to work towards to for authors and browser vendors. For example, if a browser implements CSS 2.1 (the last sanely defined CSS version), its vendor can say "we support CSS 2.1", authors who care enough can check their CSS using a validator, and users can report if a CSS 2.1 feature is implemented incorrectly.

With a living standard (e.g. HTML5), all you get is a closed circle of implementations which must add a feature before it is specified. Restricting the number of implementations to one and omitting the descriptive prose sounds even worse than the status quo.