If anyone is interested in a modern take on a lightweight, embeddable web browser / browser engine (that supports features like Flexbox, CSS Grid, CSS variables, media queries, etc), then I'm building one over at https://github.com/DioxusLabs/blitz

Feature support matrix is here: https://blitz.is/status/css

This month I have been working on support for CSS floats (https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...) (not yet merged to main), which turn out to still be important for rendering much of the modern web including wikipedia, github, and (old) reddit.

EDIT: I should mention, in case anyone is interested in helping to build a browser engine, additional collaborators / contributors would very welcome!

▲

bryanlarsen 13 hours ago | parent | next [-]

Mentioning your usage of servo components might help with credibility. You're not starting from scratch.

Edit: to be clear, I consider this a good thing. You've got a head start, are contributing to the ecosystem and aren't doing by yourself something that others have spent billions on.

	▲	nicoburns 12 hours ago \| parent [-]
		Yes, we've deliberately tried to make use of existing libraries (either from other browser engines or general purpose libraries) where possible. The main thing we pull in from Servo (which is also shared with Firefox) is the Stylo CSS engine, which is a really fantastic piece of software (although underdocumented - a situtation I am trying to improve). I was recently able to add support for CSS transitions and animations to Blitz in ~2 days because Stylo supports most of the functionality out of the box. (the other smaller thing we use from servo is html5ever: the html5/xhtml parser) We also rely on large parts of the general Rust crate ecosystem: wgpu/vello for rendering (although we now have an abstraction and have added additional Skia and CPU backends), winit for windowing/input, reqwest/hyper/tokio for HTTP, icu4x for unicode, fontations/harfrust for low-level font operations, etc. And while we're building the layout engine ourselves, we're building it as two independently usable libraries: Taffy for box-level layout (development mostly driven by Blitz but used by Zed and Bevy amongst others), and Parley for text/inline-level layout (a joint effort with the Linebender open source collective). --- I wish that the Servo project of 2025 was interested in making more of their components available as independent libraries though. Almost all of the independently usable libraries were split out when it was still a Mozilla project. And efforts I have made to try and get Servo developers to collaborate on shared layout/text/font modules have been in vain.

▲

leshokunin 13 hours ago | parent | prev | next [-]

Took me a sec to understand you didn’t mean you’re adding support for numbers with a comma :)

▲

cyanmagenta 13 hours ago | parent [-]

Took me a sec to understand you meant comma as “decimal point” :)

	▲	a96 an hour ago \| parent \| next [-]
		It's unfortunate that a lot of countries (including mine) have decided to officially use a list separator as a decimal point.
	▲	leshokunin 12 hours ago \| parent \| prev [-]
		Hahaha fair point!

▲

koolala 8 hours ago | parent | prev | next [-]

Could this run in Wasm? Even if it was just running it 'headless'? I'm looking something like this to manage layout / animations of text like the DOM to plug into WebGL.

	▲	nicoburns 6 hours ago \| parent [-]
		Yes. It currently compiles to WASM but doesn't run. But that's just a matter of plumbing it in properly. If you were running it "headless" (which is supported), then it would probably work today. There would also be the option of using Taffy and/or Parley (the layout libraries) without the rest of Blitz.

▲

maxloh 13 hours ago | parent | prev [-]

What JavaScript engine are you using/planning to use? I did a quick search on GitHub and found no results.

	▲	nicoburns 13 hours ago \| parent [-]
		That's a bit of an open question at the moment. The obvious choice from a Rust ecosystem perspective (easiest to integrate) would be Boa (https://boajs.dev/). It has excellent standards conformance, but terrible performance. We'd need to test to what extent that would be an issue in practice. Other engines on my radar: quickjs, hermes, primjs (and of course V8/JSC/SM, but they don't exactly fit with the "lightweight ethos"). There is also the possibility of bindings with more than one engine and/or using some kind of abstraction like NAPI or JSI.