4 ms·

IMO, the trouble with COM and its imitators is that they're prone to gross over-use. The best example I know is Gecko, which over-used XPCOM and then had to go

IMO, the trouble with COM and its imitators is that they're prone to gross over-use. The best example I know is Gecko, which over-used XPCOM and then had to go through what Mozilla folks called deCOMtamination. [1] I think IE might have over-used COM to some extent as well, but that's only speculation based on what I saw on the outside. (Disclosure: I work at Microsoft, but I joined well after IE became Edge, and I was never on that team.) Then Chrome landed like a piece of alien technology, and if we took a look inside, we found that it was one giant binary module (DLL, .framework, or executable, depending on the platform) that internally didn't use anything like COM, at all. It was also fairly well-known for its use of link-time optimization. I wonder how much these things contributed to Chrome's famous speed. Of course, Chrome was only able to pull this off because the team had great engineering discipline, and later, a great build system (first GYP, then GN). I remember when I built Chromium for the first time and was awed at how it was made up of hundreds of modules, but they were all built as static libraries and then linked together into one monster binary module at the end. These days, newer statically compiled languages like Go, Rust, and others are bringing large-scale static linking of arbitrary modules within reach for the rest of us. If I may stretch the IC metaphor, I'm guessing something similar happened with actual ICs; better EDA tools made it more feasible to combine more and more IP blocks onto a single chip, giving rise to the modern SoC. [1]: The best post I can find that talks about deCOMtamination, and then goes on to describe how XPCOM continued to be over-used, is this: https://brendaneich.com/2006/02/fresh-xpcom-thinking/ https://brendaneich.com/2006/02/fresh-xpcom-thinking/ Does anyone know of a definitive written history of this process?

pjmlp 6y ago
Isn't UWP exactly the over-use of COM across the whole Windows ABI surface area? It just didn't work out as Sinosfky originally planned it.
pcwalton 6y ago
> I remember when I built Chromium for the first time and was awed at how it was made up of hundreds of modules, but they were all built as static libraries and then linked together into one monster binary module at the end. This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced. (Also, based on my experiences with Node and other Google projects like Skia, I wouldn't consider gyp a great build tool—it's always been a nightmare for me. gn is better, but Google projects still have a tendency to be difficult to build for those who aren't Google employees.)
- mwcampbell 6y ago
  > This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced. Touché. And I do remember seeing this in Firefox, or maybe even the old Mozilla suite, long before Chrome came out. Still, I think static linking is a much more effective optimization in Chrome, because Chrome doesn't make heavy use of internal ABI boundaries (e.g. COM or XPCOM), so link-time optimization can be more aggressive. IIUC, Firefox and Thunderbird still use a fair amount of XPCOM internally, because they have lots of modules written in JavaScript, including all of the code behind the XUL-based UI. Chrome, on the other hand, uses a lot more C++.
  - pcwalton 6y ago
    Chrome has a lot of the frontend written in JS nowadays too. At this point XPCOM is mostly just a bindings layer between JS and C++ (that's what COM was supposed to be to begin with—a glue layer between languages). V8 has something similar. I don't think you can really say static linking is more effective in Chrome or Firefox. Both browser architectures are broadly similar these days.

pjmlp 6y ago

Isn't UWP exactly the over-use of COM across the whole Windows ABI surface area? It just didn't work out as Sinosfky originally planned it.

pcwalton 6y ago

> I remember when I built Chromium for the first time and was awed at how it was made up of hundreds of modules, but they were all built as static libraries and then linked together into one monster binary module at the end. This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced. (Also, based on my experiences with Node and other Google projects like Skia, I wouldn't consider gyp a great build tool—it's always been a nightmare for me. gn is better, but Google projects still have a tendency to be difficult to build for those who aren't Google employees.)

mwcampbell 6y ago
> This is how Gecko is built too—essentially everything ends up in libxul unless it has to be split out so that link.exe doesn't OOM on 32-bit (sadness). I believe it had been this way when the first version of Chrome was released, so this wasn't something Chrome introduced. Touché. And I do remember seeing this in Firefox, or maybe even the old Mozilla suite, long before Chrome came out. Still, I think static linking is a much more effective optimization in Chrome, because Chrome doesn't make heavy use of internal ABI boundaries (e.g. COM or XPCOM), so link-time optimization can be more aggressive. IIUC, Firefox and Thunderbird still use a fair amount of XPCOM internally, because they have lots of modules written in JavaScript, including all of the code behind the XUL-based UI. Chrome, on the other hand, uses a lot more C++.
- pcwalton 6y ago
  Chrome has a lot of the frontend written in JS nowadays too. At this point XPCOM is mostly just a bindings layer between JS and C++ (that's what COM was supposed to be to begin with—a glue layer between languages). V8 has something similar. I don't think you can really say static linking is more effective in Chrome or Firefox. Both browser architectures are broadly similar these days.