You can also add just the jsx package and rename your files to .jsx to use the ES6 syntax. This will provide the best compatibility with the upcoming ecmascript package. I think the other package lets you use experimental features by default and you may have to change code if using that (like decorators or stage 0 things).
Editors have plugins to enable JS syntax/highlighting on JSX files. Also, you don’t have to add any JSX markup in the file.
Will ES6 changes the way we develop and structure our apps in Meteor ?
I raised the same question about grigio:babel as an issue on Github. There I was told that they deprecated the package in anticipation of the upcoming ES6 support in Meteor. I personally think that it’s not a very good idea to deprecate a package before a standard solution is already available, but I respect their choice of doing so. Yet, as a developer, this gives me a kind of “uncertain feeling”, a bit like if they were stating: “We’ve put our hands in our laps now and will not take care for this package anymore.” Nothing you would like to hear if you’re using the package in productive environment However, I appreciate their open source work, so this may be some kind of nitpicking from my side. At least for me, working with .es6.js files works fine so far, I’m using them in packages only to control the usage of ES6 on a per-package level. This is just because I don’t know how the final ES6 solution of Meteor’s will look like, hence I’m only using ES6 for defining my model classes for now (since I like the new class syntax of ES6 and - even better - ES7).