3 ms·

> 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

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

rictic 8y ago
> 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.

rictic 8y ago

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