SOLVED

What were the main reason(s) Microsoft chose Chromium over Firefox?

MVP

I just saw a post on my Twitter from EdgeDev and they said they contributed so much to the project. with hashtag #Opensource

 

Open source is good but Chromium is not the only open source engine, There is Firefox, fully open source and it uses Gecko layout engine. it's been around way longer than Chromium, in fact it is one of the first engines that was ever created.

 

So I'm both curious and really interested to know the logic and reason that why Microsoft chose Chromium instead of Firefox.

 

hopefully we will see some official responses here too in addition to others :)

27 Replies

@HotCakeX 

From a technical and business perspective it was better to choose Blink over Gecko due to several reasons

 

1. Integration; It's harder to embed Gecko compared to Blink. (There's a reason everyone's going with Webkit/Blink) And since Microsoft acquired Github along with Electron, which is already using Chromium's engine at its core, improving and integrating the new Chromium-based edge should result in Electron apps being both faster and smaller in size.

 Its worth mentioning that Progressive Web Apps are the upcoming alternatives to Electron. Microsoft already added support for PWAs in Edge, now they should work with other browsers vendors to add missing functionality, like file system access.

 

2. Stability/Reliability; With Servo around and major rewrites of the Gecko's components in Rust already in-progress, Gecko wouldn't really be a viable option

 

3. Familiarity; Chrome has the most amount of extensions available, something the classic edge has always lacked, building upon Chromium's Foundation should make the transition from other web browsers easier and smoother for the end-users.

 

4. Compatibility; Because of chromium's massive marketshare, most of web contents are built/optimized with chrome in mind.  

 Many sites are created and run by developers who haven’t read and don’t care about web standards;  this is why all the effort to create a real standards-compliant browser fail, They either have to create fixes (hacks) for nearly every site (Almost Impossible) or switch to chromium.

Less browser diversity = Less targets to test for

 

 

Although having a monopoly in the market should generally be bad, chromium, unlike IE is not closed source and can always be forked.  

 The real question after a while should be: why would anyone choose to use a different browser other than the pre-installed one that is equal, if not better?

 

Hope this Helps!

@Thraetaona And what's is going to happen if Edge starts take big chunk of marketshare from Google Chrome? I understand that Chromium is open-source but quite under Google control. They might decide to add some code giving some advantage to Chrome instead of other Chromium-based browsers. Not to mention their popular approach to make Youtube, Gmail and other services to work only/better/faster under Chrome. Using Vivaldi for example had issues with many websites even tho based on Chromium and they changed user agent to Chrome, I think.  

@altean 

 

Indeed, Infact Google's popular services such as YouTube allowed them to kill IE6 in the past.

 

But we should also not neglect the fact that Microsoft has their own marketing capabilities, too. The ability to have a web browser pre installed on most of desktop devices alone has a significant influence on this.

 

Mobile devices remain, and the popularity of search engines also plays a role in this.

 

It certainly isn't an easy task to take Chrome's marketshare away, but i doubt its the goal.

 

And while Chromium is a free and open source project developed by Google, modifying the source code in a way that it affect's chrome's performance positively while lowering other's shouldn't go unnoticed. Besides, it goes through many reviews and isn't instantly merged into their Stable branch which Chrome is built on.

 

Most chromium based browsers just change their user interface and add some extra features (e.g integrating with a specific service or adding an ad blocker) without touching the core engine, and even if they do, they will probably upstream (contribute) the changes back into the original code (Chromium).

 

But let's say that they edit their site's or services (like youtube) in a way that it favors Chrome or constantly asks the user to consider switching to it.

Then it that case user agent switching should generally prevent them from doing so.

 

Regarding Vivaldi, maybe there was a problem with the vivaldi itself or Gmail, or even a bug in chromium.

There are many possibilities, hard to trace the issue without info.

 

@HotCakeX "So I'm both curious and really interested to know the logic and reason that why Microsoft chose Chromium instead of Firefox."

 

