Forum Discussion
What were the main reason(s) Microsoft chose Chromium over Firefox?
I insist that these reasons are mostly from a business and technical point of view.
1. Integration
Its rare to find any applications using embedded Gecko.
XUL is Mozilla's UI markup language, similar to HTML.
Gecko has always been rather tightly bound with Firefox/XUL. If you did not want to build your interface in XUL then the embedder was carrying around a bit of extra code that was complicated. There have been some various attempts at making Gecko an embeddable interface independent engine.
Although In recent years, Mozilla has greatly been reducing the usage of XUL in Firefox.
I think Mozilla is right not to invest in embeddable Gecko. Even if they succeeded; on a technical level, Gecko + Xulrunner = pretty huge code base. And if they manage to get Servo into production anytime soon it would just be a waste of time anyway.
https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko
It's something that even Mozilla recommends against.
Due to limited developer time and resources, embedding seems to have gone largely out of focus and thus Gecko is indeed harder to embed than WebKit.
Servo aims to be more embeddable but the API is still in work. (more info in the next section)
2. Stability/Reliability
https://en.wikipedia.org/wiki/Servo_(software)
The link you've provided clearly states that Servo's "CEF support never reached a usable state and support was removed from Servo in early 2018".
But it does not necessarily mean that Servo is deprecated or an abandoned project.
https://servo.org/
https://github.com/servo/servo/wiki/Roadmap <== This should be sufficient
As you can see the project is under active development and aims to replace major components of Gecko with the ones written in Rust.
https://wiki.mozilla.org/Oxidation
3. Familiarity/Compatibility
While Firefox's extension store might be one of the best, its something inevitable that chrome has the most amount of extensions available and most newer extensions are mostly limited to chrome.
most of those 'newer' extensions are developed by the same people who don't read or care about web standards in general.
4. Monopoly
Like I have previously mentioned, while Chromium is a free and open source project developed by Google, modifying the source code shouldn't go unnoticed. Besides, it goes through many reviews and isn't instantly merged into their Stable branch which Chrome is built on.
I'm not saying that monopolies are good, but even Google's "dictations" are Open Standards and that is nowhere as bad as closed sourced ones (IE).
And browser built upon the same platform (Chromium) are not Forced to follow Google's standards, if They have significant Marketshare they can do what google did with Webkit. Fork it.
and regarding UA sniffing, most browser capabilities (tech's) could be 'spoofed' in a similar way.
I insist that these reasons are mostly from a business and technical point of view.
1. Integration
Its rare to find any applications using embedded Gecko.
XUL is Mozilla's UI markup language, similar to HTML.
Gecko has always been rather tightly bound with Firefox/XUL. If you did not want to build your interface in XUL then the embedder was carrying around a bit of extra code that was complicated. There have been some various attempts at making Gecko an embeddable interface independent engine.
Although In recent years, Mozilla has greatly been reducing the usage of XUL in Firefox.
I think Mozilla is right not to invest in embeddable Gecko. Even if they succeeded; on a technical level, Gecko + Xulrunner = pretty huge code base. And if they manage to get Servo into production anytime soon it would just be a waste of time anyway.
https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko
It's something that even Mozilla recommends against.
Due to limited developer time and resources, embedding seems to have gone largely out of focus and thus Gecko is indeed harder to embed than WebKit.
Servo aims to be more embeddable but the API is still in work. (more info in the next section)
2. Stability/Reliability
https://en.wikipedia.org/wiki/Servo_(software)
The link you've provided clearly states that Servo's "CEF support never reached a usable state and support was removed from Servo in early 2018".
But it does not necessarily mean that Servo is deprecated or an abandoned project.
https://servo.org/
https://github.com/servo/servo/wiki/Roadmap <== This should be sufficient
As you can see the project is under active development and aims to replace major components of Gecko with the ones written in Rust.
https://wiki.mozilla.org/Oxidation
3. Familiarity/Compatibility
While Firefox's extension store might be one of the best, its something inevitable that chrome has the most amount of extensions available and most newer extensions are mostly limited to chrome.
most of those 'newer' extensions are developed by the same people who don't read or care about web standards in general.
4. Monopoly
Like I have previously mentioned, while Chromium is a free and open source project developed by Google, modifying the source code shouldn't go unnoticed. Besides, it goes through many reviews and isn't instantly merged into their Stable branch which Chrome is built on.
I'm not saying that monopolies are good, but even Google's "dictations" are Open Standards and that is nowhere as bad as closed sourced ones (IE).
And browser built upon the same platform (Chromium) are not Forced to follow Google's standards, if They have significant Marketshare they can do what google did with Webkit. Fork it.
and regarding UA sniffing, most browser capabilities (tech's) could be 'spoofed' in a similar way.
Thraetaona wrote:
I insist that these reasons are mostly from a business and technical point of view.
1. Integration
Its rare to find any applications using embedded Gecko.
XUL is Mozilla's UI markup language, similar to HTML.
Gecko has always been rather tightly bound with Firefox/XUL. If you did not want to build your interface in XUL then the embedder was carrying around a bit of extra code that was complicated. There have been some various attempts at making Gecko an embeddable interface independent engine.
Although In recent years, Mozilla has greatly been reducing the usage of XUL in Firefox.
I think Mozilla is right not to invest in embeddable Gecko. Even if they succeeded; on a technical level, Gecko + Xulrunner = pretty huge code base. And if they manage to get Servo into production anytime soon it would just be a waste of time anyway.
https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko
It's something that even Mozilla recommends against.
Due to limited developer time and resources, embedding seems to have gone largely out of focus and thus Gecko is indeed harder to embed than WebKit.
Servo aims to be more embeddable but the API is still in work. (more info in the next section)
2. Stability/Reliability
https://en.wikipedia.org/wiki/Servo_(software)
The link you've provided clearly states that Servo's "CEF support never reached a usable state and support was removed from Servo in early 2018".
But it does not necessarily mean that Servo is deprecated or an abandoned project.
https://github.com/servo/servo/wiki/Roadmap <== This should be sufficient
As you can see the project is under active development and aims to replace major components of Gecko with the ones written in Rust.
https://wiki.mozilla.org/Oxidation
3. Familiarity/Compatibility
While Firefox's extension store might be one of the best, its something inevitable that chrome has the most amount of extensions available and most newer extensions are mostly limited to chrome.
most of those 'newer' extensions are developed by the same people who don't read or care about web standards in general.
4. Monopoly
Like I have previously mentioned, while Chromium is a free and open source project developed by Google, modifying the source code shouldn't go unnoticed. Besides, it goes through many reviews and isn't instantly merged into their Stable branch which Chrome is built on.
I'm not saying that monopolies are good, but even Google's "dictations" are Open Standards and that is nowhere as bad as closed sourced ones (IE).
And browser built upon the same platform (Chromium) are not Forced to follow Google's standards, if They have significant Marketshare they can do what google did with Webkit. Fork it.
and regarding UA sniffing, most browser capabilities (tech's) could be 'spoofed' in a similar way.
#1 sounds like a decent reason, so in a nutshell it's harder to make UI changes and personalization in Gecko engine compared to Chromium. since Microsoft wants to make lots of UI personalization based on user feedback, that makes sense.
#2 also sounds good, thanks for the links, the future for the Firefox and Gecko is bright, they are not going towards a dead end
#3 It's not a good reason, quality over quantity. it's like saying Android Google play is better than App store because it has more apps. 3 millions vs 2 millions.
but we see more malware embedded apps find their way into Google play's store
https://www.theregister.co.uk/2020/01/07/nasty_google_play_apps/
#4 if forking was that easy, Microsoft would've done it. who better than Microsoft can maintain a forked Chromium project in Github!
closed source browsers and dictating open standards are not even remotely related.
when you say closed source, you named IE but Google Chrome and this new Edge insider are also closed source.
"I just wanna put it there that using big/small/colorful fonts doesn't make your point any more valid."
It obviously doesn't magically make them more valid. I used all of those for the same reason we sort documents or write accordingly to the rules; Increased Legibility or simply pointing out the more important parts; But thanks for the suggestion.
3. Quantity/Quality
Having more content isn't directly related to quality, you can have both. And I'm not saying that chrome exclusive ones are better or worse. Just stating that -most- newer extensions are only written for chrome or have first class chrome support.
4. Open Source/Standards
That's true, Chrome Is not open source.
But it's built upon Chromium, google just bundles chrome with a few proprietary stuff, namely codecs and their own pdf viewer. that is nowhere close to what we call a 'web standard'
And based on what I have heard Microsoft Edge might be open sourced.
Also 'Forking' especially for a company like Microsoft that has created 2 different browsers in the past shouldn't be hard.
why would they Fork it when there aren't any conflicts, one of their goal's is 'reducing developer pain on the web' [Compatibility]
Remember that Google who decided to perform a fork did it because they had a different approach than Apple for how "multi-process" should be implemented. Google had an implementation that they didn't want to integrate into the Webkit branch - hence the Blink fork.
- Spoiler
Thraetaona wrote:"I just wanna put it there that using big/small/colorful fonts doesn't make your point any more valid."
It obviously doesn't magically make them more valid. I used all of those for the same reason we sort documents or write accordingly to the rules; Increased Legibility or simply pointing out the more important parts; But thanks for the suggestion.
3. Quantity/Quality
Having more content isn't directly related to quality, you can have both. And I'm not saying that chrome exclusive ones are better or worse. Just stating that -most- newer extensions are only written for chrome or have first class chrome support.
4. Open Source/Standards
That's true, Chrome Is not open source.
But it's built upon Chromium, google just bundles chrome with a few proprietary stuff, namely codecs and their own pdf viewer. that is nowhere close to what we call a 'web standard'
And based on what I have heard Microsoft Edge might be open sourced.
Also 'Forking' especially for a company like Microsoft that has created 2 different browsers in the past shouldn't be hard.
why would they Fork it when there aren't any conflicts, one of their goal's is 'reducing developer pain on the web' [Compatibility]
Remember that Google who decided to perform a fork did it because they had a different approach than Apple for how "multi-process" should be implemented. Google had an implementation that they didn't want to integrate into the Webkit branch - hence the Blink fork.
You're welcome,
3. I haven't seen that, unless there are any meaningful example.
most developers release extensions for both Chromium and Firefox because Firefox is the 2nd most used browser in the world, after Google chrome. (not Chromium)
4. is there any source for that? for components Google puts into Chromium and calls it Google chrome.
you seem to have forgotten about manifest V3 and how it can cause problems for extensions.
Maybe the new Microsoft Edge goes open source to be easier to port to Linux.
3.
Of course, most professional or popular extensions are released for both, but smaller ones mostly target a single browser. we can expect more extensions to target chrome because of its growing market share.
4.
Some extra components:
1- Pepper Flash (PPAPI) Is built into chrome, you'll have to install NPAPI into chromium under linux distros, or manually extract PPAPI from a Chrome installation and link chromium to that one.
2- Widevine (Again, this can be manually added to chromium)
3- Telemetry and a background service for automatic updates.
4- ChromeOS services
5- Proprietary codecs (AAC, H.264, and MP3, etc)
About Manifest V3
lets ignore the other changes introduced in Manifest V3 and focus on ad (content) blocking.
One of the major changes is their move from 'WebRequest' to 'DeclarativeNetRequest' API
With WebRequest, Chrome sends all the data in a network request to the listening extension. That includes sensitive data. The extension then evaluates the request, and decides what to do with it.
As a result, you have to trust the extension developer won't bait you with an awesome adblocker, then switch to spying on you after an update as it already prompted for those permissions. Google is trying to move the object of trust from the extension developer to the browser developers.
The goal they're trying to achieve is to prevent extensions from spying on your web traffic, by having the extension register rules beforehand, similar to how you register a ublock Origin's filter lists.
One of its major problems was that they originally enforced a low amount of rules (50000) which raised some concerns at first, a typical ublock list could easily exceed that amount. But now it has a limit of 150000 which should be sufficient.
The problem is that Google has a conflict of interest when it comes to ad/content blocking.
Chrome will lose a considerable portion of their users if they really decide to fully deprecate manifest v2 and WebRequest without any good replacements.
The extensions will nevertheless evolve to adapt to this change, whose implementation is still distant.
On the bright side, Firefox/Chrome/Edge all have some kind of privacy related features included, I'd say that they are a decent out-of-box alternatives to adblockers.
As always, other browsers are not forced to follow this decision, While i do agree that chrome has become some sort of monopoly and has developed a significant advantage in terms of browser market share, there is an exception; Back then there was mostly IE which was already pre installed, with no real competitors, and internet speed was slow enough to make downloading another browser a time consuming and frustrating task.
Nowadays we have many browsers to choose from. Yes they mostly run Chromium as their web engine but clearly they all have unique features and target users. We also have Gecko and Webkit under active development.
Chromium is still an open sourced project and honestly not everything is bad about having a dominant browser engine as standard. (I've already explained that code changes go through many reviews from different contributors and aren't instantly merged into their stable branches.)
Even if only a 'partition' of it is open sourced, its enough to make fully functional browsers like Opera and Vivaldi.
This was not possible with Internet Explorer back in the day, which was closed source and solely controlled by Microsoft.