[DISCUSSIONS] Should we replace CoffeeScript with ES6?

[engelgabriel]

Universal JavaScript: Adopting ECMAScript 2015 (aka ES6)

SOURCE: http://info.meteor.com/blog/whats-coming-in-meteor-12-and-beyond

ECMAScript 2015, also known as ES6, is going to be huge for the JavaScript community and for JavaScript adoption. The new version of the language is "the best JavaScript we've ever had," with classes, block scoping, and many other additions. We're excited that it will bring many new developers to JavaScript by addressing the objections that developers from other backgrounds sometimes raise.

We think anyone writing an app in JavaScript should be using ES2015. So we are making ES2015 the official JavaScript of the Meteor platform. Our goal is to make Meteor the best way to use ES2015, and to provide a seamless ES2015 experience across the whole platform and across the client and the server. Meteor 1.2 will be the first step in making that seamless development experience: we're adding support for all its features except for modules, automatically transpiling JS files with Babel so they work on all of Meteor's supported devices and browsers, and changing all our examples and documentation to ES2015.

We hope that you'll make the switch to ES2015 today, especially given how easy this new support makes it. It really is a huge improvement on JavaScript. But if you're not ready to switch, or want to transition your codebase gradually, you'll have that option. You can write some parts of your app in ES2015, some parts without, and adopt ES2015 at your own pace.

Special thanks to Ben Newman, Meteor core developer and Ecma TC39 standards committee member, for his leadership in this area.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[engelgabriel]

https://robots.thoughtbot.com/replace-coffeescript-with-es6

[engelgabriel]

http://blog.ksol.fr/from-coffeescript-to-es2015

[engelgabriel]

https://forums.meteor.com/t/use-es2015-or-coffeescript/7815

[whitelynx]

👍 I'd likely be willing to contribute if the project was written in ES6 instead of CoffeeScript.

[geekgonecrazy]

@engelgabriel based on the articles you linked here along it seems they are pretty similar.

Initially I would have said es6 all the way. But after using coffeescript here. Its honestly not that bad. At some point it becomes just another language.

My question is are the people that bawk at coffeescript already familiar with es6 features that we would be using right out of the gate? Or do they just like it because it'd be javascript? Because if not either way there is a learning curve.

Note: not arguing against es6. I like it. But like I said. Its just another language. The addition of classes almost makes es6 a new language. :)

[Morgul]

I've got a bit of experience with setting up projects for ES6 (Babel.js is my current favorite transpiler), and I'm more than willing to start doing the conversion work once it gets the green light. We can do it in chunks (and someone more familiar with the project should probably decide what those chunks should be), and over time get the project on ES6. Then, Babel.js supports shutting off portions of the transpiling, as browsers get more compatible. (Additionally, the android/ios apps can keep some of them turned on, while the desktop shuts those off, since mobile moves at a slower pace than desktop browsers.)

[engelgabriel]

@Morgul you will find this link interesting: http://info.meteor.com/blog/whats-coming-in-meteor-12-and-beyond

[Morgul]

@geekgonecrazy I'm about 50/50 when it comes to knowing the new features. While I have some opinions about CoffeeScript's syntax (some of which are negative, I admit), to me that's less the point.

For web developers, it's not possible to avoid learning javascript, really. Most web guys will have to learn it. It's certainly where the mindshare is, and is likely to stay. So, as a web developer, if I want to contribute to this awesome chat application, should I have to learn a language I might not know (CoffeeScript), or a language I'm already using (JavaScript)?

Right now we're in the awkward transition phase where few people know ES6, but that's quickly changing. I'd rather see a project position itself to ease future contributions, rather than limit them, unless there's a good reason for it. Since ES6 gives most of the desired features of CoffeeScript... why shouldn't there be a change?

Or, let me put it another way: if you consider ES6 and CoffeeScript to be roughly equal, doesn't it make sense to choose the more popular?

[Morgul]

@engelgabriel Well then! It seems like the Meteor community's decided that ES6 is the best direction to go. (And they use babel! Sweet!)

[rodrigok]

We need to wait for Meteor 1.2 to be able to use ES6, and no, ES6 doesn't has all features that CoffeeScript has.

[geekgonecrazy]

@rodrigok I know its missing a good portion of the ruby style conditions. What else is es6 missing? Just out of curiousity

[rodrigok]

@geekgonecrazy

• Conditions and, or, is, isnt, not, in, etc instead && and ||, ===, etc...
• Parenthesis if a is b instead if (a == b)
• Code block with keys instead identation
• Loop over objects
• Loop with closures using do instead a lot of code
• A lot of features related with loops
• Existential operator if user?.name?.first is true instead if (user && user.name && user.name.first === true) or a ?= 1 instead if (a === undefined) a = 1

And some another features

[Morgul]

