Javascript ES6 support

[zoshe]

Include support and benefits of Javascript ES6 with the use of a transpiler.

Abstract: CoffeeScript(CS) can provide value for folks who are not fans of certain JavaScript syntax, so I wont suggest not supporting it. Currently, the value for using CoffeeScript is steadily eroding as access to new Javascript ES6 features continues to rapidly grow and replace CS. Transpilers like Babel(aka 6to5) enable ES6 to take advantage of its features and benefits today. Once supported ES6 can provide the access and maintainability benefits for those mainly writing JavaScript to also contribute. Another benefit in supporting Javascript’s new ES6 and syntax now with a transpiler, is the ability in removing the transpilation step someday when browsers have implemented the features without changing any of the Javascript source code.

Points: http://robots.thoughtbot.com/replace-coffeescript-with-es6 ES6 transpiler & Info: https://atmospherejs.com/grigio/babel https://www.babeljs.io

[aaronjudd]

I'm not against JS (or CS for that matter). In fact, I go back and forth coding between the two all day long, and don't particularly understand why everyone else doesn't do this as well ;-). It always bums me out to have to type 'function' or add a few more braces, but overall it's no big deal.

It's noteworthy that reaction started as pure JS, but once I started using CS in Reaction, that was that.

That said, I agree with many of the arguments for using pure JS, particular with some of the features in ES6 coming along. But that's part of the issue, I'd guess another 2 years before you get reasonable adoption of ES6, and for now CS is making life much easier.

I'll take this a a step farther and say that if

• we had enough vocal voices speaking up about this and wanting "pure" JS ( this is what I would rank the highest)
• ES6 suddenly has widespread adoption
• comprehensions were supported (and not experimental)
  • I'd rather it was native and not a transpiler.. will that happen?

Babel is certainly interesting, and I'd like to do some testing to see how well a transition could go.

I'd have little opposition to at least giving serious thought and being open to the proposal.
Call that "on the fence". CS will be here in the meantime.

[evliu]

+1 for pure JS, haha. and i get warm fuzzier when I type function, lol. I'd agree that I'd have reservations using a transpiler instead of native. hopefully technology advances exponentially and we can start using actual ES6-implemented clients; issue will be (cough) IE (cough) with issues upon issues within nested issues that no fortuneteller could ever predict.

[danielgindi]

My personal opinion - is that I really do not like CS, I just do not see the point. I do not see the gain in productivity, I mean it's probably easier for beginners or for people coming from Ruby or Python, but that's not my cup of tea. But that's personal :-)

Technically speaking there are proven disadvantages to CS, some of which are quickly disappearing. I mean the fact that the brain understands && faster than and will never change - but the debugging problems are mostly thrown out the window since Chrome supports debugging CS when there's a source map. That's how I debug reaction.

About ES6 - I guess that the actual technical advantages of CS are being "absorbed" into ES6 anyway, so it would be great to switch. But I do not see that happening client-side any time soon. Any code that runs purely in node.js is fine to move to ES6 as you are not restricted by users' browser versions. It's much easier to update node.js.

Btw some of ES6 is already supported in node.js, and in the major browsers. For example - Typed Arrays. Those are needed for graphical applications, and every browser supporting WebGL supports these.

[ppoliani]

Hi guys,

First of all I want to highlight the nice work you're doing here and this project is something that's definitely missing in the node ecosystem.

@aaronjudd I will disagree with you about the period of ES6 adoption. First of all, the spec is now officially called EcmaScript 2015. Which might well mean that they might aim for yearly releases of the language(check the discussion here).

Apart from that, you can see that some popular libraries like ReactJS or AngularJS are trying to promote the idea of ES6 (or even supersets of ES6 like FlowJS, TypeScript etc. ). AngularJS 2.0 is being entirely written in TypeScript and this, I think, should by itself mean that investing in the future today is a really wise decision, And I still believe that we're talking about the near future.

In addition, io.js has adopted ES6 so did nodeJS 0.12 without the --harmony flag.

