Am I understanding this right? It didn't actually slow it down... it just didn't speed it up for those browsers when it added features to make it faster for Chrome?
From the fine article: "YouTube's Polymer redesign relies on the deprecated Shadow DOM v0 API only implemented in Chrome. You can restore YouTube's faster pre-Polymer design with this Firefox extension..."
The new version uses new features which only Chrome has implemented. For IE it still serves the old version, but for FF and Edge, it serves the new version together with a compatibility layer that makes it slower. So they could have just served the old version, but they decided to serve a new, slow version instead.
The key point here is that they made it in a way that uses a deprecated API that will not be implemented anywhere else but in Chrome. Even Chrome own platform status page[1] says v0 is deprecated and scheduled for removal. By making their web properties rely on APIs which are no longer in standards tracks, they essentially harm the interoperability of the web. It is very comfortable when you control both extremes of some web property (the video sharing platform and the browser) to make sure they work well together and let the rest of the world play catch up.
We have standards for a reason, so that things such as this are avoidable and you can use your browser of choice, whichever that browser is, on the web. By allowing their web developers to play the "chrome-first-and-foremost" game, they make the net-positive side-effect of acquiring more users for their browser, after all, who wants to use a slower browser right?
This seems like a poor choice of technology rather than an outright nefarious decision. Polymer [0] uses the shadow dom api [1] extensively, but shadow dom v1 still isn't fully implemented across all vendors and shadow dom v0 is deprecated and slated for removal in April 2019 [2].
This feels more or less like some premature dogfooding of Polymer. It probably would've been advisable to serve the old version until modern non-Chrome browsers caught up, but Shadow DOM v1 will be implemented eventually so my guess is they made the decision to transition those users now.
I read a really good take once that I can't find anymore, but the gist was: sometimes a company knows about a poor decision or a bug, and just leaves it in because it gives them a competitive edge.
How can you ever know someone's intent? I don't think it makes sense to assume malice in this case.
- Because YT makes money on eyeballs and runs on every terrible device specific browser under the sun. Making users experience worse intentionally only really hurts them.
- Because we're in a forum of devs that are all about chasing the latest features and polyfilling everywhere that doesn't have them -- it's practically SOP. I totally believe performance problems like this wouldn't get caught in testing when everyone has a corp network connection and powerful laptops/workstations.
Deliberately and knowingly made decision that hurts already barely existing competition is not an innocent polyfill mistake. It's more like policy level abuse of dominant position to transition users to Chrome from non-Chrome browsers.
I am with you. I want to see a world where Google is nothing more than a search engine.
But in this case I don't think they are at fault. As far as I understand it they didn't they just over-optimize for their own browser, which is not quite the same as degrade performance on other browsers on purpose.
Look at where the internet was before google and all the tech that improved because of google. I think many people underestimate how much of the internet, web server hardware moved forward was directly or indirectly because of google. And many if not all the major web based companies that exsist is because of the tech google introduced and open sourced.
I don't know what to think here. On one hand, Google is writing code to make YouTube faster on its own browser. This is reasonable. On the other hand, Google is also using its dominance in internet video streaming to make Chrome look like a better product than the others. This is anti-competitive.
It is wrong to optimize for your own ecosystem, without optimizing for others?
It's a symptom of a greater problem, which is that Google (the search engine) owns Chrome, Youtube, Android, Maps, Gmail, and a whole host of other services that are tenuously linked at best (outside of the fact that all the data gets fed into advertising algorithms)
Quite frankly, the company should be broken up forcibly by the government. All of these services should be profitable on their own, not used as loss leaders to grab as much ad data as possible and stamp out any sort of competition.
Or they would be forced to charge for their services and actually compete in the market. Fastmail/protonmail exist, there's no reason Gmail couldn't charge $10/mo and provide the same services
> He notes that YouTube "still serves the pre-Polymer design" to Microsoft's Internet Explorer 11, which launched in 2013 and has been replaced by Edge, and suggests that Google could have taken the same approach with Edge and Firefox.
Okay, but without new features? Does the pre-polymer design served to IE maintain feature-parity with the shadow DOM (or its' polyfill equivalent)? Because YouTube never _seemed_ slow to me on FIrefox, but I'd hate to miss new features.
What new UI features does a video-catalogue website really need, though?
They've reached or passed maturity and are adding dubious features like the miniplayer that keeps playing the video you've just back-buttoned out of. Things that benefit advetisers, not users.
The truly beneficial features should be server-side; culling those awful 'Top 10 Shocking ...' videos from my recommendations, for example. Or realising that just because I watched one programme about military re-enactment, once in ten years, I probably don't want to watch another 30.
So basically the Mozilla exec is saying that the Chrome implementation of the Web Components W3 standard is a lot faster than Mozilla's implementation.
Because that is what YouTube's frontend is currently running under the hood: Web Components and Shadow DOM. Both W3 standards. No magic at all.
FTA: "YouTube's Polymer redesign relies on the deprecated Shadow DOM v0 API only implemented in Chrome". Shadow DOM v0 never was a standard, merely a proposal in a draft.
Although it's true that only Safari and Chrome (through WebKit and Blink) currently have the best support for Web Components, and polyfills are required for everything else due to flaky support.
Google even mentions this in the Polymer README:
"Web Components are now implemented natively on Safari and Chrome (~70% of installed browsers), and run well on Firefox, Edge, and IE11 using polyfills. Read more below."
Well, if I check the source of the desktop_polymer.js on Youtube I see v0 API calls in it, and not their v1 equivalents. (e.g. createShadowRoot vs attachShadow). I might be missing something, since I obviously don't understand how all of that works, but it seems supportive at least?
31 comments
[ 2.9 ms ] story [ 63.3 ms ] threadWe have standards for a reason, so that things such as this are avoidable and you can use your browser of choice, whichever that browser is, on the web. By allowing their web developers to play the "chrome-first-and-foremost" game, they make the net-positive side-effect of acquiring more users for their browser, after all, who wants to use a slower browser right?
[1]: https://www.chromestatus.com/feature/4507242028072960
This feels more or less like some premature dogfooding of Polymer. It probably would've been advisable to serve the old version until modern non-Chrome browsers caught up, but Shadow DOM v1 will be implemented eventually so my guess is they made the decision to transition those users now.
[0] https://www.polymer-project.org/
[1] https://www.polymer-project.org/3.0/docs/devguide/shadow-dom
[2] https://www.chromestatus.com/feature/4507242028072960
How would you tell the difference?
- Because YT makes money on eyeballs and runs on every terrible device specific browser under the sun. Making users experience worse intentionally only really hurts them.
- Because we're in a forum of devs that are all about chasing the latest features and polyfilling everywhere that doesn't have them -- it's practically SOP. I totally believe performance problems like this wouldn't get caught in testing when everyone has a corp network connection and powerful laptops/workstations.
But in this case I don't think they are at fault. As far as I understand it they didn't they just over-optimize for their own browser, which is not quite the same as degrade performance on other browsers on purpose.
It is wrong to optimize for your own ecosystem, without optimizing for others?
Quite frankly, the company should be broken up forcibly by the government. All of these services should be profitable on their own, not used as loss leaders to grab as much ad data as possible and stamp out any sort of competition.
Oh! You could change user agents.
Okay, but without new features? Does the pre-polymer design served to IE maintain feature-parity with the shadow DOM (or its' polyfill equivalent)? Because YouTube never _seemed_ slow to me on FIrefox, but I'd hate to miss new features.
They've reached or passed maturity and are adding dubious features like the miniplayer that keeps playing the video you've just back-buttoned out of. Things that benefit advetisers, not users.
The truly beneficial features should be server-side; culling those awful 'Top 10 Shocking ...' videos from my recommendations, for example. Or realising that just because I watched one programme about military re-enactment, once in ten years, I probably don't want to watch another 30.
Because that is what YouTube's frontend is currently running under the hood: Web Components and Shadow DOM. Both W3 standards. No magic at all.
Although it's true that only Safari and Chrome (through WebKit and Blink) currently have the best support for Web Components, and polyfills are required for everything else due to flaky support.
Google even mentions this in the Polymer README:
"Web Components are now implemented natively on Safari and Chrome (~70% of installed browsers), and run well on Firefox, Edge, and IE11 using polyfills. Read more below."
Source: https://github.com/Polymer/polymer