Browsers | Hacker News Reader

Browsers

adactio.com

341 pointsindysigners292 comments

I feel like I’m missing something, because I keep seeing blog posts that tell me a browser monoculture is bad (and the irony of Microsoft saying this is nearly too much), but none of them tell me why. I understand that it was bad in the IE6 days, but IE6 was also closed source and could only be run on Windows (see also the irony of Microsoft discontinuing IE on Mac, not wanting to compete with Safari, a browser made by the OS manufacturer). Chromium is open source - the only lock in is the decision to use it. Sure, Google may be at the reigns of where the project goes, but then differentiate on features, or fork it and make it different. Differentiate on the user interface, or integrations with other services, or go hard on privacy. Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows? One operating system would be bad, but one kernel has spawned many, many Linuxes. I guess I’m doing my part by using Firefox, but that’s more because I am worried about just how much Google knows about me, and not because I think Gecko is remarkably better than Chromium.

> Sure, Google may be at the reigns of where the project goes, but then differentiate on features, or fork it and make it different.

And if the fork diverges, then what? This is not a theoretical concern: Blink and WebKit are now quite different, and it's best to regard them as two different rendering engines. Is that bad?

> Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows?

This presupposes that the Linux kernel is at an optimum point in the design space. It's pretty clear to me that it isn't. In fact, I think the monoculture around open source kernels has been bad for OSS. I look forward to Fuchsia providing some much-needed competition, much in the same way LLVM provided much-needed competition to GCC.

IE, at its height, was available outside windows. https://en.m.wikipedia.org/wiki/Internet_Explorer_for_Mac

At that time, 2001-2002, IE6 was highly praised. You don’t get to 96% marketshare by being something everybody hates. The hate came later when CSS demand ramped up and it became clear IE6 used a non-standard box model. Worse still MS essentially abandoned the browser, the result of total marketshare dominance, and tied it directly to the operating system.

The reason people are complaining about this is the lack of diversity. This has proven very bad in the past. It essentially makes the platform a proprietary space even if the dominant browser is open source. The key here is who directs the technology and direction of the platform.

> IE6 used a non-standard box model.

Which we all use now anyway because it was right way to do it...

    * {
      box-sizing: border-box;
    }

That is a matter of opinion.

I don't do that and I avoid code that does. In the days of IE7 I learned to write CSS code that was conformant to both box models. Now I just write to the standard box model. CSS isn't something that will ever be particularly challenging once you have gone through the extremes of edge case use cases.

It's not a matter of opinion, content-box is much more difficult to work with when using fluid layouts than border-box which is why all major CSS frameworks use border-box now.

At the time, the CSS specification didn't make it clear which way to calculate widths so Microsoft, probably due to their experience building graphical layout software, chose border-box while all other rendering engines at the time went content-box probably without considering the consequences. Realizing the error, the box-sizing property was added to CSS to fix this.

You claim it’s not a matter of opinion and due to personal opinion. Weird. Then you invent a history from which to draw imaginary conclusions. It is perfectly ok to have a personal opinion on CSS. You don’t have to justify it and you certainly don’t have to conjure a dillisional alternate reality.

Imagination aside, IE3 was the first browser to offer any CSS support.

https://css-tricks.com/box-sizing/

https://blog.teamtreehouse.com/box-sizing-secret-simple-css-...

https://quirksmode.org/css/user-interface/boxsizing.html

https://www.jefftk.com/p/the-revenge-of-the-ie-box-model

https://github.com/twbs/bootstrap/issues/12351

https://jgthms.com/minireset.css/

https://github.com/sindresorhus/modern-normalize

https://semantic-ui.com/globals/reset.html

You're just wrong. The CSS box model as specified by the standards was totally unusable for making a website where you want boxes to have certain sizes with certain margins and paddings, especially in the days before you could use calc(), so you couldn't mix pixels with percentages. It's true that it was the standard, and so MS should have implemented the standard, but it's also true that what MS shipped made way more sense and every frontend dev turns on their box model when it box-model: border-box became part of the standard.

No no no, that's a completely different issue — we are talking about hasLayout stuff here.

Couple of corrections: IE6 actually fixed the box model (that was the difference between the new standards mode vs quirks mode that matched IE5), and IE on the Mac used a completely different rendering engine (Tasman instead of Trident).

The box model issue was independent of quirks mode. Quirks mode was triggered by HTML not conformance to a modern doctype (HTML4, XHTML 1.1, or one of the three XHTML 1.0) which produced a different DOM tree and thus different layout/appearance when CSS was applied. This was particularly frustrating because even when MS fixed the corresponding CSS defects their DOM tree remained non-standard until IE9.

I remember having to deal with all these things when working with the company's aging CMS. It was a great tool, but the version the company was using was old (before standardized doctypes in 1999) and inserted a comment into the top line of code throwing all documents into quirks mode in IE.

The box model was corrected when IE released version 7, which still also featured quirks mode rendering for backwards compatibility.

It was sort-of available for Mac. IE for Windows was based on the Trident layout engine. The Mac version was based on the Tasman layout engine: https://en.wikipedia.org/wiki/Tasman_(layout_engine). While they were both branded as "Internet Explorer", they weren't the same browser.

Tasman was actually quite good, too. It was a great deal better than trident in many regards, ranging from the ability to properly handle transparent PNGs to more complete and correct CSS support. IE for Mac was a great browser for years after IE 5/6 had grown long on the tooth. I always wondered why it didn’t get ported to Windows to replace Trident.

You are right. A monoculture IS a good thing for browsers engine.

> the irony of Microsoft saying this is nearly too much

Where is Microsoft saying that?

Problems with monoculture: lack of innovation, a single agenda being pushed forward, anti-competitive behavior. Google doesn’t want technology X? X is dead. Google thinks Ad platform Y is bad? Y is dead. etc

Please read this different take and explanation in this article linked within the main article, titled "The ecological impact of browser diversity", by Rachel Nabors. [1]

[1]: https://css-tricks.com/the-ecological-impact-of-browser-dive...

The problem with his analogy is that it make the difference between browsers out to be the difference between a bird and a squirrel when at best it's more like the difference between a falcon and a eagle.

If we really want diversity on the internet we should probably still be using Gopher and other internet clients.

Seems like you have yourself answered your question in your list line. One browser owned by one organization could hijack whole internet for its own interests. Just like in any other necessary item we need multiple supple options are good for creating healthy competition.

I completely agree. I think there is a bit of unjustified fear here given that Edge's ridiculously small installed base had absolutely no affect on the browser mono-culture anyway. Most developers did not go out of their way to test in Edge.

This is really no different than the Linux Kernel. People will take KHTML, Webkit, Blink, V8, JavaScriptCore and remix those into dozens of different products all with better web compatibility than something home grown from Microsoft with no chance of adoption.

I think we first need to agree that competition in a general sense—that is including browsers and everything beyond—is a good thing. It's healthy for any market to have viable competitors; principally for the consumers, but also for the vendors (so that they do not stagnate). If we don't agree that competition is healthy, then I don't believe it's possible to agree on the second-order matters.

There are several second-order reasons why a monoculture is damaging for the browser industry. I will give a few examples:

1. A monoculture encourages web developers to test on a single platform with the assumption that all other platforms, and even industry standards, are meaningless. Many of us are web developers, and most of us are guilty of dismissing low-share platforms during testing. But as long as some viable competitors exist, we nominally target the industry standards in the hope that by doing so, the platforms we do not test on will have a modest/tolerable (maybe even good) experience.

2. A monoculture is self-reinforcing. Losing established viable competitors makes it more difficult for new competitors to enter the market. If we allow second-tier browsers to be rendered meaningless, we all but ensure a long and (eventually) painful stagnation, and create an ever-larger hurdle for a new entrant to clear to reach any significance (as more an more of the web is designed to work with a single platform). While it may sound passably agreeable to have a Chrome monoculture in 2019, do we want to still have a Chrome monoculture in 2029? For my part, I hope we see an increasing set of options in most areas of life over time, even in "browsing," whatever that ends up looking like in 10 years.

3. We don't know what future stagnation will look like. We don't know what opportunities we will have lost by making it more difficult to compete or by losing the healthy diversifying force of competition. It's a classic problem of the unseen. Projecting forward, we predict testing will be a bit simplified, but we cannot know what innovations we'll never see (or won't see as quickly) because the hurdles for experimentation were too high. Today, if Firefox introduces a new feature, even though its usage is relatively small the usage is still large enough in absolute terms that the innovation isn't entirely under the radar for most of us. If Firefox's share were 0.8% instead of 8%, far fewer of us would even notice if they added a slick new feature, leaving the feature unheralded and obscure despite its potential wide appeal.

The biggest reason is that when you have one implementation, the implementation becomes standard irrespective of what the standard itself says. When IE6 was dominant, this meant a lot of people had to reverse engineer the details of IE6's weird CSS implementation. Chief among its faults was an incorrect box model (although W3C later added an attribute to use IE's old box model) and the infamous hasLayout bug, which Wikipedia at one point had a page on (it appears to be gone now). Sure, Webkit may be open-source, but that doesn't really lend itself to finding issues related to buggy implementations.

The concern is not 'now' it's 'later'.

Google is a business like any other - and when they have the power to lever a monopolized situation - they will.

For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?

Or what if they integrate technology that de-facto collects usage and behaviour - even from other domains - and then lever that competitively?

The power that Google already has, relatively unregulated is crazy. Remember that Google is the company that could change the outcome of elections ... possibly without us even knowing. They could drive markets up or down at will.

This would probably happen as a 'slow drip' - not one step being close enough to consumer awareness to create problems, and what with 'business friendly' politicians, nary a worry of legislation getting in the way.

They could introduce these technologies under the guise of 'improving user experience' (and maybe legitimately so to start), but other PM's, new CEO's etc. just take the opportunity before them. Why wouldn't they?

We worry a lot about 'Net Neutrality' at the network level, like it's a religion ... but that we don't worry about 'information neutrality' as well I find quite bizarre.

I suggest that having '1 major provider' may be a problem, doubly so if it's an entity like Google, and that frankly we don't really gain much from this fact at all. If Mozilla were the provider, great. Even Apple might be a better choice simply because they are not in the business of managing our information - at least right now, for them, it's a headache, not a revenue source.

So the concern is real.

They've already started. Google Meet (their version of Hangouts for enterprise) didn't work on non-Chrome browsers for a very long time. If you tried to do a video call with a non-Chrome browser, you were told to install Chrome and load the page in Chrome. The only reason they were able to get away with this is because Chrome has the high market share that it does. If they'd done this when Chrome had 10% market-share, the response from users would have been to stop using Google Meet. However, because they did this when Chrome has 70% market share (and climbing) there was hardly any outcry; those who didn't already have Chrome installed gave a resigned sigh and installed Chrome in order to participate in their work meetings.

Currently, all of Google's services work on non-Chrome browsers. But will that always be the case? I can very well imagine a world where Google starts making its services Chrome-only, citing, for example, that only V8 has the necessary Javascript performance to run Google's increasingly bloated webapps with adequate performance.

Like you said, it'll start as a slow drip, with the least popular and most obscure applications (for example: Google Play Music) being moved over first. Then, as users fail to object, they'll move over larger and larger applications. Even if they never make the "big-two" of YouTube and Google Search Chrome-only, they'll still be exerting a fair amount of pressure for users to switch to Chrome.

Google Meet still doesn't work with Safari, with no explanation. Safari supports the latest WebRTC, and AIUI Google Meet uses the current WebRTC standard, so why does Google refuse to let it work on Safari? This has to be deliberate.

Safari has purposefully neutered WebRTC, both Firefox and Google have full codec support while Apple tries to push H.264 only, plus things like web push still doesn't work on iOS: https://webrtchacks.com/safari-webrtc/

Google Meet also appears to have updated to support the WebRTC spec (rather than the oddball implementation Chrome had) so long as your browser supports it: https://blog.mozilla.org/webrtc/firefox-is-now-supported-by-...

I thought H.264 is free for Software Decode? Supported in Firefox as well. There is no reasons why Apple should support VP8 / 9 Which is a Google's Codec, even though it is free of charge.

H.264 isn't free, Cisco is footing the licensing bill for support in most software (including Firefox): https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Implementatio...

This is why Mozilla is pushing AV1 and VP8/VP9 so hard, being stuck with H.264 as the whole industry migrates to H.265 due to bandwidth savings is a major impediment, and the licensing body could easily extract usurious rent for H.265 if it becomes the only reasonable option: https://hacks.mozilla.org/2018/08/the-video-wars-of-2027/

Sorry I got mixed up, but it should be free for anyone which has H.264 hardware decode. Which is like 95%+ of All PC / Tablet / Smartphone sold in the last 5+ years.