Microsoft hasn't, as far as I know, issued any statements or advisories about why Microsoft chose Blink (Chrome) instead of Gecko (Firefox), but it did issue a number of statements indicating that Microsoft's motive in replacing IE/Edge was to improve compatibility and simplify web-based design/deployment.

 

It seems to me that if compatibility and simplification were the drivers, then the reason why Microsoft chose Blink is almost a no-brainer. Cross-platform, Blink-based browsers have about a 65-70% market share (slowly rising), Webkit-based browsers have about a 15-20% market share (more or less stable but irrelevant to the Windows market) and Gecko-based browsers have about a 5-10% market share (slowly eroding).  

 

The well-stated technical issues @Thraetaona raised (integration and stability) are important and might well have been a determining factor if the contest between Blink and Gecko was close (and would be sufficient reason to choose Blink over Gecko in that event), but I don't think that it got to that point.  I think that Blink was the inevitable choice given Microsoft's stated goals.

 

The market bit Microsoft badly when Microsoft introduced Edge using a non-standard engine (Edge quickly turned into a niche product), and once bitten, twice shy. 


Spoiler

@Thraetaona wrote:

@HotCakeX 

From a technical and business perspective it was better to choose Blink over Gecko due to several reasons

 

1. Integration; It's harder to embed Gecko compared to Blink. (There's a reason everyone's going with Webkit/Blink) And since Microsoft acquired Github along with Electron, which is already using Chromium's engine at its core, improving and integrating the new Chromium-based edge should result in Electron apps being both faster and smaller in size.

 Its worth mentioning that Progressive Web Apps are the upcoming alternatives to Electron. Microsoft already added support for PWAs in Edge, now they should work with other browsers vendors to add missing functionality, like file system access.

 

2. Stability/Reliability; With Servo around and major rewrites of the Gecko's components in Rust already in-progress, Gecko wouldn't really be a viable option

 

3. Familiarity; Chrome has the most amount of extensions available, something the classic edge has always lacked, building upon Chromium's Foundation should make the transition from other web browsers easier and smoother for the end-users.

 

4. Compatibility; Because of chromium's massive marketshare, most of web contents are built/optimized with chrome in mind.  

 Many sites are created and run by developers who haven’t read and don’t care about web standards;  this is why all the effort to create a real standards-compliant browser fail, They either have to create fixes (hacks) for nearly every site (Almost Impossible) or switch to chromium.

Less browser diversity = Less targets to test for

 

 

Although having a monopoly in the market should generally be bad, chromium, unlike IE is not closed source and can always be forked.  

 The real question after a while should be: why would anyone choose to use a different browser other than the pre-installed one that is equal, if not better?

 

Hope this Helps!


" It's harder to embed Gecko compared to Blink."

Source for that?

 

"With Servo around and major rewrites of the Gecko's components in Rust already in-progress, Gecko wouldn't really be a viable option"

 

I would take a look at here first

https://en.wikipedia.org/wiki/Servo_(software)

 

Servo intended to re-implement the Chromium Embedded Framework (CEF) API. This would have allowed Servo to be used as a drop-in replacement for Chromium in applications using CEF, and would have positioned Servo as a competitor to Chromium in these cases.

 

 

3. Firefox has been around longer than Chromium and their add-on store is at the very least as rich as Chrome extension store, if not richer. quality over quantity. though I'm not even sure Firefox has lower number of addons compared to Chrome extension store.

 

 

4. Chromium, controlled by Google, creates monopoly. they sometimes even dictate web standards which is the rights of a totally different organization.

 

it's in fact for this very reason why Firefox would be a better option, because it wouldn't give more power to Google.

 

 

 

 

@altean 


@altean wrote:

@Thraetaona And what's is going to happen if Edge starts take big chunk of marketshare from Google Chrome? I understand that Chromium is open-source but quite under Google control. They might decide to add some code giving some advantage to Chrome instead of other Chromium-based browsers. Not to mention their popular approach to make Youtube, Gmail and other services to work only/better/faster under Chrome. Using Vivaldi for example had issues with many websites even tho based on Chromium and they changed user agent to Chrome, I think.  


 

