Hacker News Reader

Comment by satori99 | Hacker News Reader

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.

View on HN

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.

Does it? It’s not like people are constantly running comparison benchmarks of var/const/let between browsers.

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.

Or they are all compiling their JavaScript to legacy JavaScript specs for WebKit.

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.

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.

There's roughly 1+ billion devices running Safari _daily_, I'm not sure we should torture a Safari bug into a problem with Chrome

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.

Surely professional or hobbyist software developers are more likely than the average user to use Safari or Firefox, not less.

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.

That depends. CSS prototyping is usually easier in Firefox. For example grid editing, flexbox, shape path editing.

I mostly switch to Chrome when debugging PWA. Other then that Firefox gives me better UX.

It's recommended to install your goalposts with concrete footings that go below the frost line to prevent movement.

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.

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.

Presumably it's because everyone is using babel to transpile down to ES5 for old browser support.

no, it really hammers home that this distinction doesn't matter because the absolute numbers are small compared to everything else.

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.

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

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.

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

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 :)

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.

Until IE11 dies, just about everyone compiles down.

There are quite a few markets where IE11 is about dead already, I think - the question is, how many?

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.

Reply on news.ycombinator.com