It's still better because Chromium is open-source, but I do worry that we're going to have a problem in the future with a lot of broken sites (YTMND-style).
This is already the norm. I use Safari and find many sites have issues. Before that I used Firefox and many sites had issues.
Typically the JS works, but styling often looks different (and worse) on Safari and Firefox.
I don't have any proof but my suspicion is that I've seen more sites failing Safari since Mojave.
I really dislike (& distrust!) using Chrome now, especially for e-commerce sites or anything with SMS based 2FA as Safari's ability to pull codes automatically from messages is a godsend.
"transparent 0" is not a standard way of defining things, and bad use o CSS in production.
[1] https://stackoverflow.com/questions/35583503/input-type-sear...
Chrome also frequently attempts to cover up incorrect code with what it thinks the author probably meant. Firefox tends to be much better than Chrome at following the actual spec.
I tend to develop primarily with Chrome first for some different reasons (ability to disable CORS, support for self-signed certs with WebSockets, and its better debugging of WS frames), but I always make sure to test later with Firefox and Safari, and occasionally find code that worked in Chrome, but doesn't elsewhere, and the reason is almost invariably always that Chrome didn't follow the spec.
[1] https://developer.apple.com/design/human-interface-guideline...
I develop for Firefox first as well.
The browser vendors taking the lead over standards committees is how we got this far into HTML5, especially including Apple's/Safari's decision to ditch flash, and the WHATWG actually moving us forward vs the W3C.
Unless Blink has a history or an expectation of deprecating serious functionality in the future, is it really so bad if websites follow what's Chrome-compatible instead of 'a web standard'?
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.
Let's imagine for instance that Google develops something called "Google Pay". Let's now imagine that WHATWG works on something called "WebPay".
In a multiple-engines world, there would be pressure for Blink to support (and keep supporting) most major credit cards & payment mechanisms to let users pay using WebPay.
In a single-engine world, one single manager at Google will have sufficient power to decide that WebPay supports only Google Pay.
Feel free replace Google Pay and WebPay by any other technology strategic to Google.
For all intents and purposes, web browsers are operating systems running web applications, taking care of security, etc.
And all these Chromium-derived browsers are skins and utilities on top of Google's browser/OS.
That takes a somewhat limited in scope view as to what a web standard is; by most measures, what the WHATWG produces is as much a standard as anything the W3C does, and is certainly comparably useful to other implementers.
> Unless Blink has a history or an expectation of deprecating serious functionality in the future, is it really so bad if websites follow what's Chrome-compatible instead of 'a web standard'?
If someone wants to build a new web browser, can they do it without having to spend huge amounts of money on reverse-engineering Chrome and being bug compatible with it?
Blink is open source- you want to encourage innovation in the usability and utility of the browser and let people compete on market share of their browser product not how people’s web apps that run on that platform work or don’t work - The key is it’s open we’ll never have another IE6. Anyone can compile Blink. Look Microsoft is focusing on getting it to work on arm- cool. This is the opposite of locked to windoze only.
* There is a number of implementations of the same platform.
* Those implementations are competing and the market encourages them to be in-compatible with each other.
You can avoid that bad state by having an explicit standard and applying pressure on all implementations to meet that standard. It usually comes at the expense of slower innovation.
But another viable way to avoid that bad state is to simply not have competing implementations. A single canonical implementation also solves the problem of ensuring all users get a compatible experience. It can come at the expense of evolving in a way that doesn't meet user needs because there isn't a competitive incentive to win users.
I don't think there are perfect solutions, but I also don't think it's the end of the world if this becomes a monoculture. There are tons of "platforms" that are effectively mono-cultures and seem to be OK. Every rechargeable tool company has its own battery pack form factor. Up until recently, each laptop company had a different port for the AC adapter.
What I think this is really showing is that the market size of the web is shrinking relative to the size of the browser standards. Mobile apps have eaten up so much user share and HTML+CSS+JS+etc. has gotten so big and complex that the desktop web market can't effectively support multiple independent browser implementations any more. It's just too much work for too little return.
There's maybe an interesting lesson here in not letting your platform get too complex. New features are always nice, but they have a cost. If you pile on too many of them, you may undermine your platform's ability to support multiple independent implementations.
Let's be clear: that is the future you are advocating.
The owner of the repo is Google. Google gets last word on anything Microsoft wants to include in Chromium/Edge.
That has no impact on what MS can do downstream as long as it's an open license.
If Microsoft, or Opera, or anyone else downstream wants to pull out parts of Chromium and replace them with Rust components (including a parallel renderer), they are free to do so. It increases their maintenance cost to maintain the unique components, but so would maintaining a whole separate from-scratch project instead of being downstream.
I'm guessing this is a stressful day around the Mozilla watercooler. This is bad news for Mozilla. Web authors will target the behavior supported by a majority of user browsers. With many independent browsers, there is no implementation majority, just a plurality. Majority behavior only comes from a standard and all implementers are incentivized to work with that standard.
When there's only a few, it's possible for a single one to become the de facto "standard". The web is effectively moving to a first-past-the-post election. Because Microsoft is adopting Chromium, Mozilla's engine and Safari may very quickly become minority ones.
This might suck for users, but that's not entirely clear. Obviously, in a perfect world, there would be infinite engineers building infinite implementations of every platform. In reality, every engineer-hour spent working on, say, a new implementation of COBOL is an hour not spent on software that might impact more users' lives in more important ways.
Maybe a couple of commodity web browsers and engineers working on other more important stuff is better for society? How many implementations of CSS does the world really need? <shrug>
Either way, I'm not advocating anything. I'm more interested in understanding what are the causes and effects — both bad and good — of a platform going from three implementations to two. I'm approaching this as sociology, not as someone who has skin in the game.
I do work for Google and did work as part of the Chrome org, but I don't have enough expertise to make any claims about whether this is an overall good or bad thing for the world. I'm just interested in all of the consequences.
Shouldn't users have the best possible CSS engine? If there's only one, and it's beholden to the reporting structure at Google, then disruptive innovations are less likely to happen.
People who don't work at Google should be allowed to develop the Web platform, without asking Google for permission.
Shouldn't they have the best possible COBOL compiler? The best possible VRML renderer? The best possible ICQ client?
Obviously CSS is way less dead than those, but there is always an opportunity cost. It's not a valid engineering argument to say "we should spend resources on X" without considering what else those resources could be spent on.
My initial comment is really just observing that maybe Microsoft's move actually does imply that they believe, no, the world doesn't need another CSS engine. I don't know if that's true or not, but I think it's interesting to ask the question.
We sort of a tacitly assume that the web will grow and grow forever and ever. But maybe that's just because we've only seen the first half of its life cycle. Maybe it is reaching a plateau and becoming a commodity. There are good questions about whether that's true and, if so, whether that's a good thing.
But I don't think it's illuminating to just assume the best way to improve the world is to have as many browser implementations as possible. Like an entire Dyson sphere populated solely by engineers each writing their own HTML parser.
> then disruptive innovations are less likely to happen.
Maybe the disruptive innovation has happened and the disruption was to move off the web. The Internet and HTTP is doing great. What mobile app isn't on the Internet? Maybe HTML+CSS+JS is no longer the optimal user interface language for it.
> People who don't work at Google should be allowed to develop the Web platform, without asking Google for permission.
I guess I don't see what you're getting at. Browsers don't write themselves, so if you don't want to ask one of a couple of giant rich corporations to do something, that means you better have deep pockets yourself.
Even if Microsoft kept their web engine, how does that help? Now instead of asking Google, Mozilla, and WebKit for permission, you have to ask Microsoft, Google, Mozilla, and WebKit for permission and then get them to all agree on it.