17 ms·
JSC loves ES6
- jacobolus 9y agoI’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in every browser I tried. Hopefully having some better benchmarks gets Firefox and Chrome developers to also get to work on this.
- hzoo 9y agoYeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know) Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.
- franciscop 9y agoDo you mean that you saw actual differences when using Javascript in a normal website? Or that they were slower than the alternatives in a synthetic benchmark? It would be really surprising that those were the performance bottlenecks.
- deleted 9y ago[deleted]
- itslennysfault 9y agoTypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations. Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.
- pizlonator 9y agoNative ES6 is faster in WebKit than polyfill/transpiled.
- jacobolus 9y agoYes, but sticking to old-school Javascript features was dramatically faster than either.
- pizlonator 9y agoNot necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation. We’ll keep working on more optimizations for ES-6 so there will be more counter examples.
- netheril96 9y agoBut ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.
- pizlonator 9y agoI've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.
- saamyjoon 9y agoI agree too. I wonder if this has been discussed at TC39.
- fenomas 9y agoTo be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)? When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)
- deecewan 9y agoPretty much the only thing I've had problems with is generators. Regenerator runtime is so slow. Especially when making a bunch of calls with async/await
- hoodoof 9y agoA bit odd that they don't call it ES2015.
- iddan 9y agoIt will look bad they are two years behind.
- saamyjoon 9y agoHow so? Go to: http://kangax.github.io/compat-table/es2016plus/ http://kangax.github.io/compat-table/es2016plus/ In STP or WebKit nightly
- jfbastien 9y agoI think OP meant 2015 is two years ago, claiming it makes it look behind. Truth is, ES6 is what we've called it, ES2015 is to confusing cool new name!
- hoodoof 9y ago>> ES6 is what we've called it, Who is "we"?
- jfbastien 9y agoThe WebKit team. You like that question! Third time in this thread already
- djur 9y agoIt seems reasonable for people speaking on behalf of a project to identify themselves as speaking on its behalf. The question has turned up three different people not divulging that information so far, so I think it's done the job.
- 9y ago
- caiob 9y agoWorth noting that Safari Technology Preview was the first browser to support all of ECMAScript 2016+ features. * http://kangax.github.io/compat-table/es2016plus/ http://kangax.github.io/compat-table/es2016plus/
- smitherfield 9y agoAlthough IIRC Chrome and/or Firefox had all but guaranteed tail-call optimization (not a source code-level feature, obviously) first.
- pizlonator 9y agoI don’t think that’s right. Source?
- smitherfield 9y agoJust Chrome, but yes: http://web.archive.org/web/20160303192336/http://kangax.github.io/compat-table/es6/ http://web.archive.org/web/20160303192336/http://kangax.gith...
- pizlonator 9y agoThat shows WebKit supporting tailcalls. It doesn’t a show Chrome supporting tail calls. I vividly remember us implementing tail calls and v8 not having them yet at that time. This was almost 2 years ago.
- smitherfield 9y agoThat's what I said.
- pizlonator 9y agoChrome and WebKit are two different things. So, no, you didn’t just say that.
- iddan 9y agoAnother great reason to migrate Electron to WebKit. With WebKit and JSC Electron will be faster and will use a zero amount of RAM and battery!
- k__ 9y agoDoesn't Electrino basically try this?
- emsal 9y agoCurrently it looks like Electrino only supports macOS. Doesn't it sort of defeat one of the purposes of using a web-based framework for desktop apps if it's not even cross-platform?
- k__ 9y agoSure thing, but I thought the idea was to use Edge on Windows?
- chuckdries 9y agoI mean, the difference between rewriting an app and tweaking to compile on a different toolkit is not trivial, but I see your point
- untog 9y agoIt's still web based. You can just use one wrapper for one platform and one for another. A little extra effort, but if the engine makes it worth it then why not?
- pizlonator 9y agoDunno about zero. Sounds hard.
- kccqzy 9y agoI think what OP means is that instead of bundling a copy of Chromium, just use the system-provided WebKit and JSC, which is already loaded into memory.
- Androider 9y agoThe benchmark at the bottom showing how far behind Firefox has fallen on JS performance is pretty telling. It confirms my own recent observation that Firefox is at least 3-6 times slower in practice for the particular app I'm working on.
- om2 9y agoThis benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).
- rhizome 9y agoAnd that's all fine...in a lab. In the real world, all I have to do to experience Firefox's performance is click "Home" on my Twitter account. More often than not I'll get an alert that "A script has stopped responding [...] Continue / Stop Script," and it will still take 60+ secs to finish refreshing the page. Meanwhile, all Firefox tabs and window instances are frozen.
- draw_down 9y agoOh wow, that's pretty terrible.
- kevin_thibedeau 9y agoThat's more of an indication that Chrome monoculture encourages crap developer practices. There's no reason a messaging site should be so bloated that it brings a modern browser to it's knees.
- emmelaich 9y agoAre you sure that's mere slowness? I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
- floatboth 9y ago
- vmasto 9y agoI really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
- ergothus 9y agoES6 is 3 syllables. ES2015 is 6 or 7 (depending if you say "twenty fifteen" or "two thousand fifteen"). I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.
- avaer 9y agoBut the new name is more useful. It tells you how many years you're behind.
- ergothus 9y agoOnly sort of - it says how far behind the standard I might be, but since we're limited (on the Web at least) to what the browsers have implemented, it's not really measuring the important parts. (And in the backend, we're limited to what Node or other server-side engines support, and generally that goes back to the browser support). ES2015/ES6 might be 2 years ago, but feature complete support isn't yet available on all major browsers. I expect, however, that ES2016 will hit complete-or-basically-complete support relatively soon after full ES2015 support. If true (or any other irregularity over time), I might be 2 years behind on ES2015 and 1 year behind on ES2016 according to their names, but I might have, say 3 months until ES2015 is an option and 8 months for ES2016. And of course, unlike, say, Java, it's not really a yes/no choice. I tend to use const/let, native promises, fetch(), and arrow functions, but haven't yet had/found/realized a need for generators...am I behind ES2015? If 30% of ES2016 is implemented by most browsers, and I use one feature included in that 30% in 2017, am I 1 year behind? The ES6, ES7, etc labels do an equal job (that is, not a great one) of saying how behind you are, in a more compact package.
- 9y ago
- pfooti 9y agoIt seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in windows.
- kevin_thibedeau 9y agoThere never was a browser monopoly on Windows just a bunch of tech illiterates who don't seem bothered by MS's "monopoly" with notepad.exe or anti-competitive moves like taking away the ability to use an alternate graphical shell. Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
- pfooti 9y agoI'm not entirely interested in relitigating a past I literally lived through. On the other hand, it is objectively true that there is only one browser platform for iOS. WebKit or nothing. If they actually supported chrome or Firefox instead of requiring them to be wrappers on webkit renderers, I would not have this complaint. Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
- alwillis 9y agoOf course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee. No. Monopolies themselves aren't illegal, especially when they're natural monopolies. It is illegal for a company to use its monopoly to stifle competition in other, unrelated markets. The classic case is Microsoft using its monopoly in operating systems when Windows had 95% marketshare in the emerging browser market. Remember that Microsoft threatened to cancel HP and Compaq’s Windows licenses if they continued to ship Netscape Navigator instead of IE. That's illegal. It's not illegal to have a rules and guidelines for a platform a particular company owns. Game consoles are way more restrictive than the iOS App Store and nobody is suing them.
- williamle8300 9y agoThis is huge. Jeff Atwood was right all along...
- zurn 9y agoWill this translate to better performance for languages that compile to Javascript and have so far used pre-ES6 constructs?
- projectorlochsa 9y agoFirefox on Sierra is extremely slow. Not just javascript but everything else. Can't understand how it differs so much compared to being run on Ubuntu.
- 1k2ka 9y agoI have the exact same experience. Firefox on macOS is sluggish but on the same machine on Linux it's very responsive.
- inian 9y agoUpdated numbers with Dev versions of other browsers - https://twitter.com/bmeurer/status/871962560324657153 https://twitter.com/bmeurer/status/871962560324657153 The difference in speed is much lesser. Wonder how this will all change by the time their technical preview actually makes it to stable.
- _pmf_ 9y ago> ES6 requires completely new compiler and runtime features in order to get the same level of performance that we have with ES5. Given that other languages mandate that additional features have zero overhead if unused, this seems like a particularly bad way of evolving a language.