What, really, is a downside to having an open-source web engine that all browsers use? I'm failing to see one. The web would become less fragmented; the web standard would be (only slightly) irrelevant, and we would move forward without having to deal with browsers interpreting the spec/standard differently, which is what happens currently in a lot of cases.
For example, a security bug in chromium becomes vastly more dangerous if everyone is working off that code. That said, hopefully there’ll be fewer of those because everyone is focused on the same codebase.
The questions seem to be “how many browser engine implementations is truly necessary for a healthy ecosystem?” And “has the spec gotten so bad that it’s not feasible for the ecosystem to support a sufficient number of independent implementations?”
Seems like <5, and maybe <3 is the answer to the first, and the answer to the second is we’ll see what happens to servo in 2019...
No.
1. Chrome will remain the dominant web browser
2. the Chromium repository itself is owned by Google
The only leverage Microsoft is in forking Chromium, but that does nothing to Chrome's market.
Google themselves forked WebKit when they couldn't get along with Apple. And that was back when Chrome wasn't as pervasive.
So what makes you think Google would give a crap about Microsoft today?
So, by your own logic, if Microsoft ends up in a disagreement with Google about the direction of chromium, whats to stop them from just forking it and becoming the new dominant engine?
Chrome will only remain the dominant web browser as long as its users view it as worth the hassle. If Edge is built upon chromium in the future, I'm not going to sit here and say that Chrome will remain the dominant browser following that.
We can sit here and talk about 'what ifs' all day.
https://developer.chrome.com/multidevice/webview/overview Since 4.4 it is based on Chrome, not WebKit. Since I think version 6, on all the Google phones it defaults to using Chrome for WebView instead of the "WebView for Android" browser.
KitKat was released in 2013[1] as well as Blink in the same year[2].
Apart from Blink being a WebKit fork, WebKit itself is not "the dominant engine" anymore at least since 2014.
[0]: https://developer.chrome.com/multidevice/webview/overview
Them switching to Chromium is essentially admitting defeat and inability in building a modern browser.
They won't do it, because the entire team at Google is staffed by C++ folks. How is that a better outcome?
But a real plan to do this requires a great deal of thought and serious consideration about how you get from here to there, whether there are long-term engineering velocity costs, etc. You don't just say "Rust is more memory-safe" and let that phrase alone mean "so obviously you're a dinosaur if you don't switch to it".
Even Mozilla is taking a lot of time and effort to introduce Rust-based components to Firefox. Making big changes to enormous projects used by huge numbers of people is not something you do lightly.
Still, though, we'd happily consider it.
I think it's fair to say that a Rust proposal would have been dead-on-arrival a couple of years ago. It'd be seen as far too risky. It would have remained so in a world where Blink was the only browser engine.
It's a classic innovator's dilemma: with fewer browser engines, the fewer risks the industry will take. More browser engines allow more seemingly-risky innovations (such as parallel styling/layout, or Rust) to break through.
The trickiest part is the proving that the different approach technology is enough better to warrant a switch. Very often, new approaches don't live up to expectations (not saying this is the case for the tech you're talking about).
2. The issues here don't have to do with whether the technology "works" (it does), but rather "developer velocity" and other more social/political concerns.
1. When you're experimenting with a seriously new technology or approach, the most likely outcome is that you'll fail, especially at the market adoption level. Being able to conduct your experiment at a lower cost is still a net positive, except for one point: having invested less, you are more likely to abandon the experiment early, because of the sunken costs fallacy. That doesn't necessarily need to be the case.
2. Developer velocity/productivity is something that you can demonstrate - as long as the difference is consistent, like, not 10% faster, but 80% faster. Other social/political concerns are a different thing, but really, gaining market adoption based only on those is VERY difficult - if that wasn't the case, I don't think we would be having this discussion at all, because Firefox would have a much higher penetration.
So, the point is, how is having a completely separate codebase going to help with having success? It could attract a higher number of idealistic developers, but the additional work required is very likely to negate that advantage.
It certainly doesn't hurt to do compelling things in Rust in a browser engine, but doing compelling things in Rust in some other project entirely would also be motivating.
To look at it from another angle, Mozilla itself had a reason to try to tackle some problems with Rust. It didn't need a competing browser engine using Rust in order to move forward with that plan. And the plan wasn't "well, we'll try this because we can somehow fall back on a competing engine if this doesn't work". So if your argument were true, I don't see how Mozilla could have moved on this either.
In the end people do things because the potential benefit justifies the costs and risks, and having a competitor do something is not the only way of determining potential benefit.
Edge does. I'm curious to see how this will work.
If all of our leading browsers use the same engine, the answer to that is one and the same.
I mean, I get the point you're trying to make, but the argument doesn't really fit with what I'm saying. As far as I'm concerned go ahead and rewrite Blink in Rust or Go or Common Lisp. As long as it is the main engine, or adheres to the web standards, it really makes no difference to me.