5 ms·

I can't even remember the last time I used var when writing JavaScript. Scoped const/let are just easier to reason with. This seems bad.

brundolf 6y ago
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.
- coddle-hark 6y ago
  Does it? It’s not like people are constantly running comparison benchmarks of var/const/let between browsers.
  - brundolf 6y ago
    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.
    - microcolonel 6y ago
      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.
    - mattnewton 6y ago
      Or they are all compiling their JavaScript to legacy JavaScript specs for WebKit.
    - asdfasgasdgasdg 6y ago
      Yeah. A problem Safari's developers should address. Apple is not a wee baby company that lacks the resources to keep up with Chrome in any dimension.
- yladiz 6y ago
  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.
  - brundolf 6y ago
    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.
    - refulgentis 6y ago
      There's roughly 1+ billion devices running Safari _daily_, I'm not sure we should torture a Safari bug into a problem with Chrome
      - brundolf 6y ago
        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.
        dmurray 6y ago
        Surely professional or hobbyist software developers are more likely than the average user to use Safari or Firefox, not less.
        brundolf 6y ago
- IfOnlyYouKnew 6y ago
  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.
- lhorie 6y ago
  Presumably it's because everyone is using babel to transpile down to ES5 for old browser support.
- swyx 6y ago
  no, it really hammers home that this distinction doesn't matter because the absolute numbers are small compared to everything else.
- pantelisk 6y ago
  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.
  - minitech 6y ago
    > 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.
  - brundolf 6y ago
    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.
- monadic2 6y ago
  I seriously doubt that nobody has noticed it. It simply takes a lot of effort to advocate for bugs you need fixed. Furthermore, Is JavaScript really a bottleneck for any site? what the hell is it doing?
lhorie 6y ago
I use var when I pop open devtools as a REPL. const/let are annoying there because copy/paste into the REPL multiple times throws rebinding errors. Just goes to show there are jobs for every tool :)
Vinnl 6y ago
I do wonder how many projects actually have const and let in their production code, vs. how many are writing them, but still compiling their code down to ES5.
- Zenbit_UX 6y ago
  Until IE11 dies, just about everyone compiles down.
  - Vinnl 6y ago
    There are quite a few markets where IE11 is about dead already, I think - the question is, how many?
kevsim 6y ago
Exactly. I saw a tweet the other day with someone explaining the difference between var/const/let and I responded with "never use var...ever". Maybe that was bad advice.
onion2k 6y ago
If you're transpiling the JS code to ES5 then you're deploying 'var'. That's what actually matters.

brundolf 6y ago

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.

coddle-hark 6y ago
Does it? It’s not like people are constantly running comparison benchmarks of var/const/let between browsers.
- brundolf 6y ago
  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.
  - microcolonel 6y ago
    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.
  - mattnewton 6y ago
    Or they are all compiling their JavaScript to legacy JavaScript specs for WebKit.
  - asdfasgasdgasdg 6y ago
    Yeah. A problem Safari's developers should address. Apple is not a wee baby company that lacks the resources to keep up with Chrome in any dimension.
yladiz 6y ago
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.
- brundolf 6y ago
  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.
  - refulgentis 6y ago
    There's roughly 1+ billion devices running Safari _daily_, I'm not sure we should torture a Safari bug into a problem with Chrome
    - brundolf 6y ago
      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.
      - dmurray 6y ago
        Surely professional or hobbyist software developers are more likely than the average user to use Safari or Firefox, not less.
        brundolf 6y ago
IfOnlyYouKnew 6y ago
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.
lhorie 6y ago
Presumably it's because everyone is using babel to transpile down to ES5 for old browser support.
swyx 6y ago
no, it really hammers home that this distinction doesn't matter because the absolute numbers are small compared to everything else.
pantelisk 6y ago
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.
- minitech 6y ago
  > 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.
- brundolf 6y ago
  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.
monadic2 6y ago
I seriously doubt that nobody has noticed it. It simply takes a lot of effort to advocate for bugs you need fixed. Furthermore, Is JavaScript really a bottleneck for any site? what the hell is it doing?

lhorie 6y ago

I use var when I pop open devtools as a REPL. const/let are annoying there because copy/paste into the REPL multiple times throws rebinding errors. Just goes to show there are jobs for every tool :)

Vinnl 6y ago

I do wonder how many projects actually have const and let in their production code, vs. how many are writing them, but still compiling their code down to ES5.

Zenbit_UX 6y ago
Until IE11 dies, just about everyone compiles down.
- Vinnl 6y ago
  There are quite a few markets where IE11 is about dead already, I think - the question is, how many?

kevsim 6y ago

Exactly. I saw a tweet the other day with someone explaining the difference between var/const/let and I responded with "never use var...ever". Maybe that was bad advice.

onion2k 6y ago

If you're transpiling the JS code to ES5 then you're deploying 'var'. That's what actually matters.