So true.

 

 

@Thraetaona 

Spoiler

@Thraetaona wrote:

@altean 

 

Indeed, Infact Google's popular services such as YouTube allowed them to kill IE6 in the past.

 

But we should also not neglect the fact that Microsoft has their own marketing capabilities, too. The ability to have a web browser pre installed on most of desktop devices alone has a significant influence on this.

 

Mobile devices remain, and the popularity of search engines also plays a role in this.

 

It certainly isn't an easy task to take Chrome's marketshare away, but i doubt its the goal.

 

And while Chromium is a free and open source project developed by Google, modifying the source code in a way that it affect's chrome's performance positively while lowering other's shouldn't go unnoticed. Besides, it goes through many reviews and isn't instantly merged into their Stable branch which Chrome is built on.

 

Most chromium based browsers just change their user interface and add some extra features (e.g integrating with a specific service or adding an ad blocker) without touching the core engine, and even if they do, they will probably upstream (contribute) the changes back into the original code (Chromium).

 

But let's say that they edit their site's or services (like youtube) in a way that it favors Chrome or constantly asks the user to consider switching to it.

Then it that case user agent switching should generally prevent them from doing so.

 

Regarding Vivaldi, maybe there was a problem with the vivaldi itself or Gmail, or even a bug in chromium.

There are many possibilities, hard to trace the issue without info.

 


Not really. Google stole the market from Microsoft even when Microsoft installed Edge and IE by default on Windows, even when Microsoft showed tips when people tried to change default web browser from Microsoft browsers to a 3rd party.

Google, with their annoying banners on Google search results that tell people to switch to their Chrome browser, took the market share. that's only one of their tactics.

 

user agent switching is an old trick that no longer should be used because it's as easy as drinking water, to spoof user agent.

 

websites should detect which technologies a browser is capable of instead of simply detecting what the user agent is.

 

 

 

best response confirmed by HotCakeX (MVP)
Solution

@HotCakeX 

 

 

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.

@HotCakeX 

 

MS probably decided against it because:

 

  1. If they're doing this for better web compatibility, WebKit/Blink is the obvious choice, sadly. Some of Microsoft's web products don't fully support Firefox, but do support Chromium.

  2. Chromium is more easily embedded, which may help them put it into a UWP app and the UWP API.

  3. Chromium has a slightly more permissive license for MS to do proprietary things with it if they want to.

Would've been nice though.

@Thraetaona 

Spoiler

@Thraetaona wrote:

@HotCakeX 

 

 

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.


 

#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.

@Akshay_Mane 


@Akshay_Mane wrote:

@HotCakeX 

 

MS probably decided against it because:

 

  1. If they're doing this for better web compatibility, WebKit/Blink is the obvious choice, sadly. Some of Microsoft's web products don't fully support Firefox, but do support Chromium.

  2. Chromium is more easily embedded, which may help them put it into a UWP app and the UWP API.

  3. Chromium has a slightly more permissive license for MS to do proprietary things with it if they want to.

Would've been nice though.


 

Thanks, these sound great too, specially number 3!

@HotCakeX 

 

"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.

 

 

 

@Thraetaona 

Spoiler

@Thraetaona wrote:

@HotCakeX 

 

"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.

@HotCakeX"Maybe the new Microsoft Edge goes open source to be easier to port to Linux."

 

Possible, I suppose, but Microsoft has shown no particular interest in porting to Linux any time soon -- the port is still in a "someday, when we get around to it" status (see "Edge on Linux" and other discussions in the Forum on the topic).  It doesn't sound like porting to Linux was a driver in Microsoft's decision.  

 

It seems unlikely that ease of porting to Linux was a factor in choosing Blink (Chrome) over Gecko (Firefox).    Firefox was ported to Linux a long time ago, and is the browser packaged as the default browser in just about every major distro. 

 

@HotCakeX 

 

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.

 

 

Spoiler

