> the real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not.
When Firefox was new, it was trivial to embed Gecko. There was an ActiveX-Widget that you could just drag to your VB or C# form and get a browser. There were also a bunch of browsers which were just wrappers around Gecko (K-Meleon or Galeon). It was also possible in other environments, though maybe not so easy - StarOffice/OpenOffice included Gecko, too. One reason this was possible is that from the beginning, Gecko was built with components in mind. XPCOM was very much like COM and allowed you to have a stable C++ ABI. Your classes are basically structs with a known memory layout and function pointers, and you use interfaces to access them.
Unfortunately it was a bit overengineered, and component technologies fell out of favor and were removed from many projects (XPCOM, COM, BONOBO, UNO...). I think it was a overreaction to the excesses of object orientation in the 90s- Microsoft is moving back to the opposite direction with WinRT. Anyway, the modularity was removed from Firefox/Gecko on purpose in order to simplify the code.
Webkit comes from a similar heritage (Kparts). I think the reason why there are embeddable Webkit widgets is just because people did the work to create them - QtWebKit, WebView2, ..., not because Webkit is inherently more embeddable. In fact, the multi-process nature causes a bunch of problems. You can't just reach into the DOM from your native code, but you have to inject JS to manipulate it, and so on.
When Firefox was new, it was trivial to embed Gecko. There was an ActiveX-Widget that you could just drag to your VB or C# form and get a browser. There were also a bunch of browsers which were just wrappers around Gecko (K-Meleon or Galeon). It was also possible in other environments, though maybe not so easy - StarOffice/OpenOffice included Gecko, too. One reason this was possible is that from the beginning, Gecko was built with components in mind. XPCOM was very much like COM and allowed you to have a stable C++ ABI. Your classes are basically structs with a known memory layout and function pointers, and you use interfaces to access them.
Unfortunately it was a bit overengineered, and component technologies fell out of favor and were removed from many projects (XPCOM, COM, BONOBO, UNO...). I think it was a overreaction to the excesses of object orientation in the 90s- Microsoft is moving back to the opposite direction with WinRT. Anyway, the modularity was removed from Firefox/Gecko on purpose in order to simplify the code.
Webkit comes from a similar heritage (Kparts). I think the reason why there are embeddable Webkit widgets is just because people did the work to create them - QtWebKit, WebView2, ..., not because Webkit is inherently more embeddable. In fact, the multi-process nature causes a bunch of problems. You can't just reach into the DOM from your native code, but you have to inject JS to manipulate it, and so on.