[HN Gopher] Show HN: Vaev - A browser engine built from scratch ...
___________________________________________________________________
Show HN: Vaev - A browser engine built from scratch (It renders
google.com)
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.
Author : monax
Score : 89 points
Date : 2025-05-18 17:54 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| abhisek wrote:
| What's the long term goal of this project beyond learning?
| Building a browser to support the modern web is a humongous work
| IMHO.
| monax wrote:
| The main goal is great support for static documents rendering
| as it's being used at the core of the paper-muncher [1] PDF
| rendering engine, meant to replace wkhtmltopdf at odoo. But we
| don't exclude general web browsing and JavaScript support at
| some point.
|
| [1] https://github.com/odoo/paper-muncher
| dmkolobov wrote:
| Ooh blast from the past!
|
| At a previous company we moved off of wkhtmltopdf to a nodejs
| service which received static html and rendered it to pdf
| using phantomjs. These days you probably use puppeteer.
|
| The trick was keeping the page context open to avoid chrome
| startup costs and recreating `page`. The node service would
| initialize a page object once with a script inside which
| would communicate with the server via a named Linux pipe.
| Then, for each request:
|
| 1. node service sends the static html to the page over the
| pipe
|
| 2. the page script receives the html from the pipe, inserts
| it into the DOM, and sends an "ack" back over the pipe
|
| 3. the node service receives the "ack" and calls the pdf
| rendering method on the page.
|
| I don't remember why we chose the pipe method: I'm sure
| there's a better way to pass data to headless contexts these
| days.
|
| The whole thing was super fast(~20ms) compared to WK, which
| took at least 30 seconds for us, and would more often than
| not just time out.
| sshine wrote:
| Sounds like fun considering how real the problem is.
| Teever wrote:
| So cool to see Odoo mentioned on HN. I've worked with it
| before and like it a lot.
|
| I've made posts about it on HN before but they've never
| gained traction. I hope that this takes off.
|
| You guys make neat software.
| pierrelf wrote:
| Looks like skift is a hobby os like Serenity OS which Ladybird
| is spun out from. Maybe they intend to follow the same path?
| monax wrote:
| I intend to keep Skift and Vaev together for as long as
| possible since everything is meant to be cross-platform. I
| don't see any architectural conflict that would motivate such
| a change.
| busymom0 wrote:
| I wish one of these projects would make a browser which only
| renders text (so texts and links) and no additional support for
| media (images, videos, audio etc).
|
| I know there is Lynx but having a non-terminal based browser
| which could do it would be cool.
| monax wrote:
| For distraction-free reading?
| dymk wrote:
| Something like Reader View in safari / firefox?
| tos1 wrote:
| Something like Dillo? (You can disable image rendering in
| Dillo).
| revskill wrote:
| Then google will use text to show ads.
| busymom0 wrote:
| Text based ads would be less distracting.
| II2II wrote:
| _Remembering when Google only served text based ads._
| Telemakhos wrote:
| You might be interested in Richard Stallman's method of
| browsing the web:
|
| > I generally do not connect to web sites from my own machine,
| aside from a few sites I have some special relationship with. I
| usually fetch web pages from other sites by sending mail to a
| program (see https://git.savannah.gnu.org/git/womb/hacks.git)
| that fetches them, much like wget, and then mails them back to
| me. Then I look at them using a web browser, unless it is easy
| to see the text in the HTML page directly. I usually try lynx
| first, then a graphical browser if the page needs it. [0]
|
| I know you wanted something other than lynx, but you could do
| this with EWW (Emacs web browser or any graphical browser,
| provided that your proxy wget dropped the images.
|
| [0] https://www.stallman.org/stallman-computing.html
| Hashex129542 wrote:
| Cool idea!
| khimaros wrote:
| 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.
| graypegg wrote:
| 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!)
| userbinator wrote:
| _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.
| shiomiru wrote:
| > 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.
| userbinator wrote:
| The subset could just be an older version of the spec, e.g.
| HTML 4.01 and CSS 2.1.
|
| (My opinion as another one who has been slowly working on my
| own browser engine.)
| ghayes wrote:
| I feel like some of the newer standards like CSS Grid instead
| of tables might be the best way to go. Many HTML/CSS
| improvements were not just bloat but actually better
| standards to build on.
| edoceo wrote:
| Right! Crazy fonts or cursors, not on smolweb (as another
| use put it) but Flex and Grid are almost necessary. There
| are loads of things that could be dropped (it feels like).
|
| I just want one of these browsers to give me a proper
| ComboBox (text, search and drop-down thing)
| poisonborz wrote:
| That's easy to specify but contains a lot of bloat and unused
| features. A slimmer but more modern set would be useful.
| 5- wrote:
| > slowly working on my own browser engine
|
| care to tell us more?
| robocat wrote:
| Pick a subset aimed directly at accessibility.
|
| The least-needed features are often accessibility nightmares
| (e.g. animation - although usually not semantic).
|
| The accessible subset could then be standardized and used as
| a hammer against over-complex HTML sites.
|
| For a while search engines helped because they encouraged
| sites to focus on being more informative (html DOCUMENTS).
|
| I think web applications are a huge improvement over Windows
| applications, however dynamic HTML is a nightmare. Old school
| forms were usable.
|
| Disclosure: wrote a js framework and SPA mid 00's (so I've
| been more on the problem side than the solution side).
| enos_feedler wrote:
| You mean AMP without the BS
| idle_zealot wrote:
| > standardize alternative browsers on a consistent subset of
| web standards and document them so that "smolweb" enthusiasts
| can target that
|
| Could such a standard be based on the subset of HTML/CSS
| acceptable in emails? Maybe with a few extra things for
| interactivity.
| quibono wrote:
| Are you open to contributions? I would love if there was a non-
| chromium alternative to wkhtmltopdf!
| 5- wrote:
| like https://www.princexml.com/ ?
| edoceo wrote:
| Yea, Prince is awesome. Not FOSS tho. I make some GPL or MIT
| licensed software and wish there was something as good a
| Prince with more open license.
___________________________________________________________________
(page generated 2025-05-18 23:00 UTC)