@rodrigok As for usage before 1.2, it seems there are a couple options, all with some trade offs: meteor/babel#3

On the surface it doesn't look like it would be that terrible to integrate, even before Meteor 1.2. But, it would definitely need a proof of concept project to see how it all played out.

Regarding CoffeeScript features vs ES6 features; of course you're right. They aren't a 1:1; I was taking @geekgonecrazy's premise of 'it's just another language' and running with it a bit.

[geekgonecrazy]

@rodrigok those are all pretty useful. Come to find my self appreciating the conditions as well as existential operator. Very handy.

@Morgul Meteor 1.2 might hit us at a good time. We for sure don't want to derail our rapid development pace pre 1.0 We need our initial feature set squared away before doing this.

[Morgul]

Disclaimer, I don't know CoffeeScript, so I'm basing some of these off a quick read of the docs.

@rodrigok When you say loop over objects, does't for...of give you that in ES6?

Additionally, can't you do the following in ES6 instead of do?

var mylist = [ 123, 456, 789, 1112, 555 ];
mylist.forEach(num => {
    console.log('some num:', num);
});

The big missing feature on your list that I can't suggest an alternative to is the existential operator. It's pretty nice.

[rodrigok]

@Morgul I don't think so, seems that in ES6 is for (value of object) while in CS for key, value of object

About do, yes you can do that, but seems that is only for loops over array.

[Morgul]

@rodrigok Ah, yeah, looking around it seems CS and JS have differing ideas about what for...of should mean. Fun!

[engelgabriel]

Can we have @benjamn option here? 😄

[engelgabriel]

Interesting presentation

http://www.slideshare.net/NeilGreen1/type-script-vs-coffeescript-vs-es6

[marceloschmidt]

I think the existential operator ? is absolutely the best of all CS features, and one that should not be overlooked. It makes code much simpler, as do all of CS, but this one is a must! I actually think they should have copied that to ES6, I wonder why they didn't

[mitar]

I think CS is still much better than ES6. Cleaner and consistent and still makes it easier to write good code.

+1 for keeping CS here.

[engelgabriel]

Top ES2015 Features in 15 Minutes
https://kadira.io/blog/other/top-es2015-features-in-15-minutes

[engelgabriel]

Common Meteor Patterns in ES2015
http://themeteorchef.com/snippets/common-meteor-patterns-in-es2015/

[dcworldwide]

👍 for replacing CS with ES2015. It is less about the language, but more about embracing standards and ensuring we have the broadest possible base of developers able to contribute.

[engelgabriel]

@GQAdonis we like the idea of experimenting with ES2015 on new packages, as they are self contained. It would be a good way to try it out, and eventually migrating to ES2015 if we decide it is the best for the project.

[franciskim]

I'd be happy to help in the refactoring if this goes ahead! :)

[acamarata]

+100 Yes and if all the code could be translated ASAP I think it would
remove one possible barrier to some of the community who wants to join in
and as Francis said is the way going forward.

On Fri, Oct 9, 2015 at 7:21 AM, Francis Kim [email protected]
wrote:

I say ES6 all the way if you guys want to ensure future development
momentum. It's a fantastic product and I really want to see more people get
involved +1

—
Reply to this email directly or view it on GitHub
#796 (comment)
.

[geekgonecrazy]

@GQAdonis we like the idea of experimenting with ES2015 on new packages, as they are self contained. It would be a good way to try it out, and eventually migrating to ES2015 if we decide it is the best for the project.

@franciskim ^ we're for sure not against it. I think it'd be a great idea to maybe try this on a couple of packages. We for sure have to try it somewhere.

If anyone wants to try this maybe open a PR? Show off some of the ES6 strengths. I think this would be great!

[franciskim]

@geekgonecrazy sure, I did read that too. I'll give it some thought!

[mitar]

I think you all will miss the ? operator more than you know. ;-)

[engelgabriel]

Some more references: 7m video about tools for ES6.

https://developers.google.com/web/shows/ttt/series-2/es2015?linkId=17821107

[mitar]

I have been converting README of Blaze Components to ES2015 and I must say that ES2015 did not convince me to switch to it, I will be sticking with CoffeeScript for the time being. Things one misses:

• no ? operator
• no way to call a static method inside a class body:

class Foo extends Bar
  @register 'Foo'

• super is really awkward, instead of just calling super to call parent method with all arguments, you have to do super.methodName(argument1, argument2) and so on, or super.methodName.apply(this, arguments)
• all those { and } around functions just make code so much longer
• all those { and } you have to start adding again back for objects
• no array comprehensions
• no verbose operators like or and and
• comeback of !== and ===
• no function arguments assignment from the signature: constructor: (@argument) ->
• no suffix if and unless
• have to use this instead of @

[geekgonecrazy]

