The General Assembly will vote on approval of ES6 this month. Here's how to get started with ES6 in Meteor today

JavaScript as we use it today is based on the ECMAScript 5 standard. All commonly used browsers and node.js support it. The next version of ECMAScript (ES) is going to be ES6. The final draft of the new specification has been submitted for review and consideration to the Ecma General Assembly Members (GA). The GA will vote on approving it as an Ecma standard at their meeting this month. Meteor Founder Geoff Schmidt is also part of the GA, representing the Meteor Development Group. I wrote an article on how to set up Meteor to use ES6 today.

Read more

1 Like

Thank you.
On the module front, i would like to hear MDG’s stand as the current situation is not satisfactory.

1 Like

Great article!

I would also hope that MDG will be adding ES6 soon with something like Babel so we can get ES6 now in all js files and experiment with ES7 (opt in). CC @sashko

I agree with your #9 issue… having ES6 modules would be a great opt in feature for larger apps. Globals seem nice but I don’t really like having them scattered across. Also we’re going to lose Meteor users because of the global issue IMHO.

1 Like

It looks like jsx and react are on the way: https://github.com/meteor/react-packages/blob/master/docs/index.md

2 Likes

@dferber just read a great article to supplement yours:
http://codemix.com/blog/why-babel-matters

I didn’t realize there was so much under the hood of Babel!!

@robfallows yea can’t wait!

1 Like

@SkinnyGeek1010 I actually read that article some time ago, but didn’t think of it when writing the post. It would have fit nicely in there. The article mentions being able to write plug-ins. One thing this enables is removing all Meteor.isServer blocks in code that will be sent to the client at compile time. Just replace all Meteor.isServer with false in client-side code and then use the already existing deadCodeElimination flag.

As far as globals are concerned, something like import {FlowRouter} from 'packages/flow-router' would be nice. But I haven’t thought much about this yet.

@robfallows That’s great news. Let’s see where this goes.

Hey I like that! Great idea! Let’s hope we get a tight Babel integration soon :smile:

When Meteor 1.2 supports ES6, what is going to be the file extension?

What file extension should we use with something like grigio:babel so that the transition is as seamless as possible?

Most build setups now are just using .js and running everything through babel. I would hope they would do this as well.

I don’t think grigio:babel processes vanilla .js files, does it?

Nope, I think it needs to be .es6.js or .es6. Not sure exactly what it’ll be when ES6 hits core… though I imagine it it will just be .js and would require and opt-in for older apps.

You can specify the which extensions should by processed by Babel by adding a babel.json at the top-level of your project. I usually use .jsx.

{
  "debug": true,
  "verbose": true,
  "extensions": ["es6.js", "es6", "jsx"],
  "stage": 0
}
```
Adding `stage: 0` tells Babel to transpile strawman proposals, too. So you get some proposed ES7 features. But these features are subject to change, so be cautious :smile:

I’m very confused because I just saw https://github.com/meteor/babel and it seems like this will be the built-in babel transpiler in Meteor 1.2 and going forward. Can’t for the life of me figure out how to start using it now, though.

See also the discussion in the thread How to use ES6 as Meteor default js as discussed in the recent blog

I’ll continue to use Webpack even for the server side until import and export are supported and I don’t have to write api.addFiles for every single file in a package. That’s my #1 reason for using ES6 anyway.

Sorry for the late response. Now that Meteor 1.2 is out, I updated the article. It shows all steps necessary to get started with the ecmascript package instead of grigio:babel (which is deprecated now).

1 Like