ESnext – Tomorrow’s JavaScript syntax today | Hacker News Reader

ESnext – Tomorrow’s JavaScript syntax today

esnext.github.io

39 pointstosh27 comments

How is this different than the already well established Traceur compiler? https://github.com/google/traceur-compiler

That's what I want to know. There are dozens of es6 transpilers.

Yup and the place to look for comparison of them is:

http://kangax.github.io/compat-table/es6/

Though admittedly facts like whether they support source maps (such as Traceur) or preserve comments (not Traceur) are omitted. EJS is impressive though.

Had to look at the compat-table source to find out that EJS is short for Echo JS

https://github.com/toshok/echo-js

(It's definately this repo: https://github.com/kangax/compat-table/pull/115 )

IIRC, Traceur compiles to es5 which is not supported in IE 8.

[edit] It's not clear to me that this project compiles to es3, but that was my assumption when reading "JavaScript that will work today".

Looking at the compiled source, it looks like ES5 and not ES3. They use "use strict" and Object.defineProperties which are ES5 features.

P.S. IE9 doesn't support ES5 strict mode so "use strict" might introduce some subtle bugs for that case.

Could you explain how? I thought "use strict" only added more runtime checking, but does not change the semantics. Wouldn't IE9 just interpret the line as a bogus expression and move on?

I use "use strict" on JavaScript that runs over IE8/9 and I don't get errors from it.

That's because "use strict" is ignored in IE8/9 (thankfully). You usually won't run into any issues, but if you're relying on strict-mode for certain semantics you can run into some very subtle bugs. The chances of that are super low though, I've only ever done it on purpose :)

One reason: Traceur strips comments from the source, with no option to preserve them. You can't use Traceur to generate an intermediate build product that you then run through another compiler (eg. Closure Compiler) that uses comments for source annotation.

Traceur is more complete. ESNext requires less overhead. For most Traceur features, if you want to run it in a browser, requires a rather large runtime.

ESNext is more modular. You can use just some features which may or may not require a runtime. It just depends. Overall Traceur is "better". But ESNext is nice if you just want feature X and don't want the overhead of having to support everything.

Also 6to5 which was linked on HN just a few days ago: https://github.com/sebmck/6to5

Nice, and built by Square!

Now my only issue is IE8. If I could have something like this but that allowed ES5 to run on ES4 engines, I'd be in heaven (and able to use Vue.js for work, finally, as well as not being stuck on Angular 1.2 or whatever it is...).

One of these days I'm going to get stuck into Sweet.js and make it happen, I swear. ES5-shim just isn't comprehensive enough, unfortunately.

I don't see anything substantial missing from ES5-shim. Which APIs are you missing?

Object.defineProperty along with a number of ES5 Object methods that don't work at all, or don't work correctly.

Because IE8 includes it's own horrid implementation that only works on DOM elements, the various shims for it fail (and fail in some really interesting ways). Using Sweet.js macros and compiling it out to a differently named method call would allow us to get around that limitation.

Compared to 6to5 [1], all others look subpar.

[1] https://github.com/sebmck/6to5

I don't understand something.

Why calling new Person(..,..) returns toString()?

The example calls:

console.log( 'Full name is:', new Person('Michael', 'Bluth2') );

new Person should create an instance of Person, but why it calls toString()?.

Because you're console.logging it

"Every object has a toString() method that is automatically called when the object is to be represented as a text value or when an object is referred to in a manner in which a string is expected."

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

While this is interesting, i'd still think that Typescript is a better choice to use ES6 features that will work with legacy ES engines.

Why is that? Transpiled ES6 code will stop needing the transpiler once ES6 launches. Typescript based code on the other hand will need, well, Typescript forever. If you're willing to stray out of standardized JS territory, there are plenty of other languages available.

Why not Typescript? To many, it's better than Dart, not as volatile as the ES6 draft and not as seemingly illogical as Coffeescript.

Plus, it comes from Microsoft and there are literally millions of devs out there who only want to use what Microsoft is pushing because they know that if Microsoft gets it right, they will reap the benefits of robust hiqh-quality tools and components as history has shown them. So far it looks to a lot of us like they're getting it right.

There's obviously no true measuring stick here. If you don't like Microsoft's style, which I'm betting most folks here don't, then it's probably not for you.

History has shown Silverlight too..

Exactly. Silverlight was awesome! It's the best cross platform UI kit I've seen yet.

It's sad that the trifecta of lame known as HTML/CSS/JS won out due to the fact that it's the only cross platform kit that native mobile environments will fully support, since it's so non-threatening.

I think that "better than Dart" is an opinion that is not shared by everyone. Personally I think Dart is better but also more different than javascript which makes it a bit harder to learn. As you said, a lot of developers on the MS stack likes to use what MS builds but others prefer things not from MS (sometimes very stubbornly :-) ).

unfortunately TS currently has many mis-alignments with ES6, hopefully this improves someday.

It is planned for the next version.

http://blogs.msdn.com/b/typescript/archive/2014/10/06/announ...

Right at the end "This work and the work to align with ECMAScript 6 is ongoing.".

Reply on news.ycombinator.com