> The codebase is deliberately under-architected (a legacy of the scars of working on Gecko), so many things you'd expect to be well defined re-usable modules that could be worked on independently of Google are actually leaky hacks
I'm guessing you're specifically referring to Gecko's early over-use of XPCOM, which the Gecko team itself had to clean up in a long process of deCOMtamination [1].
I'm hopeful that if Servo ever gets enough funding to become a serious contender among browser engines (hey, KHTML was once an underdog too), that it might walk a middle path between overuse of COM-ish ABIs and what you described about Chromium. Servo is already decomposed into many smaller Rust crates; this provides a pretty strong compile-time boundary between modules. Yet those modules are all statically linked, and in a release build, that combined program gets the full benefit of LTO. Of course, where trait objects are used, there's still dynamic dispatch via vtables, but the point is that one can get strong modularity without using something COM-ish everywhere.
Incidentally, the first time I built Chromium (or more specifically, CEF) from source in late 2012, I was impressed as I watched hundreds of static libraries being linked into one big binary. Then as I studied the code (though not deeply enough to learn the things you described), I saw that Chromium didn't use anything COM-ish internally (though CEF provided a COM-ish ABI on top). That striking contrast with Gecko's architecture (which I had previously worked with) stuck with me. I wonder how much the heavily reliance on static linking and LTO (meaning whole-program optimization), combined with the complete lack of COMtamination, contributed to Chrome's speed, which was one of its early selling points.
[1]: Mozilla used to have a dedicated wiki page about deCOMtamination, but I can no longer find it.
I'm guessing you're specifically referring to Gecko's early over-use of XPCOM, which the Gecko team itself had to clean up in a long process of deCOMtamination [1].
I'm hopeful that if Servo ever gets enough funding to become a serious contender among browser engines (hey, KHTML was once an underdog too), that it might walk a middle path between overuse of COM-ish ABIs and what you described about Chromium. Servo is already decomposed into many smaller Rust crates; this provides a pretty strong compile-time boundary between modules. Yet those modules are all statically linked, and in a release build, that combined program gets the full benefit of LTO. Of course, where trait objects are used, there's still dynamic dispatch via vtables, but the point is that one can get strong modularity without using something COM-ish everywhere.
Incidentally, the first time I built Chromium (or more specifically, CEF) from source in late 2012, I was impressed as I watched hundreds of static libraries being linked into one big binary. Then as I studied the code (though not deeply enough to learn the things you described), I saw that Chromium didn't use anything COM-ish internally (though CEF provided a COM-ish ABI on top). That striking contrast with Gecko's architecture (which I had previously worked with) stuck with me. I wonder how much the heavily reliance on static linking and LTO (meaning whole-program optimization), combined with the complete lack of COMtamination, contributed to Chrome's speed, which was one of its early selling points.
[1]: Mozilla used to have a dedicated wiki page about deCOMtamination, but I can no longer find it.