And that article from Mozilla, I remember it, worst article from Mozilla for as long as I remember ( That is since Netscape Era ).

Rejecting VP8/VP9 due to Google's involvement is silly and pointless, they're free to use codecs that are much more efficient than H.264. Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA.

Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA.

If that’s true, why are they a member of the AOM, which promotes the royalty free av1?

How long can Apple push against all of the major content providers? Google, Netflix, Mozilla, AT&T & the plethora of other streaming providers will not fully support H.265, and Apple doesn't want to not have a seat at the table as they build a codec to supplant it.

I think this is a repeat of the USB C engineering participation by Apple, they may roll it out to their tiny MacOS install base, but it could be years before AV1 is supported on iOS. Safari on iOS is where Apple likes to draw its line in the sand, it also happens to be where they have nearly 1 billion users, versus 70 million on MacOS: https://ngcodec.com/news/2018/10/9/whats-in-a-codec-hevc-ver...

While it's true that Safari only supports H.264, Google already produces quite a lot of H.264 video. In fact, Google has a Google Meet iOS app; I don't suppose you have any idea if they push H.264 to that app, or if they've actually embedded a software VP8/9 encoder/decoder into the app? I sincerely hope it's the former for battery life reasons if nothing else (though we already know Google doesn't seem to care about power efficiency).

What does Web Push have to do with WebRTC?

WebRTC was created to replace the need for apps that handle calling, without web push notifications (like every other WebRTC supporting browser has) there is no way for inbound calls to cause the phone to receive a notification unless Safari is open and has the webpage pulled up.

WRT VP8/VP9, bandwidth is much more of a concern than you make it out to be. Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low (say hello to congested towers, or fringe 700Mhz coverage where 500Kbps is all you get :P), thus the best compression possible ensures that video quality and usability is top notch.

By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. Is it good for interop with a 2005 era deskphone? Sure, but not much else.

Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant.

> Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low

I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target).

> By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs.

It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile".

In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

> Google Meet is a video conferencing app, not a telephone replacement.

Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years.

Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.

Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned

> In any case, if you want better than H.264, how about H.265

H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu...

> I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P

> once again not WebRTC spec compliant

According to the page you linked, nobody is spec-compliant.

I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else.

> A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.

Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.

> Currently, all of Google's services work on non-Chrome browsers.

Last time I checked, Google Authenticator only works on Chrome.

> Last time I checked, Google Authenticator only works on Chrome.

Google Authenticator is available for Android, iPhone, and Blackberry, and not for any browser; there are a number of third-party implementations, however, including a Chrome/ChromeOS one.

I don't use any of those things. I just know that I had to install Chrome to get Telegram's desktop app working.

FYI Telegram has a history of serious security issues:

https://www.theregister.co.uk/2018/02/13/telegram_messaging_...

https://www.theverge.com/2017/1/11/14237136/trump-leak-teleg...

https://gizmodo.com/why-you-should-stop-using-telegram-right...

Thanks.

But I did know that.

It was just that Everpedia used it for chat, and I was curious.

Gmail and YouTube uses Chrome only features that make them slow in other browsers, compared to Chrome.

You imply they do this deliberately, do you have any evidence? It sounds super unlikely to me.

Also if alternate browsers mindshare dips too far they could argue it was too much effort to support such a small part of the market.

> Currently, all of Google's services work on non-Chrome browsers.

Google Earth is Chrome-only, because they use the Chrome-only NativeClient.

Google Hangouts dropped calling support on non-Chrome browsers for quite a while: https://news.ycombinator.com/item?id=15889018

YouTube (and perhaps GMail) is extra slow on non-Chrome browsers because they use a dropped-and-never-standardised feature that is available only on Chrome, and force a slow polyfill on Firefox (and perhaps Edge): https://twitter.com/cpeterso/status/1021626510296285185

Google Earth has a desktop version too.

They use a polyfill for Firefox on Youtube because of a never-standardised feature too: https://twitter.com/cpeterso/status/1021649116391075840

> YouTube (and perhaps GMail) is extra slow on non-Chrome browsers because they use a dropped-and-never-standardised feature that is available only on Chrome, and force a slow polyfill on Firefox (and perhaps Edge): https://twitter.com/cpeterso/status/1021626510296285185

I work on the Polymer team at Google, and have worked with YouTube on this. I can promise you that the folks at YouTube are working very hard on porting to the specs that are supported crossbrowser. Switching to the final versions of the specs is super high priority for all of us, there were just some changes between v0 and v1 that are hard to paper over, and as you might imagine, YouTube has a lot of code.

> Google Earth is Chrome-only, because they use the Chrome-only NativeClient

My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.

https://medium.com/google-earth/earth-on-web-the-road-to-cro...

https://developers.google.com/web/updates/2018/02/meltdown-s...

> there were just some changes between v0 and v1 that are hard to paper over

From my point of view, the moral of this story is that Chrome shouldn't be shipping v0 specs that are on by default.

It's not that people like me want to be cynical conspiracy theorists, it's just really frustrating to watch Google ship an unfinished API that's on by default, integrate it so tightly into its core products that it can't be easily updated after the spec changes, and then just kinda... sit on it. And it's really convenient that whenever Google messes up standards, it just happens to mess them up in a way that makes Chrome look better to normal users for all of its core products.

Heck, it's frustrating that Chrome is still shipping the v0 implementation. I don't want to be vindictive or bitter, but engineers on the Polymer team clearly thought the polyfill was fast enough for Firefox. They don't think it's fast enough that Chrome could be using it now?

I don't think I'm being a conspiracy theorist when I say that probably the reason why Chrome still ships with a working v0 implementation is because Youtube uses it. And it makes me feel weird to have a dominant browser deciding to contradict a standard because it makes a Google site fast. I think that's problematic and harmful for the open web.

So even though I know that the team's intentions are good, the intentions do nothing at all to mitigate or fix the harm. And I'm sure you can understand that when people talk about the dangers of a browser monoculture, it is exactly this kind of thing that we're afraid of. A lot of us feel like Google dev teams don't really have much respect for standards or community processes. Google tends to have an attitude that standards will always go the way it wants, and if other browsers are behind on that, we just need a little polyfill or stopgap or something until they catch up. Certainly they won't decide to go in a different direction.

Is that going to get better when Chrome has 95% market share? Won't Google devs feel even more emboldened to ship v0 implementations that disregard the standards process? Are there any new safeguards or internal policies being put into place to prevent devs working on Youtube or Gmail or Maps from building core infrastructure around browser APIs that haven't been standardized yet?

> I can promise you that the folks at YouTube are working very hard on porting to the specs that are supported crossbrowser.

I'm sure the folks at YouTube are working very hard on porting to the Web standard, but the truth of the matter is:

1. Non-Polymer YouTube works just fine, and yet isn't served on Firefox and Edge;

2. Chrome shipped and continues to support a Chrome-only "standard", which is never going to be a Web standard, for some reason;

3. YouTube, a sibling product of Chrome, and supposedly a Web app, built a whole redesign around this when it wasn't even a Web standard, or even available in more than one browser, and now apparently can't do without, without dragging every browser that YouTube is not related to down.

On these counts, the apparent favouritism is clear.

> there were just some changes between v0 and v1 that are hard to paper over

I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?

> My understanding is that if it weren't for spectre, cross-browser Google Earth would very likely be shipping today. There is a web assembly version of Earth, but it needs threads and SharedArrayBuffer, which is disabled in most browsers today because of spectre-class security issues.

You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly. Google Earth is currently available for the desktop in these forms: A native version, and a Chrome app. Yes, Chrome also happens to be a browser, but it is not just a browser, and Google Earth does (heavily) depend on its non-browser parts.

So, naturally, questions arise:

1. If it weren't for things like Google Earth and Hangouts, would Chrome's NativeClient still be around?

2. If it weren't for Chrome's NativeClient, could Google Earth and Hangouts have become the products that they have?

The answer to the second is easy: Hangouts did exist as an NPAPI plugin for a while, and does currently work on non-Chrome browsers via WebRTC, so it certainly could have used the exact same features on Chrome, and Google Earth has always had an installable, native, desktop version.

> 2. Chrome shipped and continues to support a Chrome-only "standard", which is never going to be a Web standard, for some reason;

It's going to be unshipped around April.

Chrome shipped the v0 spec in order to prove out that the specifications were valuable and worth implementing. It took time to get the other browsers on board. Writing a major application like YouTube with the specs provided a lot of valuable feedback for the final version of the specification.

Today, the other browsers are very much on board with these specs, Firefox is even rewriting many parts of their UI with these same specs. Three years ago there was more skepticism, and by building real world applications we could figure out what works and what doesn't, and address the (very reasonable) questions that people had about their design.

> I believe you. I also see that there's a polyfill for this. And yet, YouTube doesn't (need to) use it in the one browser that it's parent company makes?

YouTube does actually use the Shadow DOM polyfill today, even in Chrome, and Shadow DOM is definitely the most complicated and arguably the most performance-critical spec involved. Polymer v1 uses the Shadow DOM polyfill by default even in Chrome because if it used native Shadow DOM it would be too easy to write an app that would only work properly in Chrome.

> You mean, if it weren't for Spectre, a Web version of Google Earth would very likely be shipping today, using WebAssembly.

Would you prefer that the NativeClient version of Google Earth not exist at all? The work that went into NativeClient has contributed to the wasm spec, and (I assume, but don't actually know) the NativeClient version of Google Earth was the basis of the wasm version.

Speaking just for myself, like, I get what you're saying, but I'm not sure how to actually translate it into action. If no one had used the v0 web component specs, then the v1 specs might never have gotten adopted at all, or at least would have been specified with way less experience on the table for how they need to work in the real world.

NativeClient is somewhat similar. It was a proposed standard that informed will (hopefully soon) be superceded by a final standard which could build on the lessons learned in building NativeClient.

Someone is going to be the first to ship a new feature. For a while, asm.js applications were really only usable in Firefox. They would technically run in other browsers through what amounted to a JS polyfill, but not very well. But Firefox's asm.js work was really good for the web, because they were able to gather a lot of real world info on how asm.js and similar techniques work in the wild.

Same thing with WebVR. As I recall, for a while Firefox was the only browser shipping experimental support for virtual reality in the web browser (someone correct me if I'm wrong here). Yes it's annoying when something works better in one browser than another, but how do you add new features to the web platform without experimentation and getting real world use?

The important thing is that the insights from shipping the experiment make it into a open specifications that are implemented cross browser.

The people should own their own data, and be able to take it with them to other services.

"For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?"

This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.

Now while I'm not sure I'm convinced that YouTube was changed intentionally to slow Edge, many of my co-workers are quite convinced - and they're the ones who looked into it personally. To add to this all, when we asked, YouTube turned down our request to remove the hidden empty div and did not elaborate further.

And this is only one case.

I think it's interesting. Did you investigate why they added that div?

Many "irrational" decisions are related to interactions with anti-bot/anti-fraud logic.

I worked on IE in the days when there were many crazy conspiracy theories about silverlight and IE collaborating to ruin the open web. This sounds similar.

We often use empty DIVs for catching mouse events.

Antitrust?

The behaviour that your co-workers claim Google engaged in sounds pretty exactly like the AMD-Intel antitrust case where AMD alleged that Intel's C compiler was deliberately crippling performance on AMD processors to help Intel's processors compete. If true, Microsoft should sue Google over it - not just out of raw corporate self-interest, but because this sort of conduct is evil and should be stamped out.

If this case hasn't already been run up to Microsoft's lawyers, start running it up to them. You'll be doing the world a service.

Fascinating. I wonder what the counter-argument would be; that a website isn't software, perhaps? That argument could be sufficiently argued apart by equating manually downloaded/installed software with code that's manually downloaded (GET / host: youtube.com) and run in a browser context.

I'd be curious to see how likely Microsoft would be to follow this approach rather than to just stick to using Blink... as they've already decided to do.

The counter arguments are a) broken rendering in your browser does not dictate how my websites have to be, and b) since when is Google a monopoly on standardized HTML web video?

Google could start responding to YouTube requests with binary streams of gibberish if they want, MS would only have standing to sue as a content creator and advertiser on YouTube.

If Google is reverse engineering other browsers optimization paths and putting out content that is disagreeable to that optimization, that's possibly unfortunate but not illegal.

a) A broken reference C compiler don't dictate how a different C compiler might act -- in reference to the case which Intel lost.

b) since Google's browser became the defacto standard browser thanks to Edge switching engines, hence the thread. The standard doesn't really matter anymore; Google makes most of them now as a matter of course anyway.

What will Microsoft gain if they Win? Nothing. Google has the upper hand in public image. Microsoft is still evil outside of Dev Circles. And IE did some ass moves as well in IE6 era, think about the PR mess this would lead.

