Hacker News new | ask | show | jobs
by saurik 2049 days ago
In stark contrast: "Using const/let instead of var can make JavaScript code run 10× slower in Webkit" ;P.

https://news.ycombinator.com/item?id=24844353

2 comments

I know you jest, but I don't think that's a good example of "contrast" between the engines. That was just a bug/oversight and fixed in a couple of weeks after it was reported [1].

[1]: https://trac.webkit.org/changeset/269115/webkit

Actually, it was reported about a year ago by the Dart team: https://bugs.webkit.org/show_bug.cgi?id=199866.

It was an excellent bug report, complete with a reproducible example.

Only after it recently made the rounds on Twitter and hn was it fixed.

https://mobile.twitter.com/mraleph/status/132175888792258969...

YMMV, but I find that Safari uses dramatically fewer local resources on my computer than Chrome does, for the same workload. Chrome can’t remotely handle the number of tabs I typically keep open (it chews up all available memory, and hangs or crashes). Even for lighter browsing usage, Chrome chews battery faster and slows the rest of my computer down. Overall Safari is the most usable, followed by Firefox.

In various numerical computing in Javascript projects/experiments I’ve done, Safari is typically fastest, but not always. At any rate, it is clear that all of these teams have done very extensive optimization work, and all of the modern browsers are engineering marvels.

But there are a lot of weird nooks and corners in all of the browsers when it comes to Javascript performance.

As someone who uses JavaScriptCore in most of my projects (there is one for which I am currently intending to use v8, which is seriously "off brand" for me), and only finds Chrome usable with The Great Suspender (at which point I do use it instead of Safari for various reasons, particularly since I now use a Windows desktop ;P), I agree with you; but, everything you said seems unrelated to the topic?...
For years people have been ragging on Safari for being slightly slower to adopt new features, usually with the implication that they are holding back the web. But I think their current priorities are just fine.

I assume all of the ES2015 features will eventually see the same level of optimization as ES5-era code. I’m not too worried if it takes a few more years.