@mitar but the question we have to ask our selves is this. Are sacrificing these things worth having a ton more contributors?

Nothing on that list makes me say "nope I can't live with out it".

[mitar]

Are sacrificing these things worth having a ton more contributors?

Do you really think the language is the bottleneck for contributors? I do not know. From other open source projects I contributed to is it so that there is always a lot to learn to be able to contribute, technology stack, code structure, understand where something is and how it works, the patterns community likes and so on. The programming dialect is really a smaller part, especially for a language you can learn over one day. So what I am saying that when you want to contribute, you will do anyway some effort to learn necessary stuff.

[franciskim]

@mitar language definitely is a bottleneck for contributors. Rocket Chat is widely known as a Meteor project - I was turned off when I found out I needed to write CoffeeScript. I think CoffeeScript is great, but it is much more beneficial to go with the official JS of Meteor which is ES6.

[mitar]

I am not saying that it does not lower possible contributions a bit, but that it is not a bottleneck, the main reason why people would not contribute. But of course, all this is speculation and we have no good numbers. It might be a good research to find a way to quantify and evaluate various factors as such in contributing to open source. :-)

Because things are always trade-off. Having many people contributing might in fact reduce the quality of the project (because they might have less knowledge of the project), you have a bigger community of contributors you have to manage and teach them how to submit patches and so on, so there is more work for core developers just maintaining the project. On the other side, using the language existing developers are used to and which (arguably) provides some features which makes it faster and quicker to program high quality code, might at the end provide more features being added to the project.

I am not saying that one or another is the right thing, I am just saying that there much more questions such a change is embedded in.

I see CoffeeScript as extension to JavaScript. You can say that you want to program something only with core Meteor packages, or you can use an extra package to help you here and there.

Interesting thread for Atom project and this topic: https://discuss.atom.io/t/why-coffeescript/131/110

Anyway, I think I spoke too much already and I am really just more or less an observer here, so let me step aside here. I just wanted to add 2c here based on my experience converting some part of code from CoffeeScript to ES2015. I just see as that CoffeeScript pushed a lot of ideas further which made then into ES2015 just because CoffeeScript proved them useful and viable. And that while this is great, we should not give up midway and should keep showing that there are more great features to be added to core language. And we can do that by using those features. Great projects as examples are important to lead that.

[nszceta]

Please use plain old Javascript. There is already so much innovative work being done in this project that the choice of a niche language is a distraction from the greater task at hand and it is also a potential turnoff to the many great developers which are not familiar with coffeescipt. I think it is safe to say that this means the majority of web developers.

Please do the right thing and use Javascript.
Save the coffeescript for something else

[shrop]

This article came out recently. It seems to be a fair perspective from someone who approached Meteor from a Ruby on Rails background. http://justmeteor.com/blog/why-i-moved-away-from-coffeescript/. I don't think it proves the projects should go one way or another, but is an interesting, related read.

[dokudoki]

👍

[tvld]

Actually until I saw this, Coffee was one of the reasons why we not wanted to dive into RC.
So +1 :)

[j8r]

I suggest to combining the advantages of both and using ES2015 and CoffeeScript. For example code using community ressources in ES6, more custom code in Coffee.

[tvld]

@j8r Combination of dialects increases the threshold for newbies to participate. I would not recommend it. ES2015/6 is nice enough to form the native standard.... which it is ;)

[engelgabriel]

Hi all, our team agreed to start developing new packages using ES6 (a.k.a. ES2015).

The refactoring of existing code will take a while, as we will focus on new features for now, and on learning ES2016 before we rewrite anything.

We will make an official announcement on our blog soon. (as we will have a blog soon).

[tvld]

+1 for the Blog :) and ES6 ... wow :)

[j8r]

CoffeeScript is no longer very maintained and too much dependent of fzw people, who are not very active this time... too bad because i love this language. Lots of improvements were done in ES2015 and are coming to the next versions (ES7...). ECMAScript is effectively even more the future.

[onigoetz]

This is great news, I have to admit I wanted to contribute a few small things.
I'm not familiar with meteor and wanted to learn a few things, but the added overhead of learning coffeescript on top is just too much to learn at once for the small amount of time I can provide to the project.

[engelgabriel]

I'll close this, as we agree that we making the switch to ES2015.

It won't be done at once, as we will prioritise the development of some important missing features, but all new development will be done in ES2015.

Existing code will be refactored over time, as we have a lot of refactoring to do before 1.0 :)

[telemakhos]

Smart decision... ES2015 is the way to go

[thevinci]

There are some performance issues with ES6 by the way. Not sure how it affects ES2015. Are you planning on compiling it back to ES5? https://kpdecker.github.io/six-speed/. Also Safari has limited support for ES6.

[geekgonecrazy]

@thevinci by way of meteor it is compiled down to es5