It is not the best time to strike now, once the timing is right, I am sure they will.

I wonder whose circles are those, most non-technical people I know doesn't care less about evil, good or whatever.

> "What will Microsoft gain if they Win?"

Uh, money? It might not exactly be a noble incentive for a lawsuit, but it's sure as hell an incentive, isn't it?

I wonder what sort of information Google might dredge up during discovery that Microsoft wouldn't want to see the light of day. I'm no lawyer/accountant, so I don't know what amount of money would be worth that risk.

With a lot of legal issues, sometimes the only winning move is not to play.

hiybbprqag for one - https://www.wired.com/2011/02/bing-copies-google/

I mean google was recently caught doing the same thing with baidu... https://theintercept.com/2018/12/17/google-china-censored-se...

Google will continue to have the upper hand in public image until stuff like that happens. Yes, this would be a PR challenge, but one MS might even be able to spin in a way they can benefit from...

"What will Microsoft gain if they Win? Nothing. "

They'll get a more level playing field.

CEO's generally don't order this stuff to happen. More often it's a director, manager, VP or whatever that's just really aggressive. Possibly the CEO knew or not.

When a company gets bloodied for a pile of money, they generally have to own up to it, which makes them look bad (by they way, these things do have a cumulative effect) - but more importantly, they have to at very least 'go through the motions' of getting staff to 'not do this stuff'.

So they have 'training' and 'oversight' etc.. However ingrained it is into behaviour (or even a single rotten apple) the likelihood of recursion goes down.

For example - if an inner legal team gets some responsibility for oversight on these issues, they can make life difficult for managers on these things.

I worked at a Fortune 50 that was sued by a patent troll, and it seriously and fundamentally changed internal culture to the point wherein we needed lawyers involved in everything, it was really bad. Obviously a negative example.

But especially Microsoft has enough $ to drag Google into court, they should do it.

That said: I'll bet $100 that MS might be doing some tricky things of their own anyhow.

Microsoft and Google exist in a bit of a cold war. They don't want to destroy each other in court. You can't just take free shots and not expect a response.

Agree.

What Microsoft gain after Windows Phone YouTube app case? Nothing. Google successfully fucked up Microsoft.

There are dev circles where Microsoft isn't evil? I've been a Unix/Linux dev for thirty years so maybe I'm not keeping up, but the general view was that if Microsoft had a platform we needed to target it was because it made us money and we assumed we'd eventually get burned - which nearly every time we did.

And I've worked for Google in the past, but their main issue has always been that they change a lot which makes them a moving target which is annoying in its own way.

Microsoft earned its public image and while it's made nicer noises recently it's not an organisation that fills me with trust.

"Microsoft is still evil outside of Dev Circles"

TBH, I consider Google much more evil than Microsoft, in or outside of Dev Circles. Microsoft dropped the evil baton and Google picked it up and sprinted away.

That sort of behaviour should be called out and publicised widely.

Given how easy it is to delete an offending div using the dev tools, it would be easily verified by web developers. There'd be a thousand blog posts and news stories saying "Google deliberately sabotages Edge on YouTube" and the public blowback would be pretty damaging I imagine.

well... https://arstechnica.com/gadgets/2018/12/the-web-now-belongs-...

The best part of this anti-trust browser conspiracy is that it involves Microsoft — but now, as opposed to the IE dominance in the 00's, Microsoft is the victim. So ironical. How's the taste of your own medicine? :)

> So ironical. How's the taste of your own medicine? :)

How is this productive?

These are, however, changes to Chrome and not Chromium, right? Even with a move to Chromium, anyone/everyone is still going to be playing catch up to Google. Having an open source engine means next to nothing if Google plays these kinds of games, abusing its dominant position. Having Edge updates tied to OS updates seems to be more of a problem than EdgeHTML itself, unless there are other issues (and there probably are) in play.

Chrome and Chromium share the same engine, and for this stuff it is the engine that matters.

For now, at least. AOSP and Android "share the same engine", supposedly, but API footprint standardized in AOSP is getting drastically distanced from the API footprint moved behind Google Play Services and other proprietary bulkheads. The number of APKs that run on non-Google Play enabled AOSP builds has dwindled fast in the last few years. (Just ask Amazon.)

What's to stop "YouTube needs Genuine Chrome™ with Google Play® Support Services Installed"?

What's to stop that now?

They could throw up a check and have "Youtube requires Chrome XX.X with the Evil-DRM plugin enabled" live whenever they want. It's the relevant market forces and ecosystem.

Another example: on Android, look up scores of an ongoing sports event on mobile Chrome, and mobile Firefox. Mobile chrome gets you a box saying what the score actually is; mobile firefox just shows you the links to sports-league and news sites that you see under the score in mobile Chrome.

Click the "show desktop view" page on mobile firefox, reload, and suddenly the score is there. They're not discriminating that aggressively against competing desktop browsers. Yet.

I'm surprised by how much less attention this gets. I couldn't use firefox or any other browser because google searches in chrome brings up results like if you were within the google app. But use any other browser and you'll just get the legacy layout and links to pages.

> For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome's dominance over Edge on video-watching battery life.

Huh?

First, I can find nowhere that Chrome claimed to have better video-watching battery life (in fact, popular tech sites mention improving but still worse[1]).

Second, the only dip I can find in the public Edge battery life tests[2] was

April 2017 - 12.5 hours

Dec 2017 - 16 hours

May 2018 - 14.3 hours

vs Chrome's 9.3, 13.5, and 12.5 hours. Which means whatever happened last spring, Chrome also dipped.

And third, how about we talk about the kind of web browser battery benchmark based on playing fullscreen video and is defeated by adding a single hidden div? It's not testing battery life of a representative sample of what a web browser is actually used for (especially over 12+ hours), and obviously wasn't very resilient in the face of what a web browser has to actually handle.

Honestly it sounds like they added a div for unrelated reasons (accessibility, "security", ads, who knows), thought it was worth the performance tradeoff (or never measured), and it indirectly ended up making Edge better for real web content (as of the Win10 Oct update).

[1] https://arstechnica.com/gadgets/2018/05/edge-still-boasts-be...

[2] https://www.youtube.com/playlist?list=PLWs4_NfqMtoxOT8E8d5KP...

Counter anecdote: As a Google engineer it always seemed like Edge implemented the sparsest possible version of the web platform to make major Google products work–and literally nothing else. That works to launch the browser, but then basically any product change runs a chance to no longer fall into that sparse subset and break in a browser. If Edge had implemented a more robust set of features, it would have massively improved compatibility down the road.

Features like empty divs on top of video? Could be by accident ofc, but the entire story makes this unlikely.

> Features like empty divs on top of video? Could be by accident ofc, but the entire story makes this unlikely.

I'd suggest inspecting a few sites you watch video on. An empty div is the least weird thing you'll find.

On the other hand, pretty easy how such a div might trigger a less efficient path; if the video is top in the z-order then it can probably bypass being composited by the browser (and who knows, maybe even bypass being composited by the OS) and avoid a whole mess of rendering to a texture, texturing some triangles, and so on and so forth.

ha, just saw your story over on ars.

FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite).

> On the other hand, pretty easy how such a div might trigger a less efficient path

I mean, sure, you can always fall off the fast path, but given how common transparent divs over video are, the battery benchmark should have come with even more caveats. Edge is the most battery efficient browser†!

† for playing fullscreen video††

†† Battery test not valid if the page doesn't use the exact layout youtube used in December 2017. Also not valid if testing vimeo, or twitch, or any porn site, or...

[1] https://news.ycombinator.com/item?id=18701430

[2] https://arstechnica.com/gadgets/2018/05/edge-still-boasts-be...

I don't think the performance claiming is really the important part here; it's doing something that lacks any real reason but which hurts Edge.

And while I agree that video overlays are common, I also think it's reasonable for such overlays to revert to a slightly less efficient path.

> it's doing something that lacks any real reason but which hurts

Hey, there's a new div in the DOM, the only possible reason for a change like that is so Chrome can advertise about beating Edge on a benchmark nobody cares about? Even though they never beat Edge on it and this "advertising" never took place?

This was the credulity I was talking about. These events didn't happen (you literally wrote the stories plural! about edge winning the benchmark) and the motivations make no sense. I'm not sure why you'd repeat it without even a warning that it may just be a narrative made up from grumblings about fixing a fast path heard third hand.

Speak for yourself, please.

I do care about video playback battery performance. So much so, in fact, that I bought my current laptop specifically so it would last long when watching videos.

Also note that tablets, smartphones, the Macbook Air and the Surface are sold on their battery stamina, and specifically while watching videos. And how would you measure that? Youtube, of course!

> And how would you measure that? Youtube, of course!

Makes total sense, but if you're over-fitting for Youtube's exact layout in 2016, you're eventually going to have to update your optimizations. Sites don't stay the same forever.

> it's doing something that lacks any real reason but which hurts Edge.

In my own web development activities I can point to hundreds upon hundreds of hidden, invisible, and obscured DOM elements that have no obvious reason to for existing to someone outside the code-base where you find the commen explaining the required work around, browser hack, or legacy constraint. I've also experienced wildly divergent performance on MS browsers compared to others when creating content, often from something as trivial as DOM order or composition.

Clearly Google owes me some money for my part in their ongoing conspiracy to hurt Edge. I'm flexible, I'll accept GCE credit :)

I highly suspect that the issue is that Windows video playback can only use scanout compositing if there is nothing on top of the video. Scanout compositing is significantly more energy-efficient than standard framebuffer compositing because it avoids a memory copy each frame.

This ultimately comes down to hardware limitations. GPUs are limited as to what they can compose during scanout, because of memory bandwidth limits. Each plane that you can alpha-blend together at scanout time multiplies the amount of memory fetches per dot you have to do. On today's high-DPI displays, the bandwidth going out to the display is very high to begin with, so you can't afford to multiply that by much. That is why putting something on top of a video is tricky: you're adding another layer to be alpha-blended on top, increasing your memory bandwidth by 50% over the two layers you already have (RGB for the background plus YUV for the video). The user's GPU may or may not support that--as I recall, prior to Skylake, Intel GPUs only had two hardware planes, for instance.

I'm not surprised that Microsoft just used "are there any DOM elements over the video?" as a quick heuristic to determine whether scanout compositing can be used. Remember that there is always a tradeoff between heuristics and performance. At the limit you could scan every pixel of each layer to see whether all of them are transparent and cull the layer if so, but that would be very expensive. You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.

> You need heuristics of some kind to get good performance, and I can't blame Microsoft for using the DOM for that.

which, again, that's fine, but mayyyyybe they were a little lax in checking performance on nearly any other popular video site on the web to see if that heuristic is a good one?

Or maybe changing page layout in an extremely common way wasn't an effort to undermine a hyper specific benchmark?

How many sites put invisible DOM elements over the videos?

Remember, if you put visible DOM elements on top of the videos, then you lose scanout compositing no matter what.

> How many sites put invisible DOM elements over the videos?

A lot of them? Vimeo, for instance, has a number of opacity: 0 and hidden divs over the video. Twitch has at least a couple of opacity: 0 divs on top.

Maybe we're interpreting the phrase

> hidden empty div over YouTube videos

differently? That's the structure I assume they were talking about.

I'd assume that it was actually an invisible, but not technically hidden div, leading to a fully transparent blending pass - divs with opacity:0 or display:none are trivial to optimize for this case.

> I'd assume that it was actually an invisible, but not technically hidden div

Considering that it's now optimized and that's not what the original post said, I don't know why you'd assume that.

There are visible elements on top of YouTube videos.

That's what this "empty div" is for if that's the one I think it is. It is the container for things like branding and annotations.

I fail to understand how an empty DIV can break a state-of-the-art video acceleration. Why not add another check to remove such empty HTML tags before hand.

Also, what can explain Edge failing to load Azure dashboard - was that a Google bug too? Ref: https://www.youtube.com/watch?v=5zMbfvEHlTU

> Why not add another check to remove such empty HTML tags before hand.

Sure, and they did. And then next month it’ll be something else, and a new check. The next month it’ll be something else yet again, and yet another check. Pretty soon Microsoft’s codebase is littered with checks and guards against the random things Google does, and they’ll still always be a deploy behind. Google could keep this up for years.

didn't MS did the same thing in the past?

Well why microsoft made IE default browser on windows pc and why SharePoint doesn't work well with non IE browsers and why excel still can't Handel vba loops and why Skype takes few seconds when multiple users ping one user and Microsoft still charges for licensing.. Its the battle to be lesser of the evils

As far as SharePoint goes, the current versions should work just as well (usually better) in Chrome. Should be mostly on par since the 2013 release.

