5 ms·

> 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

> 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 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 https://twitter.com/cpeterso/status/1021626510296285185

gsich 8y ago
Google Earth has a desktop version too.
proaralyst 8y ago
They use a polyfill for Firefox on Youtube because of a never-standardised feature too: https://twitter.com/cpeterso/status/1021649116391075840 https://twitter.com/cpeterso/status/1021649116391075840
rictic 8y ago
> 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 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-cross-browser-7338e0f46278 https://medium.com/google-earth/earth-on-web-the-road-to-cro... https://developers.google.com/web/updates/2018/02/meltdown-spectre#high-resolution_timers https://developers.google.com/web/updates/2018/02/meltdown-s...
- danShumway 8y ago
  > 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?
- pritambaral 8y ago
  > 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.

gsich 8y ago

Google Earth has a desktop version too.

proaralyst 8y ago

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

rictic 8y ago

> 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 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-cross-browser-7338e0f46278 https://medium.com/google-earth/earth-on-web-the-road-to-cro... https://developers.google.com/web/updates/2018/02/meltdown-spectre#high-resolution_timers https://developers.google.com/web/updates/2018/02/meltdown-s...

danShumway 8y ago
> 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?
pritambaral 8y ago
> 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.