@Thraetaona wrote:

@HotCakeX 

 

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 a open sourced project and honestly not everything is bad about having a dominate browser engine standard. 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.

 

 

3.

 

Smaller extension developers can create Firefox version too, nothing is preventing them.

like I said Firefox is the 2nd most used browser and it's more popular in Linux ecosystem.

so this can't be one of the reasons Microsoft chose Chromium over Firefox.

 

4.

Yes I was aware of them as they are very popular and well known.

 

Given the nature of Google company, It's wiser to trust an extension like ublock origin instead of Google Chrome. Google talking about preventing spying is a joke.

you can read some of my posts here

 

Decent yes but far from perfect.

 

https://techrogen.com/manifesto-v3-and-ad-blockers-in-chromium-150000-rules-for-declarative-net-requ...

 

 

@tomscharbach 

Spoiler

@tomscharbach wrote:

@HotCakeX"Maybe the new Microsoft Edge goes open source to be easier to port to Linux."

 

Possible, I suppose, but Microsoft has shown no particular interest in porting to Linux any time soon -- the port is still in a "someday, when we get around to it" status (see "Edge on Linux" and other discussions in the Forum on the topic).  It doesn't sound like porting to Linux was a driver in Microsoft's decision.  

 

It seems unlikely that ease of porting to Linux was a factor in choosing Blink (Chrome) over Gecko (Firefox).    Firefox was ported to Linux a long time ago, and is the browser packaged as the default browser in just about every major distro. 

 


Well Microsoft say they love Linux, so it's time to show it in action..

 

@HotCakeX 

 

3.

 

Well, nothing is preventing them from porting the same extension to other browsers, too.

But that comes at the cost of maintenance.

 

Even if firefox's share droppdd to 1% compared to 99%, would it still make sense porting to it, considering that it still is the worlds second popular browser?

 

Well, That's impossible, but i was just saying that if chrome's usage is going to grow, then less and less developers will care about Firefox's support. how can you expect someone who doesn't care weather their site is accessible by anything other than Chrome to port their extensions to other browsers?

 

Firefox's usage is indeed higher within the Linux ecosystem, but be aware that some extensions might specifically target a certain OS; same reason we don't use shell (like KDE) integration extensions in chrome/firefox under windows.

 

Linux usage is only a tiny portion of desktop share, let alone the influence of mobile markets on this.

 

4.

 

ublock origin is not the only extension making use of that API

 

Regarding trusting ublock, you might be interested in this: http://tuxdiary.com/2015/06/14/ublock-origin/

 

Well, why would anyone who values privacy at that rate, choose google chrome in the first place? there are many alternatives.

 

"Decent yes but far from perfect."

 

Well, it should use something like 140k at max, given that most of those rules are outdated and no longer in existence, it could be trimmed down to a much smaller amount.

 

 

 

@HotCakeX  "Well Microsoft say they love Linux, so it's time to show it in action."

 

Microsoft is steadily heading in the direction of Linux -- Azure, for example, is increasingly tied into Linux, Microsoft seems to be moving to Linux on its servers, WSL2 provides tight integration between Microsoft's in-house Linux kernel and Windows, and Microsoft is preparing Linux versions of core revenue products (e.g. Microsoft Office) for deployment.  I expect to see the process continue (and accelerate) in the future.  I won't even be surprised if Microsoft abandons the NT kernel in favor of the Linux kernel as the foundation for Windows within a decade.

 

However, as impatient as I am to see Edge ported over to Linux (as are many on the Forum who use both Windows and Linux in daily work), I can understand why Microsoft is not making the port a priority.  Linux has a very small desktop market share (about 2%), the port process is complicated, and the number of Linux users who are likely to use Edge (people who use both Windows and Linux for day-to-day work) is almost certainly extremely small.  In short, the cost/benefit equation does not favor making a Linux port a priority.

1 best response

Accepted Solutions
best response confirmed by HotCakeX (MVP)
Solution

@HotCakeX 

 

 

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.

View solution in original post