The biggest feature difference for SharePoint cross-browser has historically been with the ActiveX controls. Say you had Word installed, there was a control to open documents with Word. As in, you could click save/view/edit rather than just whatever the browser default was. Or with Skype, to see a user's available/busy/away status next to their name on a SharePoint page. So if you're looking at a wiki or calendar for something, you might go "oh, the author is free, I can just ask." Chrome's plug-in model was much stricter than ActiveX. That's why you'd see some features in IE but not Chrome.

These assumptions truly seem as a random conspiracy theory an intern would write who does not have any idea of how a big company of this sort actually works.

Google of today is a collection of disjointed silos which don't work well together or they work together at all. The leadership of those silos is being aggressively staffed by "industry veterans" VPs and SVPs from Oracle, HP, Motorola and alikes. These folks build their little empires, not products. NIH spreads, internal "competition" starts, etc. This story should sound familiar to more experienced people from Microsoft... they've seen this development phase, they know what I am talking about... Microsoft's name for that was "IBM", Google simply calls that "Microsoft". And when you hear "We are not THAT yet" and people have need to say it, you probably turned into THAT.

Anyway, The idea of Chrome being so aligned with Youtube - over such minor gains over Edge - would today be just a wishful thinking. Until some major, major restructuring and changes to their recent corp "culture", Google will simply remain incapable of driving waaaaay more important product development changes across its product surfaces than this.

I just started a new job at a MASSIVE international conglomerate. I was literally told that an intranet site I needed to use would only work in IE, and that it specifically would fail to render fields if I used Chrome. It's a little disingenuous to hear these kinds of complaints coming from the company which distorted the browser market so badly that the world is still paying for it 20 years later.

So now it's okay because it's done to an actor that you consider deserving of such treatment? People said such behaviour is wrong, so they changed their act. Why wouldn't you hold others accountable to the same standard? What is the point of listening to the criticism and correcting your behaviour if it will be okay for others to keep punishing you?

Seems counterproductive to me.

Thank you for posting this.

and it was ok with drdos and windows 30 years ago. Now let's eat your own dogfood.....

I'm a little skeptical... when an intern claims a single empty div tanks performance from hardware acceleration that is presumably robust enough to handle much weirder stuff, this comment starts to look a bit more like a conspiracy theory account if the demise of Edge.

It sounds plausible to me. Overlaying something onto a hardware-accelerated thing suddenly adds a compositing step to your rendering pipeline, which - usually - requires moving the compositing to your GPU as well, AFAIK.

I just don't buy that any halfway decent hardware acceleration isn't robust enough to handle it. In fact they managed to fix whatever the issue was in a later release, which bolsters the argument that their process wasn't robust enough to begin with. With no other evidence here I'm invoking Hanlon's Razor.

Self-defense I would call this move of Google: Some weeks ago I stumbled upon a win 10 laptop I should set up for family. As soon as I installed Firefox, windows started bugging me with popups like "We encountered you use an third party browser. This might pose a serious security thread - do you want to switch to Edge?" and stuff about this browser slowing down the system along with urging me to switch to Edge. You guys at Microsoft just still exploit your market share - so why shouldn't Google do the same to counter?

This is the feature where you can scroll down during full-screen videos that they rolled out a few weeks ago. Sure, advertising that their new feature performed better on their own browser is kinda shitty, but I really don't care about supporting Microsoft's garbage web platform that I have to run in a VM. If they had Edge on Linux and MacOS I might feel sorry for them, but nah.

Nothing is going to make me feel bad for Microsoft losing market share. This is the company that silently disabled microphone access for Chrome because it wasn't installed via the Microsoft store. I spent a month trying to figure out why my microphone suddenly wasn't working in any of my web apps. As much as I dislike what Google is doing, Microsoft has been doing far worse for much longer.

Self-defense I would call this move of Google: Some weeks ago I stumbled upon a win 10 laptop I should set up for family. As soon as I installed Firefox, windows started bugging me with popups like "We encountered you use an third party browser. This might pose a serious security thread - do you want to switch to Edge?" and stuff about this browser slowing down the system along with urging me to switch to Edge. Microsoft just still exploits its market share - so why shouldn't Google do the same to counter?

>so why shouldn't Google do the same to counter?

Because it's EVIL!

Also, have you tried opening Google.com, GMail, YouTube or Translate in Edge? You are bombarded with prompts to install Chrome. There is no way to disable them, not even when logged in.

The developer which added that invisible div responded: https://medium.com/@jeremy.noring/did-google-cripple-edges-y...

That's not the dev that added it, the article is from someone who has done something similar, not someone who works at Google.

It doesn't confirm Google's reasoning for the div

That's a developer that added an invisible div.

To clarify, that's to say it's a response by an engineer, but NOT a Google engineer who was involved with YouTube.

That is random conjecture from someone who also did that for completely different reasons on something else. Admittedly so too is the OP's post, with the added (although unsubstantiated) comment about YouTube refusing to change.

As an aside- his points on why Chrome is a monoculture misses the point. Chrome is a monoculture for the same reason almost every other thing becomes at monoculture. It was, at one point, deserving of it as a product. Whether it was naturally the only one or the best. But now, they might not be the best out there. And when they go on to create barriers to competitors and lock-in, thereby making them artificially dominant, that is an anti trust case in the making, if the U.S. Justice Department had any teeth in that area.

I guess I shouldn't be surprised with how shady Google has been over the past couple of years, but this is still pretty wild, thanks for sharing.

I have little sympathy for any Microsfot product that gets bullied in this manner. Christ, this has all the oldie hits of microsoft:

- embrace and extend standards - secret apis - advocate for standards, then drop them for proprietary ones - perform hidden changes that make competitors look bad - then tout your advantages loudly

The only thing missing is outright paying people to not support your competitors.

Firefox, however, I feel bad for. Nerd advocacy was partially responsible for Chrome's rise to popularity, but the time has come to advocate for Firefox.

I hope you have read this https://medium.com/@jeremy.noring/did-google-cripple-edges-y...

Google Maps has been doing something nasty to non-Chrome browsers for several years now -- started about the time of the Great Interface Overhaul.

So, color me astonished, not.

Exclusive access is exactly why I switched to Chrome back in the day. When they started offering features like offline Gmail access that was only available on Chrome, you bet I was intrigued. And even today, things like copy/paste keyboard shortcuts on Google Docs only working in Firefox still abound.

> For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail

Correlation does not imply causation: Yes, it might be true that companies make changes to their products that break stuff somewhere else. But to claim that it is done intentionally is very far fetched. Especially when you have to support so many different environments, it is close to impossible to thoroughly check all of them. Demanding that the performance is good even goes one step further than just demanding the service works.

The new GMail UI is considerably more snappier and responsive on Chrome than the latest Firefox, so I think it's already happening.

On more than one occasion, changing the user agent in Firefox leads to a faster Google product. It's most definitely happening, but Google hides behind the excuse that it's using "cutting edge" technology and they have compatibility layers for browsers that don't support the new features.

This would be solved if they did feature detection instead of browser sniffing, but given that the user agent hack works, they're very likely doing browser sniffing.

Better yet, they should probably wait to adopt new standards until things are actually standardized, instead of doing things as soon as they hit "experimental" status.

On one level I agree with you. But... if the problem is later, why can't we solve it later? What kind of hurdles are people fearing Google might introduce here such that it makes switching to another browser impossible in the future?

Put another way, isn't it OK for users to experience temporary discomfort and inconvenience? If it truly gets bad, someone else will eventually eat their lunch, and everyone (except Google!) is happy again. See: Microsoft.

One very obvious point which somehow hasn't been named yet, is security.

If Blink has a security vulnerability, like the recent WebSQL remote code execution, then in a monoculture that means everyone has this vulnerability.

Exactly. A week ago I read on hackernews how desktop linux failed because of diversity. Now I read the web will fail because of monoculture.

What do you mean by "fail"?

> how desktop linux failed because of diversit

Yes, but that was based on a comment that was twisted out of context, and is, moreover, demonstrably false.

> web will fail because of monoculture

Go ask a banana.

do not mix diversity with fragmentation

Google is much more at the reigns of Chromium than your comment perhaps illustrates. The only way to really innovate would be to make a full-fledged fork which would soon diverge enough to require as much development resources as Chromium, thereby negating many advantages of a common codebase. Also, even Chromium has many Google-specific features and integrations which make it worrying from a privacy perspective.

Lack of official support for Chromium on platforms other than OSX, Windows and Linux worries me a little.

Both FreeBSD and OpenBSD maintain large patch-sets to be able to build Chromium. [1][2]

I don't know the current situation, but historically some of these patches have had problems reaching upstream because Free-/OpenBSD is not officially supported[3].

[1] https://svnweb.freebsd.org/ports/head/www/chromium/files/ [2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/chromium/... [3] https://codereview.chromium.org/180743014/#msg3

Although the Chromium project is ostensibly open-source, Chrome is clearly closed-source. And worse, some Chromium releases have included (or at least pulled) closed-source blobs from Google.

So the whole thing is arguably suspect.

To me biggest reason is security. multiple options gives at least some escape route if one engine screws up. Other is breaking standards, but so far this doesn't seem to be a big issue because of the open nature of blink / webkit.

The problems really begin when a browser doesn't want to wait for a standards body. I realize the situation is different with WHATWG now than how this played out in the IE6 days. But when the dominant rendering engine decides to start adding features where the standard hasn't caught up yet, you're arguably no longer doing web programming, but rather Chromium programming.

This sort of thing boxes out other vendors/rendering engines and forces them to have to add non-standard features themselves. Vendor prefixes are not enough. If devs no longer test on non-Chromium platforms, vendor prefixes have to be adopted by non-Chromium engines or risk utter obsolescence. This is also true of Chromium forks. If a fork is a niche player, being open source doesn't buy you much because the Chromium governing body (i.e., Google) still has the lion's market share, and thus the decision-making authority for what the web should look like.

And who would use the forked rendering engine? Would web developers add the forked engine to their test suite?

Imagine the entire web (90%) can only run in Google Chrome and Google Chrome stops linux support. What then? Will linux not be able to render 90% of www? What if MS pays Google millions of $ to stop linux and Mac support?

Not a criticism of you but an observation: people will say a browser monoculture is bad but have absolutely no problem with a political monoculture.

> I feel like I’m missing something, because I keep seeing blog posts that tell me a browser monoculture is bad (and the irony of Microsoft saying this is nearly too much), but none of them tell me why.

For me personally, multiple independent implementations is a stamp of approval. It means that Google can't just sit on the standards committee, build something behind closed doors, and ship it, even if the result is open-source.

It means someone outside of that one company has to understand it, and be able to implement it. It can't be ridiculously complex, or have DOCX-style "just do what proprietary implementation X does" requirements. There has to be sufficient documentation. The implementations probably won't all have the same bugs -- I've heard avionics systems have multiple independent implementations for this very reason.

> Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows?

I fear it'll be more like Darwin. It's nice that XNU is "open source", perhaps, but nobody is taking advantage of this. I've never heard of anyone running XNU except as part of Apple's proprietary operating systems, and I've never heard of anyone forking it to run a custom version on their Apple hardware. I'm not even sure to what extent it's technically possible.

I would be much less worried if the single surviving browser engine were Gecko -- not because I think it's technically superior (I don't think it is), but because I trust Mozilla a lot more than I trust Google, or even Google+Microsoft. Mozilla is not good at design but they operate out in the open.

There used to be a BSD type distribution of Darwin. It's not been maintained in many years.

Seems like there's something called PureDarwin that's trying to do something with it now.

http://www.puredarwin.org/

People don't download Chrome because EdgeHTML-Edge sucks; they download Chrome because it's familiar, and ironically doesn't nag the person to enable half a dozen Microsoft's services one by one. There's two greater truths here: that some people are more comfortable using Google's services over those of Microsoft, and that the power of defaults matter, even when they feel skeevy to a part of the population. Google proved that defaulting to all the services enabled by default is reasonable not just with a discretionary application (like Chrome) but also when the user barely has any other choice on the device (like Android), and years of these defaults have resulted in a userbase that relies on them and seeks out the product for this reason.

It also shows that past precedent can lead you down a gauntlet of bad PR: Microsoft has tried to be pushy with many features of Windows 10 (telemetry, inking, online login, Cortana, always-online search) in the same vein that we've long seen from Google, but their strategy contrasts unfavorably against long legacy of a less invasive Windows. Google has pursued a policy of opt-out from the beginning, and by doing so they escape a fair bit a bad press.

