For example:
- Servo vs Blink vs Cobalt do selector matching and style resolution very differently.
- WebKit has a selector JIT, no one else does though.
- WebKit and Blink do layout super differently (with LayoutNG shipped).
- Firefox's html parser is written in Java and converted to C++ at build time.
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.
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.
If you wanted to innovate in browser tech you'd really need to leave the specs behind. SCIter is an example of such an engine. It exposes APIs that are useful for app devs but that regular browsers don't have, for example it provides the vdom diffing algorithm React uses but implemented natively.
Even better if your browser can go beyond HTML and enable fully different ways to do apps and documents. That's the only place where design decisions can start to have a big impact.
This is pretty much what the author is suggesting by the end the article: "Instead of being a Web browser, you might want to initially try just being a faster, lighter or lower-power Electron or WebView. Then the Web compatibility barrier would be much less of an issue."
This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?
"Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies.
On the article itself; it might be better to start with more... basic things than the optimizations it talks about:
* 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.
* 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.
* "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.
* 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.
* 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.
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.
[0]: To write a Chromium replacement, you may have to reincarnate as awesomekling ;)
One idea that’s crossed my mind (may never get around to trying it) is writing an engine that completely ignores everything that’s not modern HTML5 and CSS3. That’s still a lot but it seems like it’d cut down on the scope significantly. This engine wouldn’t be very useful as a browser but it’d probably be enough for displaying bespoke web content in an app or something like that.
So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized.
Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features.
In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web.
[1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.
Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?
Just try disabling the JIT in a modern browser and you’ll find your UX is not really any worse.
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.
And if you don’t have JIT, then it’s not clear if Spectre is even a meaningful concern.
It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users.
And of course there's a lot more to perf than just the JIT. I barely mentioned JIT in my blog post.
Those are so niche as a concern, that might as well not take into account at all when doing a new browser engine.
And without Spectre, the argument for site isolation is much weaker.
It manages memory, processes and security, it can run user-supplied arbitrary code. It has an API, not unlike system calls that allows programs to access the underlying hardware. It doesn't do thing like writing on the address bus directly, but it does have the equivalent of drivers that are proxies to the underlying OS services for display, audio, video, etc..., which it abstracts away. Like many OSes it comes with a compiler and a shell.
Sure, it doesn't access the hardware directly through the address and data buses, like one may think an OS should do, but now that we have stuff like hypervisors, even what are unquestionably true OSes like Windows and Linux may not access the hardware directly either.
I'm joking. Maybe. Probably. It seems like we've come full circle with MS-DOS and Windows 3 in the 90s.
Indeed. The modern web browser is the single most advanced, complex, and highly developed piece of software that 99% of people will ever interact with, and we treat it as a given. Having a highly performant fully sandboxed VM that runs on every system imaginable in billions of devices used by nearly every human on earth is the single greatest triumph of software engineering ever, perhaps only second to the Linux kernel.
Roughly 60% of earth's population used the internet in 2023. So not quite nearly every human.
We do not typically call TeX a "compiler". We don't consider XSLT engines to be "compilers". dot(1) is not normally considered to be a "compiler". And so on.
An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1].
[1] https://verygoodgraphics.com/, the website is built with its own technology (wasm version).
We escaped Flash. We shouldn't clamor to go back.
Could still have typical DOM rendering handled with Webassembly delivered by the web sites (ideally cached). The challenge is though still having standards and accessibility options. That VeryGoodGraphics example allows for no text selection - and doesn't at all handle zooming. Still though it'd be a good bottom up way for a new browser to disrupt Chrome
It's been on HN loads of times.
A "browser" engine but very narrow scope. Works a treat for LOB type apps.
There are lots of browser engines like that still around. It'd be really interesting to see one that supports the vast majority of web standards but without trying to do everything else a full browser does.
That wasn't because they weren't up to the job. It's because Google was using Microsoft's playbook against them. https://news.ycombinator.com/item?id=18697824
> I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.
(While this may seem like poetic justice, Google's also been doing this against everyone else, so we shouldn't cheer. Also, unlike when Microsoft pulled these stunts, this might not even be deliberate on the part of the Google webdevs.)
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.
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.
Really being competitive with Chrome is not enough because that still doesn't give anyone any reason to use your browser over Chrome. You need to actually provide some end-user benifit that Chrome doesn't (and ideally won't) and that is more important than being competitiv with Chrome on the features Google wants to push. This is where Mozilla really dropped the ball. 15 years of Chrome lighting fire under their ass and zero innovation in the way we browse the web. Well, less than zero when you consider all the useful extension broken by browser changes over the years.
Meanwhile Mozilla keeps gaslighting us how they care about privacy while trying numerous ways to integrate ads in the browser.
... yeah I see why someone would rather create a browser from scratch than support Mozilla.
> initially try just being a faster, lighter or lower-power Electron or WebView.
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?
The average Node project pulls in hundreds of dependencies. While you'd hope these would have some security vetting because of the Many Eyes theory, you have no fucking idea what your project is doing. Even a trivial Electron app is running a ridiculous amount of unreviewed third party code.
Just one module able to exercise some local exploit in your engine because you didn't fix Security Footgun #8176 screws over all of your users.
A browser engine that's been developed with a billion dollars of person hours runs that same untrusted third party code but has security guardrails everywhere.
With the interactions an electron-like app might be doing with external services and the ton of JS third party library it could use, I think it would be indeed risky.
This would be more like Servo which I believe is focusing on embedded use cases. It makes sense because for Electron/embedded you don't need it to work for every site (really really hard), you only need it to work for one site. (Or a few hundred/thousand if you count all your users.) That is several orders of magnitude easier.
Nobody builds their own browser engines. And I mean nobody. I didn’t get the feeling that he wrote this for pet projects either.
Andreas over at Ladybird is probably the only one (and Servo?) who is really doing it the way that this post describes.
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.
One such project has pretty regular HN chonkthreads, including last week.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
You have to watch some of his YouTube videos to appreciate the insanity that goes into getting things to work, but he at least has some help from the OSS community: building automated tests, scripts, etc.
As I was reading the post I thought he would at least shout him out too!
Anymore.
There's a fair number of other engines though like Sciter, Flow, Cobalt and Servo.
> [bunch of things that are only relevant to an application platform]
Yeah you really don't need any of this for a web browser to be usable for its intended purpose.
But it would be riddled with security issues.
The only correct answer is, "don't".
I mean, if you want to build a toy browser engine for a CS class or fun or something, then sure.
But the idea that "you want to build an engine that’s competitive with Chromium" is, quite simply, nonsensical.
If you want your own browser engine, you're going to fork Chromium or Gecko (Firefox). I mean, even Microsoft gave up on maintaining its own independent engine and switched to Chromium.
I literally don't understand who the author thinks this post is supposed to be addressed to.
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 two open-source versions of?
We're collectively getting better via following the same spec, which is great, but challenging the browsers and even the spec can shed light on potentially better implementations. Let's not pigeonhole ourselves to a couple vendors just because it's easier and works _good enough_.
My favorite web design is that '90s style where text went from very left to very right, barely any CSS, and Javascript (somehow my favorite language) was for fart buttons.
I'm currently most excited about keeping up with WebRTC. And yeah, I have no interest in writing a new browser engine.
This article appears to be entirely about an implementation from scratch.
It makes very clear that it is not about forking Chromium.
But even Google was smart enough not to start from scratch.
So again, I don't know who the intended audience for this article is. It's advice on something no sane person or organization would ever do.
