It's incredible that such a common case can be affected so dramatically and yet nobody noticed it until now. Really hammers home the problem of having a browser monoculture.
This isn't completely a browser monoculture issue though. It might be part of the issue, but it's very likely because most big applications use tooling that hide this issue, i.e. using tools like Babel which just translate let/const into var automatically. I imagine it's never really been noticed because it just never really has been a "real world" problem.
You make a good point that a Babel configuration targeting pretty old browsers would convert const/let to var, though I don't think you can say it necessarily isn't a "real world" problem. It could very well be a real problem for a significant (Safari-using) minority of users, who don't see it as a bug and so it never comes to the attention of developers, but continues causing subtle headaches for thousands of people.
You misunderstand. The problem is that all the devs, and something like 3/4 of regular users, all use Chrome, meaning something like this can fly under the radar, going unnoticed, and make Safari or Firefox a second-class experience. It's only a "problem with Chrome" insomuch as Chrome has an unreasonably large market-share.
Definitely not, at least in the case of front-end devs. Speaking as one myself, part of this is that Chrome's dev tools are so much better. Part of it is that the great majority of your users are on Chromium, so that is the most important case to test. But of course it's a self-reinforcing cycle: the more devs that only use Chrome, the more apps that work best on Chrome, the more users that switch over to Chrome, the more devs who only feel the need to test on Chrome, repeat.
To add: any project or random script that hasn't at least considered babel/webpack probably isn't at a point where they would notice a 10x slowdown - the difference could be 10ms vs 100ms.
It would blow your mind if you saw how much slower querySelector is compared to old school getElementByid, getElementsByClassName etc.
We tend to think that newer is better and faster, but it's also wise to think that old apis had to be fast on old hardware. Hardware that is not the target of new APIs.
That wouldn't blow my mind, and it's also a wildly different question. The OP is about a core language feature performing differently on two browsers. querySelector is fundamentally a higher-level API across all browsers.
Also, block-scoping is a language feature that's fundamental to virtually every other modern language out there. This isn't some high-falutin' new API. This is basic.
> how much slower querySelector is compared to old school getElementByid, getElementsByClassName
IE 8 got querySelector before IE 9 got getElementsByClassName, so it’s not really an old vs. new thing, and I don’t think anyone expects querySelector to be faster than getElementById.
Or, maybe, it's an edge (ha!) case with little practical relevance because – as but one possibility – absolute numbers are low and dominated by network latency or rendering.
If every large JS app on Safari is 10x slower than it is on Chrome, and the user base of Safari has been dealing with that since who-knows-when, and no developer noticed because they're all testing on Chrome, that's a problem.
It's Apple's problem to solve though, I mean, outside of developers writing code that's more efficient to begin with so it doesn't really matter when it's 10x slower, but they should probably be doing that anyway.