Firefox has the worst of it: their users are the most discriminating, the hardest to please -- even if some of Mozilla's controversies were poor choices, the level of uproar was immense. Posts like this just encourage the migration of users driven by causes. This would be less of an issue if it were entirely community-supported, but Mozilla has paid developers and evangelists, and deriving revenues from a discriminating userbase is a challenge.

As a counter-point, I've had to set up Chrome with ad blockers even for computer illiterate family members and friends because they eventually have it installed anyway. Why? Not because they knew they were installing it, but because every time you visit "google.com" in Edge, you get an intrusive message that says:

"Switch to Chrome Hide annoying ads and protect against malware on the web [No Thanks] [Yes]"

And that then appears on every single search. And if you click no thanks, it reappears.

And then when they go to youtube, they see this:

"Watch YouTube videos with Chrome Google recommends using Chrome, a fast and secure browser. Try it? [Yes] [No Thanks]"

Again, every page load. It's a dark pattern. What about Gmail?

"Google recommends using Chrome Try a fast, secure browser with updates built in [No Thanks] [Yes]"

EVERY PAGE LOAD.

You'd think there'd be a super-slim version of uBlock that only blocked Google's nag messages to install chrome

Start a list...

Doesn't it already? I've never noticed the nags when using Firefox

I use Firefox with the vanilla uBlockOrigin. I don't notice any google nagging except on the google translate page.

To be honest, I think it's pretty bad that the company with the largest influence on the web is also the company that controls the largest web browser. Chrome should be moved to a different Alphabet company and Google forbidden from promoting it.

It's not limited to Google Search/Youtube. A few years back Google had an incentive program that would reward 3rd party websites to put up a "This page is faster in Chrome" banner. Not a regular advertisement, a separate banner.

I don't use Chrome, and can honestly say I don't remember the last time I saw one of these messages.

Granted, the browser i use is Blink-based. Probably has something to do with it, but it is still _not Chrome_.

Those messages don't appear for me in Firefox, but they do when using Edge. Clicking 'no thanks' sometimes dismisses them, however sometimes they come back at next load.

> they download Chrome because it's familiar, and ironically doesn't nag the person to enable half a dozen Microsoft's services one by one

More accurately, they install it because google.com, Gmail, YouTube, etc. will constantly nag you to install Chrome and will sometimes display errors telling you that a feature requires Chrome even though the browser you’re currently using also supports it.

This move by Microsoft may probably help Microsoft have Windows users using its browser, but I seriously doubt if it's good for the web.

There are people claiming that Microsoft could easily fork from Chromium, but honestly, do you see that happening in the next few years? Having read that Microsoft's Edge team was a very small one, I don't believe Microsoft will fork Chromium anytime in the next two or three years (no financial incentive, which could be a big motive, to do so)...and that's a long time to keep pushing the Chrome/Chromium way ("what Google wants for the web").

As an aside, I very much liked this article linked within, titled "The ecological impact of browser diversity" by Rachel Nabors. [1]

To all those who evangelize Firefox, please also see if you can donate money to Mozilla. It may seem like Mozilla has a lot of money (more than 90% coming from Google for being the default search engine added in the browser), but this is not enough, and could turn to be nothing if Firefox's market share becomes next to nothing and Google decides to pull the plug when the current contract expires. Partnerships with Bing (or other search engines that not many people use) may not bring in as much money to Mozilla.

Read about all the work that Mozilla does (aka "not just Firefox") in its "State of Mozilla 2017" annual report. [2] The audited financial report is here. [3]

[1]: https://css-tricks.com/the-ecological-impact-of-browser-dive...

[2]: https://www.mozilla.org/en-US/foundation/annualreport/2017/

[3]: https://assets.mozilla.net/annualreport/2017/mozilla-fdn-201...

So the only competitor to Google’s monopoly on web browsers is... funded almost entirely by Google? Yikes

While Safari’s desktop market share is minimal and it really only competes with Chrome directly on Macs. No one is going to use Chrome only features that don’t work on iPhones.

I hope you are right.

Why? Apple has been playing the game of vendor lock-in for quite some time now. How does it make the situation any better? Heck, they have changed - and set a nasty precedent - their hardware for this exact purpose.

Large companies usually don’t act with a single voice. The iPhone is what stopped IE’s ability to dictate what the web would work like — not entirely without help but it’s what forced companies to treat support for other browsers as mandatory rather than nice-to-have – and WebKit was a huge win for open source, eventually including Chrome.

That doesn’t mean that things like Lightning connectors don’t also happen but in the context of the web Apple has generally been helpful for fighting monoculture since it used to be a huge threat to their continued existence.

Thanks for your reply! Yes, I can see now how it would be beneficial in this case at least. :)

By the way, just came across: https://apple.slashdot.org/story/18/11/10/1656225/apple-bloc...

Ugh.

> No one is going to use Chrome only features that don’t work on iPhones.

Mostly facetious, but who except Americans cares about iOS anymore? Total iPhone market share is down to ~15% of smart phones worldwide. Android has the big lead now and doesn't look like it will relinquish it soon. Chrome only feature, works on ~85% of smart phones today? "Ship it," says the bottom line.

It’s not about market share. It’s about where the money is.

Being equally facetious. No one cares about a bunch of poor people buying $40 Android phones running 4 year old operating systems...

Look at the countries where iOS market share is above 30% and compare it to per capita GDP

http://gs.statcounter.com/os-market-share/mobile/europe

That feeds the point about market share though, at what point is iOS too much of a luxury brand that doesn't support the effort to get over that hump of "works in Chrome, ship it"?

"I don't care if the Maserati owner can't buy these wiper blades, because look how many more GMs and Fords there are on the road every day. I bet the Maserati owner flogs themselves if they accidentally even drive in the rain, how often do you think they replace their wipers?"

iOS market share, and it's luxury brand demeanor, leaves it at great risk. I don't know where that line is, myself, but pinning hopes on iOS preventing a browser monoculture seems increasingly desperate looking at current world figures.

No one is marketing “worldwide” with the same website. In the US, Europe, Japan, etc if you want to reach the middle class - you have to care about iOS.

You’re not talking about reaching people that can afford Maseratis versus Fords. More like the people who can afford a car vs people who can barely afford a bicycle.

If I was trying to reach poor people in developing countries the equation may be different.

Instead of funding Mozilla, perhaps funding the many non-Blink, non-Gecko browser authors out there would be more impactful? Even if it's indirectly through spreading responsible ownership of standards discussions and components like Skia/ANGLE/etc.

Disclaimer: independent browser author, unpaid.

Does your independent browser properly render a page like the following:

https://gitlab.com/gitlab-org/gitlab-ce/issues

There should be a left column wide enough to read the text, and some transient menus which appear when mousing over the links there, and a switch to icon-only left column when you scrunch the window size small enough.

I’d personally favor both — funding Mozilla as well as non-Blink/non-Mozilla browsers. We need stronger contenders for the present (like Mozilla) and stronger contenders for the future (others, assuming they’re still nascent and aren’t on the radar for most people). Though I support Mozilla for various reasons, I see value in supporting smaller competition that could ultimately help everyone (including Mozilla).

Please share your project and other independent browsers/engines. It’s been some time I’ve checked this space out (and I do know that I could also go to Wikipedia to get some information on this).

> To all those who evangelize Firefox, please also see if you can donate money to Mozilla

As a Firefox user for years I lost all the motivation to donate to Mozilla because of their mixed messages.

I would like my money to go to their engineering efforts, to make the best browser in the world. You could guess to what kind of "places" I don't want my money to go to. It's nice to advocate for the free web but in the end if your browser isn't competitive everything else will fall apart.

There's a lot of FUD with things like the Mr Robot "ad" (Mozilla wasn't paid for that) but there are legitimate concerns about some of their behavior. It wasn't so long ago that I clicked on anything Mozilla with joy, but now my brain bullshit detector is automatically deployed. I love reading about Servo and anything tech related but that's about it.

There are several comments on this post wondering why a browser monoculture is bad or speculating that a browser engine monopoly is inevitable and ought to be accepted.

Let's just replace 'browser' with OS (ironically the similarities are becoming more with each passing day) above... would we still say the same? Is an OS monoculture good, regardless of whether it is inevitable? Have we forgotten the power that MS had with Windows during the 90s and early 2000s before Linux, MacOS and Android became viable alternatives?

Given that browsers are becoming the new OS and VM, we need competition in this space more than ever, going forward. Let's not accept Chrome/Google as the One Ring.

Unfortunately that's not really a valid comparison at all. Browsers all try to stay compatible with each other. OSes do not in any way try to stay compatible with each other. Programming apps for Linux, Mac, and Windows requires entirely different code. Programming for Firefox, Chrome, Edge, Safari do not (or at least not supposed to unless you're used new APIs or edge cases)

You can't currently make an alternative browser in the same sense that you can make an alternative OS. An alternative browser would not use HTML, CSS, JavaScript. It would use something else in the same way that MacOS/iOS push ObjectiveC and Swift where as Android pushes Java/Kotlin and other OSes other languages and each OS as it's own UI API

I disagree. MS has recently pushed the “linux on top op windows” solution. Making windows programs run on linux has attracted plenty of ressources (commercial and unpaid): open framework clones, wine, steam play vm’s. The same can be said for osx. iOS and Android not so much though.

As people have observed historically, browsers have competing incentives - to support the most use cases, and to be better in some way than their competitors.

Supporting the most use cases is where you get the compatibility from.

Being better than your competitors is where you get browser-exclusive functionality from.

