The Chrome Distortion: how Chrome negatively alters our expectations

Looking at the dbmon benchmarks there's a big difference between Ember performance: http://mathieuancelin.github.io/js-repaint-perfs/ember/

And the performance of other frameworks/libraries:

Angular: http://mathieuancelin.github.io/js-repaint-perfs/angular/

Polymer: http://mathieuancelin.github.io/js-repaint-perfs/polymer/

React (optimized impl): http://mathieuancelin.github.io/js-repaint-perfs/react/opt.h...

Where the other libraries all cluster around the same framerate, Ember is running in the single frames. I know that benchmarks can be written in a way to make one library look pathological so this is just one data point, but I wanted to throw it out there. I agree that it would be great if V8 and Ember played better together :)

Obviously both browsers are developed by highly talented software engineers (disclaimer: biased Google employee here, not in Chrome, speaking for self). But I think type of website and upfront ecosystem investment have some effect on where the most development pain comes from. My naive guess is that rich content consumption sites are easier to do in Safari, more app-like long-tail-of-features stuff easier in Chrome. If this is true, why? My guess is that Apple has its own idea of which general-purpose platform it'd prefer to most invest in.

[1]: https://meta.discourse.org/t/the-state-of-javascript-on-andr...

Adding new features while being slow on others does not make a browser "the new IE". In general, "new IE" arguments are easy to throw out but don't bring much insight, but this instance completely misses the mark in understanding both what was bad about IE around 2000 and what was bad about IE in the decade that followed.

> And herein is the problem; Google implements features that (usually) work at a high pace, but they very rarely make them work efficiently...they introduced us to shiny few features like CSS will-change, requestIdleCallback, and a fairly solid implementation of ServiceWorker in the hope that new tools would magically make their performance gap go away. It doesn't matter to them that even these shiny new tools are 3x+ slower than their peer's counterparts

While new features are apparently rarely made to work efficiently, of the three actual examples mentioned, one is "fairly solid", one (requestIdleCallback) isn't in any other browser, and the last (will-change) is just a modifier of other properties so web developers don't all have to use hacks (translateZ) forced on them years ago by WebKit to get decent GPU support. And only with one of them (the "fairly solid" ServiceWorker) would it make sense to call slower or faster compared to other implementations...but of course there is no ServiceWorker in Safari yet to compare to. I haven't heard (nor can I find) any complaints about ServiceWorker performance in Chrome vs Firefox, but maybe they're out there and really mad about that 3x+ slower implementation in Chrome, for some vague definition of slower.

I do love:

> There's a lot of these errors that Chrome silently ignores or just "deals with", and it leads to code debt that we "think" is due to other browsers being shitty, but honestly it's just what I've come to call "Scumbag Chrome".

and then proceeding to offhandedly mentioning having to work around old Safari flexbox issues, old Safari WebSQL issues...

But those aren't a big deal to the author, because he knows how to quickly work around them. And that's what most of this article is talking about: bugs the author is familiar with are easy to work around, bugs he isn't familiar with aren't. Honestly 90% of this just sounds like he's used to his iphone and Safari devtools and is upset he has to build for other browsers on other machines.

If you think that sounds exactly like someone with a site that only works in Chrome because they're used to the Chrome devtools and they didn't check it in another browser until right before launch, you'd be right.