I'm a fan of Andreas and love seeing the progress here, but let's be fair: it didn't take Mozilla 25 years to write a HTML engine. It took Netscape 3 years to build the world's best (at the time) browser from scratch ('94 to '97).

Chromium's HTML engine derives from an open source KHTML engine, written for the KDE project.

Not trying to diminish this impressive work from Andrew, but I would believe as the saying says those last (ongoing since a browser is never finished) 20% is what take 80% of the time to make a browser.

I'm actually pretty impressed with the Chromium source code. For such a huge, old and complex project, I think it is rather impressive. It's a lot better than the Linux kernel for example, another project of similar size/age/complexity.

I think a significant factor in this is that C++ simply has better abstractions for building large codebases than C does. Any big enough C project is gonna turn out a bit funky.

For quite a long time now I have said that the future for the Linux kernel could easily be C++ rather than rust.

Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.

> C++ would prevent so many bugs

https://chromereleases.googleblog.com/search/label/Stable%20... and control-f for "High CVE"

This from the company with arguably the best security researchers on Earth, and probably unholy amounts of internal fuzzing and static analysis tooling

Note that the baseline is C not C++ used badly.

Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. We made a couple of significant changes in years 4-6 right before Firefox launched, but Gecko was basically "there" about 4 years after Mozilla transitioned from the old Communicator engine to Gecko/NGLayout/Raptor/Magellen.

Having said that, Gecko wasn't a Netscape start from scratch effort. They acquired and built on a very simple and modular cross platform rendering engine that was used for the preview function in an HTML authoring product called WebSuite by Digital Style out of San Diego. (This is where Netscape got engineers Rick Gessner, Peter Linss, and manager Jim Hammerly.)

So, maybe if you count the WebSuite and the Netscape efforts both, you get something like 5-6 years of effort to get Gecko up to sufficient capability to compete in the market. That's a far cry from "it took Mozilla 25 years" though.

And yes, the Web is much more capable today, which makes building a rendering engine more difficult for sure, but the 25 year comment seemed wrong enough to me that I thought I'd share some of what I know as a Mozilla participant for the last 25 years (and a full-time Netscape/Mozilla employee for the last 22.5 years.)

This is not in any way meant to take away from the efforts of any new engine devs or teams. I'm amazed that anyone is even trying given how large the platform has become and have great respect for those trying and succeeding.

> Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years.

Yes, but web standards were at least an order of magnitude simpler back then.

How to build a browser is also a much more solved problem now.

I noted that in the later sentences of my comment. Yes, the platform is larger. But in some cases, it's also more sensible now that standardization has had 20 years to work it over. When Gecko was being developed, it was half implementing standards and half reverse engineering Microsoft's undocumented web APIs. Still, I'm sure it's nevertheless harder today and that's why I said so near the end of my comment.

Not really - there are certainly more of them, but - and this is extremely important - Mozilla, Apple, Google, and even MS spent the best part of a decade essentially rewriting the specifications that made up the web platform.

The DOM, etc through the work that eventually got labeled HTML5 made it possible to follow the spec and, as a super simple and "obvious" example, parse URLs in a way that worked. The existing specs of the era were often incomplete, semi-frequently what they did say did not match how browsers actually worked, and frequently ambiguous which meant that implementing anything required exhaustively testing what everyone else did to try and match it.

TC39 eventually recognized that the same issues existed in the ECMAScript spec, and recognized that ES4 did nothing to resolve those issues, while adding considerable complexity and more of the same issues. That's how we ended up with ES3.1 - it was an attempt to actually correctly and completely specify the language and runtime, ES5 continued/finished that catchup (ES3.1 did not resolve all the issues) while adding a few important features, but was still in the "make it possible for someone to implement the spec and be confident that they could run anything any other engine could run".

So in the modern browser there are many more specs, but those specs are much easier to confidently implement as you can get basic working behaviour by essentially translating the spec language into your environment.

Making the resulting engine fast, memory efficient, etc is of course another thing entirely (although even that is aided by removing ambiguity in the specs as the lack of ambiguity means that you can actually write tests now).

> And Google's Chromium is simply a convoluted mess, chockful with vulnerabilities and memory corruption errors.

I'm sorry, but Ladybird is written in C++. Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.

> Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.

Is it though?

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities.

If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

I think you should take it easy with the rust kool-aid. Not that black and white in reality.

And in reality, it is really going great for C++ based browsers and their engines like Chromium, and WebKit with all their static analyzers, address sanitizers, valgrind, etc have got their memory corruption CVE woes sorted /s

As Ladybird gets more complex, it will most certainly have memory corruption vulnerabilities, just like the other browsers and it will turn out to be no different.

You're really just dogmatic making assertions. I don't really see much backing these assertions up. Making them more firmly isn't making your case more convincing.

--

Let me make a silly argument. Let's say you write a program in rust, a sort of elaborate turing tape that interprets C++ code and evaluates it as a C++ program according to all standards and rules. To the end user it is indistinguishable from a C++ interpreter, but between the C++ code and the system is a layer of rust.

According to standard rustacean dogma, this program will simultaneously be guaranteed to be memory safe because it is rust, and inevitably have memory corruption bugs because it is C++. This is surely a contradiction. It cannot both be incorrect and correct at the same time.

I'm not agreeing with rvz, but I don't think even extremely pro-Rust devs would agree with what you just claimed

No it isn't. I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII.

Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.

> No it isn't.

It is.

> I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII.

Firefox is still in C++ and is still subject to memory corruption vulnerabilities, proving my point again.

> Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.

"almost flawless" is still in the category of 'possible'. Memory corruption is not possible in Rust by default.

Surely you understand what 'inevitable' means before giving me an example of a project that has at least one memory corruption vulnerability out of the thousands of other projects that are also in C++, especially browser-based software?