Finally, I believe more people will be willing to contribute to the project if it is written in a language that will make sense for them to learn; I have to admit I was talking about myself, but I still think that in 2015 someone would choose to learn ES6 and a language that eventually will transplile to ES6.

[aaronjudd]

I'm going to say that as soon as Meteor and Velocity both "officially" support ES6 [ECMAScript 2015] we will migrate all CoffeeScript to ES6 [ECMAScript 2015]. There are meteor packages for Traceur and Babel, but from my research there are still some things to iron out, and MDG has suggested that this is a core feature that will be coming soon in Meteor.

Thoughts?

[mikemurray]

@aaronjudd Yea, proper support for ES6 might be an issue; however, we don't have to go full ES6 right away. Coffee -> ES5 is decent sized jump in style and probably best to start early. ES5 -> ES6 is mostly just sugar; sweet additions to our old friend JavaScript. Classes, imports, modules, etc can all be added later when meteor gets its in core.

Also lets not forget that if you ran an ES5 JS file through Babel, you should get the same ES5 JS out. So, no harm in trying one of the ES6 -> 5 compilers in the mean time if we wanted to. :wink:

What do you think?

[aaronjudd]

Fun fact, our codebase actually started with a ES5 before switching over to CS. I can't say if the decision was the right one, but CS just felt more productive in early development. In a large part due to list comprehension in CS, which was just a breath of fresh air to me.

However, (and maybe because of CS) the codebase seems small enough right now to expect a reasonably easy conversion to ECMAScript 6 / ECMAScript 2015. If we were to switch back to ES5, someday we'd be having the discussion of updated to ES6 (which CS is already closer to). I'm in favor of just moving forward into the future now, and avoiding at least that future refactor.

The decision to me isn't really a technical one, even though there are features I am eager to use in ES6. Personally I'm equally comfortable with any of these choices, but this is more of a discussion of adoption. I think ES6 has enough exposure (like @ppoliani mentioned) that we're not going to get many complaints from either JS or CS users. I'd like to see us reaching out to the largest group of developers, and to me this has always meant focusing on using the tools with the most passionate communities. My theory being that, the right tools will also help us attract a strong community of early adopters and contributors of our own.

Right now, at least http://kangax.github.io/compat-table/es6/ seems to suggest Babel would be the best approach right now (I'm comfortable with this, after all, we'd just be swapping one transpiler for another).

It also looks like 'meteor-babel' was jsut added into the current meteor/devel branch, so I suspect that we'll get meteor supported babel in a release very soon. I'd say we can start planning the best way to do this.. we could run side by side CS and Babel, and start converting individual files, or take a quick branch and convert all at once (my preferred method).

[zoshe]

I would branch and covert files individual, because you may decide to put changes in place.

For example: Although it may have some risk, putting a ban on some parts of Javascript now, before converting to JS, should be very beneficial.

1. Currently, Javascript has three asynchronous methods, Callback-Hell(es5), Promise Nightmares(es6), and the Async Function(es7). The usage of Callbacks(es5) and Promises(es6) should be banned, and only the Async Function(es7) be allowed. Presently, Babel supports using Async Function(es7), so its possible to put this ban into place. In my opinion, having a ban on parts of Javascript would be a good thing, The benefits would be optimal design and simplicity, but it's a little risky now because the Async Function(es7) spec hasn't yet been finalized. https://github.com/tc39/ecma262

What do you think, and what parts of JS would you suggest be banned?

[aaronjudd]

@zoshe we're just a couple hours away from merging the feature-accounts branches into development - this include conversion of all CS to ES5. This is our first step, we'll make the move fully into ES6, after that - I don't think we've made any decisions on what exactly we should adopt, so open to discussion - maybe we can find a decent conventions / standards doc that already exists (I'd hope that Meteor would be updating their own style guide for this).

[zoshe]

When possible, I would look into sticking close to recoding to the airbnb JavaScript Style Guide and some parts of es7. https://github.com/airbnb/javascript#ecmascript-6-styles

[aaronjudd]

@zoshe all the core reaction packages are now JS in the development branches.

[mikemurray]

With the upgrade to meteor 1.2 we now have support for ES6 in the development branches of all of our packages.