Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible.<p>For example:<p>- Servo vs Blink vs Cobalt do selector matching and style resolution very differently.<p>- WebKit has a selector JIT, no one else does though.<p>- WebKit and Blink do layout super differently (with LayoutNG shipped).<p>- Firefox's html parser is written in Java and converted to C++ at build time.<p>The big value in folks trying to write new engines is finding these alternate paths. We can't depend on the big three for all the innovation.<p>That's what's great about Ladybird. Sure it'll need a lot of sophisticated sandbox improvements to get us to a big four situation, but it's more likely its value will be in finding another road the other engines didn't travel across the huge universe of specs, content and features.
I'm writing one for fun: <a href="https://sr.ht/~bptato/chawan/" rel="nofollow">https://sr.ht/~bptato/chawan/</a><p>"Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies.<p>On the article itself; it might be better to start with more... basic things than the optimizations it talks about:<p>* Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is another level... and I'm just talking caching, not even multi-threading.<p>* The "web platform" contains a very large amount of poorly thought out features harmful for user privacy and/or security. You can choose between convenience (opt out) and privacy (opt in), or try to balance the two as major browsers do. Both is often impossible.<p>* "Serialize the entire application state" sounds like the most complex thing you can come up with as a distinguishing feature. Much more low hanging fruit exists if you give up on writing a Chromium clone. e.g. a fun side project I've had is making my browser "protocol-agnostic", or adding a bunch small QOL stuff for myself. You can probably find new ideas easily once you start out.<p>* Older browsers are useful for inspiration too. The coolest features in mine are often just carbon copies of the same things from w3m, just a bit more polished. Reading about what historical engines did - even IE! - is often enlightening too. Sometimes it's just a smaller scale of what engines do now, and easier to implement. Other times it's a whole different approach.<p>* It's easy to get lost in the details - careful with perfectionism. As you start getting more components interacting, it will slowly become clear when the naive approach is wrong and how to improve it.<p>Overall, it takes time, but is also fun and rewarding - you will learn a lot, even without replacing Chromium.[0] That said, if you want to learn how "modern" browsers work, getting involved with a "modern" engine itself is probably much more productive.<p>[0]: To write a Chromium replacement, you may have to reincarnate as awesomekling ;)
I’m not sure that performance needs to constrain web engine design the way it traditionally has. The world has changed since the browser perf war started.<p>Just try disabling the JIT in a modern browser and you’ll find your UX is not really any worse.<p>HW has gotten faster than when the current browser perf wars kicked off. So it might be that to have a meaningfully useful browser engine alternative, perf won’t be the top concern. Compatibility will though, just because of the sheer number of features a modern browser engine supports.<p>And if you don’t have JIT, then it’s not clear if Spectre is even a meaningful concern.
Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs?<p>An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1].<p>[1] <a href="https://verygoodgraphics.com/" rel="nofollow">https://verygoodgraphics.com/</a>, the website is built with its own technology (wasm version).<p>[2] <a href="https://docs.verygoodgraphics.com/specs/overview" rel="nofollow">https://docs.verygoodgraphics.com/specs/overview</a><p>[3] <a href="https://github.com/verygoodgraphics/vgg_runtime">https://github.com/verygoodgraphics/vgg_runtime</a>
Seems a good place to mention <a href="https://sciter.com/" rel="nofollow">https://sciter.com/</a><p>It's been on HN loads of times.<p>A "browser" engine but very narrow scope. Works a treat for LOB type apps.
This post starts with a false dichotomy: You're either making a toy browser for fun, or you're trying to make the next Chrome. There are many points in-between on that spectrum. (Look how long Microsoft IE existed, despite being highly inferior.)
If you actually want to build one I cannot recommend <a href="https://browser.engineering/" rel="nofollow">https://browser.engineering/</a> enough.
I've wanted to make my own browser by forking chromium. But then I got confronted with the reality of hacking on a Google scale c++ project.<p>I've tried doing it by embedding webkit which is much more doable but I've found that many sites I use don't work my embedded webkit.<p>So now I think if I want to make my own browser it would be better start making my own versions of those sites first and make sure those are good and popular. At which point I'll just make native clients for them and forget about html/js/css.
interesting how oldpersonintx's comment "thinly-veiled passive-aggressive swipe at Ladybird" was dead'd here when that accurately reflects the authors comments (as roc-robert o'callahan) here on LWN.net: <a href="https://lwn.net/Articles/977625/" rel="nofollow">https://lwn.net/Articles/977625/</a>
I was going to suggest:<p>> initially try just being a faster, lighter or lower-power Electron or WebView.<p>But he mentioned it himself, though maybe someone might want to try this with no intention to become a full browser. Can you skip any of the tricky security requirements if it'll be bundled into an app? Or is that just asking for trouble?
How important is process separation if the browser engine is programmed with a memory safe language like Rust? I am under the impression that things like site separation are to bandage memory safety issues. Is that right, or are there other issues at play?
Who is this post intended for?<p>Nobody builds their own browser engines. And I mean nobody. I didn’t get the feeling that he wrote this for pet projects either.<p>Andreas over at Ladybird is probably the only one (and Servo?) who is really doing it the way that this post describes.<p>Still, the last couple of paragraphs made me think that this is more of a reflection of his own time over at Mozilla: could have / would have.
> So You Want To Build A Browser Engine<p>> [bunch of things that are only relevant to an application platform]<p>Yeah you really don't need any of this for a <i>web browser</i> to be usable for its intended purpose.
> <i>So You Want To Build A Browser Engine</i><p>The only correct answer is, "don't".<p>I mean, if you want to build a toy browser engine for a CS class or fun or something, then sure.<p>But the idea that "you want to build an engine that’s competitive with Chromium" is, quite simply, nonsensical.<p>If you want your own browser engine, you're going to fork Chromium or Gecko (Firefox). I mean, even <i>Microsoft</i> gave up on maintaining its own independent engine and switched to Chromium.<p>I literally don't understand who the author thinks this post is supposed to be addressed to.<p>Building an independent browser engine could have made sense in 1998. These days it would cost hundreds of millions of dollars in dev time to catch up to existing engines... just to duplicate something that you already have <i>two</i> open-source versions of?