If something (e.g. ActiveX, Java, Shockwave, Flash, some new CSS that's not standardized yet, a new feature on some top 500 website, ...) works in your browser, that's a win for both goals - and if it works only/best in your browser, that's also a win.

Monocultures can be toxic in part because the disincentives to adding lockin (e.g. losing users and other negative feedback sources) get weaker/less likely as one participant becomes more dominant.

I'm old enough to remember the fun with "works only/best in IE/Netscape/...", and Microsoft's old Embrace/Extend/Extinguish policies. While I do not have any reason to believe any of the parties involved in browser development would behave pathologically, history suggests that monopolies in any space tend to eventually become pathological.

(I work for Google, not on anything browser related, all opinions above are mine personally, etc.)

> Let's just replace 'browser' with OS (ironically the similarities are becoming more with each passing day) above... would we still say the same?

From what I've seen, yes absolutely, as long as it is Linux.

precisely. I wholeheartedly agree with this statement as well. The differentiator? Linux, like Chromium, is open-source. I would welcome an OS monoculture with every OS being based upon a linux kernel.

Just so we're clear, I definitely do not agree with this sentiment.

I don't think I understand the desire that something be open source.

I feel like, if I wanted to, I could contribute to the linux kernel. All that I would need to do is submit pull requests, have it vetted, and gain reputation within that community.

Could you say that about any arbitrary pull request for chromium? Even if it was against googles interests to merge it?

Is your contention that I just fork it and compete with chromium with my PR integrated?

I don't view these projects as equivalent at all.

I'll echo tokyodude. Not a valid comparison in the least. The biggest differentiator I can see is that Windows is not, and probably never will be, open sourced. Chromium is.

I would place myself squarely in the camp of those that don't see every browser using Chromium under the hood as a bad thing. It makes every company that has their own browser invested in improving together, for one thing. Also, compatibility across browsers will only get better if that is the case, which is also something that people tell horror stories about from the time when IE was king.

The last time I enjoyed using the Firefox rendering engine on a Mac was back in the Camino days. I’d almost say that that browser is a better Mac experience than Firefox is today.

I’ve started using Safari and it’s actually pretty OK and the resource utilization is a lot better than Chrome (no fans blowing!). I empathize with Firefox making a big deal out of avoiding a monoculture but i really hope they’re figuring out how to do a better job on things like the Mac internally, because I don’t think that people are really going to use an inferior product as some moral statement.

Correct me if I'm wrong, by all means, but I recently read somewhere that Firefox is genuinely trying to improve it's MacOS performance in one of the new releases.

No sources, it was just in passing somewhere, but I distinctly remember it.

It may do, but there's still a long way to go. Multi-touch gestures that use system animations (or at least approximate them), certain aspects of UI design made to fit the macOS aesthetic and workflow better, and other things. My personal hope is that once the newest UI implementation settles down, there'll be some more love added to it.

Stuff that Chrome got pretty damned fast, I hasten to add. Whether people like Safari or not, it does set the standard for browsers on macOS because, unlike IE or Edge, it's actually a very good and __very__ well-loved browser.

This has been said about a litany of releases, and they don't really ever make a dent.

I cannot remember the number at this point, but there was one specific release recently that did seem to make a significant improvement for me on MacOS.

I used to have heavy pages hang here and there and really burn some CPU (Facebook, etc) and sometimes even freeze without loading completely. Now on the same machine, the latest Firefox works just fine and avoids those states completely.

It's still a long way from perfect, but I once thought Firefox unusable on MacOS and went back to Chrome, but now that I've tried the latest FF releases, I'm happy enough with the performance that I'm staying with FF this time around

The only remaining sites with poor performance are Google products, and I blame Google for that and am trying to slowly remove myself from all of their products.

According to the latest poll within Mozilla, over 50% of the developers use a Mac. I suppose they're experiencing the same issues first-hand, and that it's only the matter of time before they iron out the performance.

The web browser vendors have too much money. They have no incentive to keep the platform small. Google in particular, the cost to implement Blink is essentially meaningless to them, but it is beyond affordability for almost anyone else.

MS could easily shell the bill, but there's 0 reason for them to do that; by leveraging Chromium they get 500 millions USD worth of development for free every year.

What's the total money passing through the web? Billions, trillions?

The amount of money that is spent on browsers is such a tiny fraction of web-derived profit it is, in my opinion, surprising that browser vendors don't have more money.

Well they do give away browsers for free.

Well, Microsoft opting for Chromium will be a big win for Google. As Google has a strong hold on Android mobile user base, for many non-technical users what comes by default is the first browser (may be best browser). Google taps that privilege/monopoly/advantage to their use. Those who comfortably use Chrome in mobile device will obviously opt for Chrome in desktop as well. Because it simplifies their mental model of browser comfort. Microsoft might have done the same thing for decades, but it has been trying to come out of that image for the past of couple of years. IMHO Microsoft is no more an evil. I won't blame Google if it plays fair with respect to its Chrome browser in Android. In many Android phones we can't uninstall Chrome. If we use Chrome actively in Android, it pushes lot of notifications (they will say serving the user with relevant content, but to me its a ad/handle which intend to make me see pages where ads are again controlled by Google). Even in Desktop when i open Google's any of the services using browser other than Chrome, at least in the third world where i live, it suggests me to "Switch to Chrome". Nobody is forcing anyone. But it is very essential to tell the world that there is something better available.

The recent better one from Firefox: https://play.google.com/store/apps/details?id=org.mozilla.ro...

Those who comfortably use Chrome in mobile device will obviously opt for Chrome in desktop as well.

You make it sound like users know, or care, which browser they're using. Most of them don't. Most don't actually know there's more than one browser. They use the stock browser that's installed on their device, and they don't switch unless there's a reason to - eg their favourite websites and apps don't work.

In the case of Edge with EdgeHTML there are popular sites that don't work properly, and that means users seek out Chrome instead. Microsoft switching to Chromium will mean those users continue to use Edge because "it works properly" for the user regardless of the actual problem being the developers of those sites failing to write cross-browser compatible code.

I'm a bit sad that the choice and market for browsers is shrinking, and I think it's going to slow progress in web tech, but let's be honest here - the blame for Microsoft's very sensible business decision lies with web developers who fail to test their code in more browsers than just Chrome. If web developers did a better job there'd still be business value in developing a competing browser engine.

If there’s anyone at MS reading this, I’ll once again implore you to push for Edge to be open sourced, as it should have been before the initial announcement was made.

Yeah. This stuff matters. Firefox is more important than it's ever been.

I still remembered when i first time used Firefox in 2004, and it's like a life-saver to me to get out of the terrible Internet Explorer. What i want now, maybe from 2020, i could use Firefox, but as a replacement for Mobile App container.

I still remember when my Dad marched me over to his laptop, to boldly proclaim the new Internet Explorer 7 had TABS

He legitimately looked as though he'd unlocked some kind of arcane technology that mortal man should never have wielded

I still feel a little bad when I casually shrugged it off with "Firefox has had that for years". He looked legitimately shattered

Sometimes I still browse Digg (it's different now). Since the last Firefox update from a week ago which disabled Symantec certificates the site doesn't work anymore. I bet the day Chrome disables Symantec certificates they will immediately notice and fix it.

It's sad that in one week not even one of their people opened it in Firefox, and not many of their users either (there was just a couple of mentions on Twitter about this issue)

> Since the last Firefox update from a week ago which disabled Symantec certificates the site doesn't work anymore.

Is this the fault of Firefox or Digg though?

It's pointing out the mindshare and impact that Chrome has.

Chrome distrusted Symantec certs when 70 got pushed to stable (at the end of October)[1]. Digg shows NET::ERR_CERT_SYMANTEC_LEGACY error when I navigate to it. Firefox was supposed to remove the Symantec certs in 63 (also to be released at the end of October) but I guess they pushed it back a version[2].

All major browser coordinated to distrust the certs at the same time.

[1] https://security.googleblog.com/2017/09/chromes-plan-to-dist...

[2] https://blog.mozilla.org/security/2018/07/30/update-on-the-d...

Chrome also shows an error. The reason nobody at Digg noticed is that Digg is not https by default, so only people using certain extensions would hit that error.

This move is actually genius by Microsoft. They will negate the need to install Chrome on Windows. Microsoft will gain control of the browser market.

I don't think they want control over the browser market, just the browser users on Windows. People are less likely to ditch Edge if it is more compatible with the way Chrome and Safari work (including the ability to run Chrome extensions). That means they have more visibility and control over those users.

They’re also releasing Edge for Mac and Linux so sounds like they’re all in on their strategy.

How so? I don't believe the layperson really cares all too much about the underlying engine, it's more a marketing thing. And the IE brand is forever tainted.

Word of mouth. Ads. The media. Plenty of avenues will quickly frame why Installing Chrome is so yesterday.

One of the linked posts spent a great deal of time differentiating between the browser interface and the engine itself. The average user doesn’t understand the difference, so being told “Edge is more like Chrome now” doesn’t actually make it Chrome for them. Other than tricking user agent checkers from putting up the inferior browser warning (is that still a thing?) this won’t stop people from using Edge to install Chrome.

I think Google will continue to have a headlock on the browser market via the forced-inclusion of Chrome (and the other 20 non-removable apps of theirs they force on you) on most all Android devices -- like Microsoft once had with IE on Windows. Mobile is the market, most people don't even own desktop computers nowadays.

Even if that is true. Gaining control of the “Windows desktop browsing market” is at best a Pyrrhic victory.

63% of all browsing is done on mobile.

https://www.stonetemple.com/mobile-vs-desktop-usage-study/

Microsoft has already conceded the mobile space. They're doubling down on desktop dominance.

If they were doubling down on desktop dominance they'd be doing something more interesting with Edge than conceding it to the competition.

(Microsoft is doubling down on Azure and DevDiv, if anything.)

This seems only to put the desktop at risk, especially with (EdgeHTML-powered) HTML+CSS+JS as the "third pillar" of the original Universal Windows Platform strategy, this only seems to further feed questions about Microsoft's overall confidence in UWP and thereby that middle word, Windows itself. This decision is directly showing a weak flank to "Chrome OS". What's to stop Chromebooks from attacking Windows for just being the junk drawer of old Win32 applications and games around a Chrome OS knockoff?

There's certainly still a lot of value, especially in enterprise, invested in that "junk drawer", but is that enough any more? Yeah, there's just no way that this decision is doubling down on "desktop dominance".

What's to stop Chromebooks from attacking Windows for just being the junk drawer of old Win32 applications and games around a Chrome OS knockoff?

That’s all Windows has been for years. There hasn’t been anything interesting happening nor any serious money invested in writing PC software for well over a decade. The only non game companies making any money selling desktop software are Microsoft and Adobe.

That perspective is indeed why I think Microsoft is leaving themselves extremely vulnerable here (and I worry as tiny, tiny little shareholder). I don't think it is entirely true, mostly because of the giant amount of "dark matter" PC development that remains in the enterprise and industrial worlds, but it definitely feels true at least in the consumer space.

There is nothing that Microsoft can do. Personal computers are big, bulky and not as a convenient for what most people do with their computers most of the time.

Even from a corporate standpoint, enterprise deployments of desktop apps are cumbersome. That’s the reason that even corporate LOB apps have moved to the web. Besides a web site is the ultimate cross platform app.

It hasn't. Otherwise it wouldn't have developed a mobile Edge browser (also based on Chromium), and other mobile apps for Android and iOS.

Firefox has one feature the other browsers will never have - privacy.

Brave seems to go for the same, but with a Chromium base (currently in beta). They seem to de-claw whatever's left by Google.

Firefox has still some clear advantages over Brave, thanks to owning their engine.

A trivial example is the battery API. It's nowadays mainly used for tracking, but is an official webstandard. Mozilla decided to fuzzy it, so it lost its usefulness for tracking. Google didn't.

And I imagine, there's hundreds of similar examples at this scale, which as an average user you'll just never hear of.

One bigger feature is Firefox's Containers. It's based on work from the Tor Browser. Which also just illustrates what this partnership sometimes brings forth. Tor Browser is going to always be there, checking the Firefox code for privacy problems, and will suggest better ways of doing things, which Mozilla can just adopt.

For Chromium, there exist in principle similar efforts, like Brave, Iridium Browser, ungoogled-chromium, but these will always fight an uphill battle against Google and obviously Google isn't going to adopt and maintain their fixes.

Brave is an advertising company mixed with blockchain snakeoil.

Why should we trust them?

Why wouldn't Safari have the same feature? I'm not a huge fan of Apple's generally closed ecosystem, but acknowledge that they have unusual respect for user privacy.

> respect for user privacy

No US based entity can offer user privacy, as the government can force any of them to cooperate while requiring non-disclosure. The fact they don't use anonymous user data to offer internet services doesn't negate the fact that where most of us actually care about privacy, they don't have the power to actually offer it.

First of all, we’re talking about business practices and culture, not government coercion.

In any event, being a non-U.S. entity has less significance with each passing day with respect to the ability to insulate information from government. Consider that in the past decade, the U.S. managed to get the Swiss government to change its once-formidable bank secrecy laws.

If they never collect the data, or store it in a way that they don’t have the private keys, they can’t give it to the government.

If their primary funder, Google, threatens to pull their funding if they don’t ship them the information they desire, Firefox may end up no better than Chrome in this regard.

How many billionaires have made their fortunes through the web? Surely some of them care enough about preventing a monoculture to foot the bill for an independent browser development team - if not for profit, for the greater good. Consider it philanthropy.

>an independent browser development team

So Mozilla?

Well maybe another Mozilla? The point is the ecosystem needs variety and there are people who could afford to create that.

Firefox and Gecko are going to die because the vast majority of people do not care about layout engine monopolies. Corporations rely on the vast majority of people. What will probably happen is as Mozilla goes bankrupt, they will spin off Firefox's development structure to a more community driven approach. Then, Firefox and all of its derivatives will continue to live in Linux/Unix Open Source world. Let's face it, political software issues are developer centric. From there, Firefox will end up like Galeon and Gnome Web, slowly losing relevance, lacking modern browser features, and lose development support over the years because a layout engine is very complex and MUST have a corporate backing. Microsoft proved this themselves with their decision.

All of these articles love to fear their listeners by warning them of another IE monopoly situation. None of them seem to mention why monopolistic browsers are an issue, or even how history will repeat in this crazy modern internet world. The only point anyone's made is that security vulnerabilities will span across all browsers. With that logic we might as well write all programs in different languages, and use 20 different operating systems. Obviously that isn't efficient and neither is wasting development money on yet another layout engine. But hey, it's fun to worry about petty issues, so I'll keep reading these blogs.

The biggest danger to the web in terms of control right now is browser monopoly, not engine monopoly. And this move is probably the most effective way at combatting that. I think this is the right move at this time not just for Microsoft, but for the web.

Borrowing from a previous comment I made, think of it this way: do you think it helps or hurts Google to have every version of Windows come pre-installed with what is essentially already Chrome, except, of course, it will probably have Bing as its default search engine. Do you think the odds of people just using Edge to download Chrome and nothing else go up or down with this move? Do you think it helps or hurts Google to have most tech people not bother telling their parents to download Chrome anymore? There is significantly less control from "owning" an engine than owning an actual browser. I don't think I would have had much of an issue with the dominance of IE 20 years ago if I knew I could compile and modify (and release!) IE myself.

If you care about the state of search monopoly, out of control ads, and identity on the web, then you should be happy with this move. This is more akin to most browsers now having a common starting point. The problem with browsers is that if you truly want to make a new one you need to somehow replicate the decades of work put into the existing ones. What that means is that before you can exercise any of your noble privacy/security/UI/whatever goals, you must first make sure you pass Acid 1 and replicate quirks mode float behavior and etc. etc. etc. This is a non-starter. But now, Microsoft can launch from Chromium's current position and have a browser that can actually compete with Chrome. It's as if they've taken "engine correctness" off the table, and can compete on cool features or "we won't track you" or anything else. Websites will work in Edge by default, so if you like that one new feature in Edge, you can feel OK switching to it without compromising devtools/rendering/speed/etc.

Now I know that the initial response to this is "but Google will call the shots!". Not if the way this has gone down every other time has anything to do with it. Google's Chromium started as KHTML. When Apple based WebKit off of KHTML, the KHTML team had very little say in anything and they eventually forked of course. Then Google based Chromium off of Apple's WebKit, and once again, there was very little "control" Apple could exercise here. Sure, they remained one monolithic project for a while (despite having different JS engines which just goes to show that even without forking you can still have differentiation), but inevitably, Chromium was also forked from WebKit into Blink.

And there should be no reason to think the same won't happen here, and it's a good thing! Microsoft in the past couple of years has demonstrated amazing OS culture. I can't wait to see what the same company that gave us VSCode is able to build on top of Blink, and eventually separate from Blink. Ironically enough, the worst thing that could have happened to Google's search dominance is have Blink win the "browser engine wars": we all agree Blink is the way to go now, so we can all start shipping browsers that at minimum are just as good, and won't auto-log you in, or have their engine set to default, or etc. etc. etc.

that is a very interesting take on the subject.

> I can't wait to see what the same company that gave us VSCode is able to build on top of Blink, and eventually separate from Blink.

The situation here is very different from WebKit and Blink. Google was already the plurality contributor to WebKit at the time of the fork. By contrast, Microsoft has contributed virtually nothing to Blink, and they intend to be identical to upstream Chromium. Microsoft is not going to fork Blink.

Blink is completely controlled by Google. (98% of Blink patches are reviewed by a Google employee.) This means that Google has complete control over the direction of the Web platform. While Google may not be able to set the default search engine in Edge, it has and will exert more subtle influence on the Web as a platform in ways that benefit Google. (Just to name one example, Chromium has deployed whitelists of Google properties for NaCl support.)

“Subtle control of the web platform” is strictly better than the explicit control of the web platform and the web browser space the currently enjoy. Microsoft’s IE and Edge together currently have just 10% market share, compared to Chrome’s ~70%. Step 1 to winning back a meaningful amount of control over the web platform is making a browser people actually use. And if in the meanwhile you can win other important battles? Amazing!

I feel people don’t analyze this move realistically in the current context, but instead compare it to some imagined magical alternative where we snap our fingers and have a fresh new viable competitor or people just decide to switch away from a browser most people like.

Regarding the specific example you gave, I’m fairly certain Microdift’s wrapped Chromium can exclude participation to those lists. And frankly I’d be surprised if they didn’t. Microsoft didn’t sign on Google as an OEM provider of a browser for their OS, they are building their own browser on top of Google’s engine. Im not super worried about Microsoft being bullied, they’re probably the best suited to do something like this in a defensible way.

Why? Because the W3C is a factory the never stops churning out specs.

It's quite telling that even Microsoft was not able to keep-up with the complexity and decided to piggy-back on the biggest investor.

If we want less mono-culture, the first thing to do is to bring the complexity down to something manageable.

I'm not sure this changes as much as people keep saying. Microsoft isn't completely abandoning browser development, and it will still have (sometimes strong) opinions on the development of the web.

The conversation though will shift from conversations in external organizations between stakeholders, to conversations in a shared codebase between stakeholders.

In some cases this could be better, as it means we will have fewer occurrences where there's agreement on a feature, but implementation lags in 1 browser. Instead, adoption of many features should now be quicker, while debate about larger or more controversial features will still exist.

Meh. I don't buy it.

First of all, individual boycotts will never, ever overcome a collective action problem, so a fundamentally futile solution is being proposed here.

Plus, this is only bad if Google act destructively evil and no one steps in to change it. If the endgame is control of Chromium being passed from Google to a neutral foundation -- which I suspect it will be -- then everyone wins.

It's always seemed inevitable to me that one browser engine will win out. This is the way of all web technologies. Should we go back to competing variants of (proto-)JavaScript to prevent web monoculture, too?

> It's always seemed inevitable to me that one browser engine will win out.

I think it should be that one competing _standard_ will win out. Ideally we can have infinite number of browser engines, as long as each one implements all widely used standards correctly. We already see this with most websites working fine whether in chromium or firefox. The only incompatibilities (in theory) should come from bugs or new standards/experiments which haven't been widely adopted or implemented yet.

The same for javascript - multiple implementations of a js engine is fine, as long as they all implement the ES* standard.

Also if everyone moves to a Chromium engine monoculture, what will happen to innovation? eg. Mozilla has made some major progress with it's work with Servo.

> If the endgame is control of Chromium being passed from Google to a neutral foundation -- which I suspect it will be -- then everyone wins.

There is zero chance of that happening. Like all public companies, Google acts in its own self-interest. Google controls Chromium, and there is absolutely no benefit to Google to hand control of Chromium over to an outside entity. 98% of all patches to Blink are reviewed by a Google employee.

If establishing a foundation were going to happen, then it would have happened when Apple and Google were still collaborating on WebKit.

I wouldn't say the chance is exactly zero - if Google's monopolistic behaviour surrounding Chrome (the "install our browser!" nags on their web properties come to mind) get too egregious, they may be forced to divest via antitrust law.

I know there is a lot of hate for Safari on HN ( Still don't understand why )

But I wish Microsoft worked with Apple and bring Safari / WebKit to Windows, and invest in Webkit instead.

( Blink and Webkit are now pretty much different Engine )

In the distant past, Safari was officially available for Windows.

Can I question the orthodoxy on this one?

Suppose WebKit or Blink are the one engine that everyone uses. Do you know how much uncertainty and effort that will save around the world that goes into browser compatibility and quirks? Look at the x86 architecture or POSIX as well.

Here is my serious practical question: this is open source, so if you want to make some extension, you should be able to distribute it. And if it becomes so popular as to be merged into the core, or included with the main distribution, then it will be.

It seems on balance, this would be a good thing.

it's more complicated than that though.

Nobody is lamenting the loss of the edge engine. Things like choice of video codec, drm module, etc have shown is it's a good thing to have a few different vendors with a seat at the table for standards.

Most important of those is Firefox.

x86 and POSIX are actually great comparisons to the current state of browsers. They all have well defined standards that everyone should follow in theory. In practice CPUs have bugs[0] that kernels and applications make a lot of effort to work around. There are also enough implementation/non-compliance quirks in POSIX[1][2] implementations to matter when porting. Just like all of the web standards, x86 and POSIX don't solve the compatibility problems that come from innovation.

[0] https://wiki.osdev.org/CPU_Bugs

[1] https://personal.opengroup.org/~ajosey/tr28-07-2003.txt

[2] https://en.wikipedia.org/wiki/Linux_Standard_Base

I think Microsoft just wants to give up on the browser market/share/innovation (for business reasons ofcourse </snark>). They just needed to have a default browser installed on their system and hence just wants to rebrand chromium and drop it in their default installation.

If they really cared, they could have adopted Gecko/Spidermonkey atleast.

Author starts by saying NDAs are useless, and he keeps secrets better without them... Then in the right next sentence, he shares how he learnt about a big secret from a friend at Microsoft without any NDA!

The biggest mistake we've ever made is not realising that Google used to be called.. SkyNet.

Just my two cents

People keep telling me that Firefox is super fast!

But it's slower than Chrome and my laptop runs hotter.

Sorry.

I find it kind of hilarious that people seem to think the solution to the Chrome monoculture is them personally switching to Firefox and then writing a blog post / comment / tweet about it. It's like saying we need to get serious about climate change, so you're going to start cycling to work, and encourage your friends to do the same. If that salves your conscience, then great, but your individual actions are statistically irrelevant.

There are systemic trends and market forces at play here involving billions of people. And nowhere amongst the significant forces and trends will you find "there are insufficient nerds evangelising Firefox". Hacker News can upvote as many as these kinds of articles as it likes, but Chrome's market share will continue to grow until there is something far more substantial to stop it than philosophical objections by tech insiders.

So when MS controller the browsers we threw our arms in the air. But when google controls it we just sit here and go meh?

I didn't say the concerns are wrong, just that repeating them again and again, mostly within an echo chamber of tech people, will do nothing to change the facts.

I don't think people should sit there and go meh. They should just be realistic about what actions will and will not make an actual difference.

How does the next default Windows browser being forked from Chromium mean Google controls it?

You know what open-source is, right?

People threw their arms in the air because IE was substantially behind other browsers in stability and capabilities, and all their new features were IE-specific APIs that didn't work anywhere else.

Chromium is an open-source project that largely follows IETF/W3C/ECMA standards.

The two are not even remotely comparable.

It's great that it follows all these standards, but the browser (due to recent changes) and the company behind it doesn't seem to follow some necessary ethical standards.

It's open source, the recent changes you mention (which I'm not aware of, a reference to these changes would be nice) can be reverted and the ethics of the company behind it aren't really relevant because it's an open-source project, the only way Google really benefits from it's use is if they receive contributions back to the Chromium project, which also benefits everyone else.

We only started caring about Microsoft when they stopped updating IE up to the point it was very buggy, non-standard compliant, outdated and insecure. Then Firefox came along and gave us an alternative. Chrome might also be pushing their own standards a bit too hard, but it is fairly standard compliant, secure, cross-platform, up to date and actively developed. So of course we don't care so much.

> I find it kind of hilarious that people seem to think the solution to the Chrome monoculture is them personally switching to Firefox and then writing a blog post / comment / tweet about it.

That's how change starts. "First they laugh at you..."

> nowhere amongst the significant forces and trends will you find "there are insufficient nerds evangelising Firefox".

Were you around when nobody knew what Firefox was?

Yes, my first browser was Mosaic, and I've been working as a professional web developer since before Firefox existed.

Firefox benefitted from years of stagnation and neglect of IE by Microsoft. And even then, when it was clearly the superior product, it took years to gain a significant portion of the browser market, and it still never managed to get much over 20%. Only Google, with the most popular website on the planet, and billions of dollars to spend, managed to actually dislodge IE.

As things stand, Chrome is not stagnating or neglected. Firefox is a good browser, but it is by no means a clearly superior product. There is a vastly larger number of deployed PCs, using Chrome as their default browser, than there was in the early 2000s. Mobile has replaced the desktop as the dominant consumer computing platform, where installing and using a replacement browser is far less likely. There are far more apps and content optimised for Chrome than there ever was even for IE, and the quantity is expanding all the time.

For all these reasons, and more, I am convinced that advocacy and evangelism alonge will not succeed to change the situation, and such efforts, while noble-minded, are mostly a waste of time.

But without healthy competition it's quite possible that Chrome will also start stagnating..

Nerd evangelism might not get something to 100%, but it can make something large enough to matter. Linux on the desktop matters, for example, because nerds like it and talk about it. The fact that some single-digit percentage of people use it means that the duopoly doesn't have absolute power.

Firefox, even in single-digit percentages, affects the ecosystem in the same way. If there weren't a choice, the browser would gradually turn into a cable TV interface.

I'm not going to use Firefox for development and I'm not going to install Firefox for my family members, simply because Chrome is better for both scenarios. Firefox is pretty good, but Chrome is just better.

Instead, I send Mozilla some money every month (a small amount), because I still care that Firefox continues to be developed.

What would Mozilla have to do to make their browser better than Chrome?

For me, as a developer, it boils down to the Web Dev Tools (Elements, Console, Network panels), which keep getting better and better.

For my family, Chrome is on desktop and their phones, everything synchronized. Chrome autoupdates without bothering them. Chrome is simple and it just works for them, and everything works in Chrome.

Please don't downvote me, I've been supporting Mozilla with monthly donations for years, and after Edge switches to Chromium, I'll probably increase the amount ;-) And I invite more of us to do the same. :-)

All of those things are available on Firefox, which is why I asked. There are a diminishing number of features not available to Firefox users at this point.

What I would like to see is some kind of "white-list" browser - I think it's our best chance to keep an ad-free environment. Maybe it is a bad idea in general to allow a remote page write pixels to your screen: images, videos, text and now applications

It is nice that the web is open (at least reasonably), but maybe raw JS, HTML and CSS is too general? The most valuable webpages have simple designs and are liked because of their content, like

  - wikipedia.org
  - HN
  - stackoverflow.com
  - maps.google.com
  - ...

These pages could implement

  - Knowledge-Base
  - Topic-Comment-Community
  - Answer-Response-Community
  - Interactive-GIS

specifications, that obviously do not exist. E.g. if a newspaper implements a hypothetical "Newspaper-Specification" it would have to provide original, sourced content containing text, images, audio and video via some API (which is often already the case when single page apps fetch content client-side via e.g. JSON). There would be no visual difference between reading "The Guardian" vs. "USA Today" or browsing "OpenStreetMap" vs "Google Maps" as content would be rendered on the client.

>Maybe it is a bad idea in general to allow a remote page write pixels to your screen: images, videos, text and now applications

Computers have been doing this since the 60s, at least, in some form or another. I don't think you want to live in a world where the very idea of networks is considered harmful. Where all of the software you consume has to be loaded from physical media and the internet and any network connected device just doesn't exist. You couldn't even have cellphones.

We don't need a "whitelist" browser - you simply choosing not to visit sites you don't want to visit is already a sufficient whitelist. Having "specifications" that websites and authors would have to enforce based on content would make the web less free.

Websites are software. Software authors have the right and the freedom to write whatever they like, any way they choose, up to and including the UI. The Guardian being able to make their own decisions about how to implement the web versions of a "newspaper" - including design choices which might differentiate them from USA Today, is part and parcel the same sort of freedom that any author of any work, software, literary, music, what have you, enjoys. That HTML, CSS and JS don't step over the line from describing content to making editorial decisions about content is a feature, not a bug.

Maybe I have expressed myself unclear, but I don't want to advocate against networked software and loading resources over a network in general. I would like to have a more "typed" API to networking services (including web-pages) that provides sufficient information to render the application on my client - the term "whitelist" may indeed be a sub-optimal term.

> Having "specifications" that websites and authors would have to enforce based on content would make the web less free.

We already have enforced specifications (HTML, HTTP, TCP, ...) and they did make the web free, as you could and can participate, when you implement these specifications (at least to a sufficient degree). However we could go further and provide specifications for more high-level tasks.

Consider the problem of going from A to B via public transport. Cities with a working public transport infrastructure normally provide a webpage that allows you to search for routes and reporting journey time, cost and additional information. However these webpages are more or less convenient to use and every transportation provider has to implement its own shitty webpage. Hypothetically it could implement an API that provides this information and the "Browser" has its builtin GUI (configurable by the user) to access this information.

> Software authors have the right and the freedom to write whatever they like, any way they choose, up to and including the UI.

I am more talking about users who should have the possibility to access the information they seek in an uncluttered way. And we can keep stuff like <canvas>, so you are still able to draw your pixels.

There would be no visual difference between reading "The Guardian" vs. "USA Today" or browsing "OpenStreetMap" vs "Google Maps" as content would be rendered on the client.

You're describing Reader Mode, which most browsers already have.

Honestly I just see all this, even despite the author claiming taking time to "mull it over", as a knee-jerk reaction. There is little evidence that MS changing to Blink/V8 will have any tangible impact on the web.

Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser.

The garbage rhetoric that Mozilla and their supporters have been spreading is pure FUD:

> By adopting Chromium, Microsoft hands over control of even more of online life to Google.

MS' new default browser being based on Chromium does not give any additional control of online life to Google. They're open-source projects that, while Google manages, does not have absolute control over the consumption of. If Google did ever try to muscle control on Chromium like they've been doing with Android, Microsoft could simply fork it without the hostile Google changes.

If anything I see this whole thing being beneficial for the web in the long run - now instead of MS engineers pissing their time and effort down the drain on a dead browser and needlessly fragmenting the market with engine differences, even if people don't use the default Windows browser Microsoft's engineers can contribute to and benefit the web by contributing their improvements upstream to the Chromium/Blink/V8 projects.

> Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser.

I don't have much love for MS, but this is just wrong.

XMLHttpRequest, the precursor to fetch, pretty much allowed "web 2.0" to exist. Now we use fetch, but they introduced it first.

box-sizing: border-box, a much better way to reason about the CSS box model, is almost always introduced as "the way Internet Explorer had always done things in older versions and quirks mode." Surely its existence in IE (and the experience people had w/ CSS there, preferring its box model) had some historical weight in this property coming about?

Lastly, and something still not standardized: setImmediate. Lots of libraries currently have to polyfill this with MessageChannel, postMessage, and other hacks. Clearly there's high demand for it.

There are thousands and thousands of APIs, properties, attributes, functions and so on for web programming. Holding up a few examples of past accomplishments from long ago is no defense for IE and the widely known vulgarities.

You seem to have missed the part of my comment that said "since IE6"

AFAIK the box-sizing box model you mentioned was implemented since the beginning of Trident, well before IE6 came about.

XHR was available from IE5 onwards (only accessible via ActiveX object, it didn't become available as a native window property in JS until IE7 but the feature was still available), so again isn't "since IE6". If you think whether it was available in native JS matters, note that Mozilla had a native JS XHR object available in 2002, well before it was available in IE7 in 2006.

I specifically mentioned "since IE6" because that was the point at which Microsoft had decided they'd won the browser war, and ceased to innovate. From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features.

setImmediate is not standardised for good reason, there are already more appropriate use-case specific solutions: use `requestAnimationFrame` if you are working with animations/visual changes use `postMessage` or WebWorkers if you are working with transporting or processing heavy data

There's no browser use-case enabled by `setImmediate` that isn't supported by one of the above. It does however make sense for `setImmediate` to be implemented in node because a node environment lacks the two APIs mentioned above and doesn't really have any way of achieving the desired outcome short of forking child processes.

> You seem to have missed the part of my comment that said "since IE6"

IIRC the pointer events specification[1] came from Microsoft and is implemented in Chrome and Firefox (just checked and found setPointerCapture in devTools-- yay).

It allows developers to use a unified approach that can work for various pointer devices. I can confirm it does just that in Chrome and am waiting to hear back from someone who will test it with multi-touch on a surface pro.

That API was released well after IE6.

[1] https://www.w3.org/TR/pointerevents/

I see you have never had to implement Promises in userland. :)

setImmediate is one of the more popular polyfills in fact, all the workarounds you mentioned either have downsides or are ugly hacks. It's useful to anything that has a scheduler. Like Vue for example. Maybe someone should tell Evan You that it doesn't make sense to need setImmediate?

https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795f...

Check the download counts:

https://www.npmjs.com/package/setimmediate

https://www.npmjs.com/package/next-tick

https://www.npmjs.com/package/set-immediate-shim

https://www.npmjs.com/package/core-js#setimmediate

> From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features.

There are definitely examples:

IE8 was the first browser with separate content processes (before Chrome was announced).

CSS Grid was heavily pushed by MS (and shipped, prefixed, in IE10).

Ultimately, being in a game of perpetual catchup in unsurprising when they stood still, with only an absolute minimal amount of work happening, for three years, while other browsers continued to march forwards.

It's not just the interregnum/break that made it a game of perpetual catchup, though. Google certainly helped a lot to keep the goal posts moving. Web SQL, SPDY, QUIC, VP8, VP9, WebRTC, etc and so forth, are just some of examples of Google pushing half-finished standards into Chrome, then encouraging devs to use them (even in prefixed forms, where applicable), well in advance of standards processes.

It's easy to be "standards compliant" when you are the ones building the standards and everyone else has to work to support your bugs/mistakes/half-finished backward incompatible solutions, because real world sites already rely on them. (That's exactly the IE6 problem in a nutshell.) When many of those real world sites that folks rely on are Google-owned properties themselves (looking at you, tube), there is almost no way to keep the goal posts from moving.

The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered for a long time to come. But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does".

This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language.

What did we really expect from the way so-called web standards are created? WHATWG (who write the HTML5 specs and call this a "standard") pride themselves in creating a "living standard" where nothing ever is locked down, and ECMA has put itself up to creating yearly JavaScript updates (after the language has stagnated for 15 years). W3C creates an enormous amount of CSS specs and has said goodbye to versions/levels and profiles a long time ago. The result is that there is no reasonable spec as an implementation target for browser development. Those in the game have closed the door behind them.

Firefox has, unfortunately, a shrinking user base, is financially dependent on Google, and might suffer from problematic incentives in the future.

The web is in tatters.

> But if only a single browser will be able to display it

Chromium has no intrinsic power. If Chromium and Google disagree, the latter can easily break off. The browser political landscape is fragmented as ever.

> the latter can easily break off

How? Developing a browser takes hundreds of millions of dollars, and Google is currently providing all the funding for that (meaning they decide what changes get made). Who has the necessary resources to fork Chromium, and would actually be willing to do it?

Microsoft, of course.

> But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does".

Safari and Konqueror still use WebKit, Firefox still uses Gecko, so not "only a single browser will be able to display it", but multiple maintained browsers using 3 different implementations will still be able to display it. Additionally, even in that worst-case scenario of Chromium/Blink/V8 becoming the de-facto implementation and making standards irrelevant, it wouldn't be "whatever Chrome does", but "whatever Chromium does". Being in that situation Chromium would be in use by everyone, so if anything that only places more power in the hands of the community because Chromium is an open-source project. Why should every browser have their own competing (and often incompatible) implementations of each standard to the detriment of the web? How is that more beneficial than browser developers all collaborating on a common, shared implementation? Very rarely have implementation-specific differences between browsers benefited the web, generally such differences will either remain implementation-specific and become redundant (e.g. all the IE-only APIs) or are experimental implementations of a standard that's only in draft state and will be updated to be consistent once the relevant standard is finalised, in both cases they're just neat toys for developers to play with that aren't practical to employ in production (because they'll only work for a fraction of viewers).

> This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language.

This is a fantastic and wonderful result for the web as we know it. With less implementations to support, the web would be substantially faster and more efficient. Because why would we want to load our asset bundles with megabytes of polyfills and shims just so things don't explode on the odd chance someone tries to view your website in the default browser of their OS that's either outdated or poorly implements specs?

If every major browser ran Blink/Webkit + V8, the web could be written once in native ES2018 javascript and consistently execute anywhere. This is not the case today because implementations behave differently, you can't write a webapp purely following the established specs because the specs are inconsistently implemented. For example `navigator.mediaDevices` API works differently across browsers, some browsers support-sub features that others don't etc. This ends up requiring checks and work-arounds that waste processing power to execute and human resources to implement.

Making some WebKit derivative the de-facto engine would be very short-sighted. There will come a time, maybe in a distant future, when we need to get rid of C and our whole approach to mobile O/Ss, CMOS, and everything else. In any case, the situation we have now -- that of the web getting out-of-hand -- is what WHATWG, W3C, and co. should have avoided. They totally fubar'd it instead, so the world has to move to something else. HTML is a means to an end, not an end in itself. HTML hasn't changed much since the beginning, although it has been supplanted with the disgrace that is CSS and JavaScript. Can you seriously recommend to write a dissertation, a school book, a law text, a contract, or anything that matters in HTML at this point?

WebKit isn't written in C, but in C++.

Why is this such big news? No-one I know uses Edge as their daily browser. Based on the Google Analytics data of the various apps I work on, the usage for Edge is so small that it is basically irrelevant. If we are concerned about a lack of browser diversity, why weren't more people using Edge to being with? Or is it all the people who are now chanting "Use Firefox" are the ones who used Edge and feel cheated somehow?

It's not about the browser, it's about browser engines. Edge will still exist, but EdgeHTML will not. We're down from four major browser engines to three, with one clearly dominating the market.

OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many disappointed [2] (see comments in both threads universally deriding the decision).

The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-the-browser native C implementation that is SQLite).

Anyway, now that Firefox has become less relevant than ever with Microsoft's adoption of Chrome, I wonder if there's any chance that WebSQL will live on despite its deprecation? After all, it's still available in Chrome and Safari, which dominate the browser market.

IndexedDB is fine if NoSQL is how you store your data, but an absolute PoS if you want to work efficiently in a relational model with joins, grouping, etc.

Such a shame, every server-side language under the sun compiles to javascript now; imagine being able to share SQL statements between client and server; being able to aggregate data, count & sum with reckless abandon. Instead we have to do it all by hand in javascript, such a step backward [3]

/rant

[3] https://news.ycombinator.com/item?id=9978540

[1] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

You couldn't share SQL statements between the backend and the frontend. It's for the same reason it was shot down: SQL implementations are incredibly varied.

Limited to a certain subset you most definitely could use the same statements (obviously not CTEs and the like).

Ideally you'd have a translation layer, so instead of writing error prone string-y SQL, you'd have a type safe DSL in the vein of LINQ to SQL, Esqueleto, Slick, Quill, etc. that generates approriate SQL based on the target driver. That way you write the same query once, with the same model, and dispense with the inefficient square wheel that is IndexedDB + javascript.

Are you aware of the recent WebSQL remote code execution vulnerability?

That's a pretty good reason for Mozilla's decision.

Did we really need the stupid viewpoint on non-disclosure agreements? Like cmon, don't take it too personally that a company might want to try and cover its own arse when giving you access to sensitive information.

It still shouldn't change your character with regards keeping secrets so why does it matter?

Reply on news.ycombinator.com