ES6

[sonnyp]

Hello,

Just curious, how would you feel if I send a PR that is a dumb rewrite from CS to ES6/babel ?

[ezzatron]

I'm not super keen on this, just because I'm much more familiar with CoffeeScript than JavaScript. But if you have some good arguments for going back to ES6, I'd like to at least understand them. Cheers!

[jimmywarting]

Inventaire started as a love affair with coffeescript but it's not a definitive thing. While I don't mind using technologies that where trendy more than 6 months ago, there are real incentives to move the whole project to standard JS, ES6 and above.

Reasons to move to ES6+

• Having a language known by way more people. Despite the fact that CS is just JS, it isn't obvious to the new comers, making it less likely for them to jump in the code
• Not having a language denigrated by the whole community. Yep, that's sad, but new learners are largely discouraged to learn CS by the community, and while one might think this is totally disproportionate, you got to pick your fights
• With such a bad press, we can expect less and less support for CS, in JS tools in general (that --coffee flag in test tools, etc), but also in CS specific tools (coffeelint)
• leave CS kind of toxic governance for the TC39 bunch of java-lovers... hurraaay... :p
• NodeJs is ready for ES6: yeah destructive assignments \o/
• ES6 modules tree-shaking and other static module dependencies analysis goodies
• const, let, with possible performance benefits in the future, and less lexical scoping issues
• end the confusion between some CS and JS syntax: the of operator among others

Conclusion

TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.

Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, the list goes on. If you have a large code base, picking CoffeeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt. and CoffeeScript should have faded off and brought some good parts to ES standard

CoffeeScrip will always be a step behind. When ES8 will be release you will have to wait till CoffeeScript adds supports for new technology

Resources

• Moving to ES6 from CoffeeScript

[ezzatron]

@jimmywarting Thanks for your input, but I don't know what to make of the first paragraph; I have no idea what Inventaire is, or its relevance to this project.

On this topic, I have much more experience with ES6 and Babel than at the time this issue was created. While I certainly agree that ES6 is more future-proof than CoffeeScript, at this stage, rewriting in ES6 is less appealing than rewriting in ES5.

I originally wrote this library to handle PRECIS prepare in the browser, and PRECIS enforce on the server. I realize that PRECIS probably has more applications on the server side than the client side, but working well in the browser is an important goal IMO. The PRECIS spec has explicit allowances for client implementations, and there is no more ubiquitous a client than the browser.

With this in mind, I'm open to the idea of getting rid of the compilation step of CoffeeScript, as it gets rid of many moving parts. But getting rid of that just to replace it with a shinier, newer compilation step doesn't hold as much appeal.

[sonnyp]

@ezzatron what I mostly do now is write code in es6 that runs on latest Node.js and evergreen browsers and transpile to es5 with babel for releases. No compilation step required to develop, just for releases. I'm rewriting node-xmpp that way and it's working great so far.

[ezzatron]

@sonnyp There's a particular problem I have with compilation that's relevant to this project, so it would be interesting to get your opinion. Sorry in advance for the wall of text.

In order to keep browser bloat to a minimum, precis-js implements multiple modules. Since PRECIS prepare doesn't require Unicode normalization, you can trim about 150KB of JavaScript bloat by using require('precis-js/prepare') instead of just require('precis-js').

This kind of require statement, that includes a relative path, poses a problem when combined with any kind of compilation step.

Note that I believe this is actually broken in the current release, because I mistakenly assumed that it would "just work". With the current setup, I think users would probably have to include the lib directory in their require statement, like require('precis-js/lib/prepare'). I really dislike exposing the internal directory structure like that.

Let's say this project was re-written in ES6. I'd probably put the prepare module in ./prepare, so that import precis from 'precis-js/prepare' works as intended. But what if you're not running Babel? I'd have to put a compiled version in a different subdirectory, forcing the user to require('precis-js/subdirectory/prepare').

When I first realized this was a problem, I went looking for what other devs do in this situation. I thought there must be some package.json option that magically changes the base directory of the module. Unfortunately not.

To the best of my knowledge, in order to have source code under src, and retain this kind of require pathing, I'd need to write my own wrapper around npm publish that builds the desired directory structure before publishing. I already don't like that added complexity, but I discarded the idea outright once I realized that it would break usage of this module when fetched directly from source control. That is, you could no longer do this and have it work:

{
  "dependencies": {
    "precis-js": "eloquent/precis-js#master"
  }
}

On top of all of that, I don't think this module really has much to gain from ES6 features. It could probably be rewritten in a more functional style that would work just fine without ES6 classes. So even if there's a great, simple solution to the pathing mess I've described above, I just don't feel at this time like the benefits are worth the added complexity of having a compilation step at all.

I'm sure a time will come when browsers all support ES6 and String.prototype.normalize, at which point all of this becomes moot. I'm absolutely looking forward to that!

[sonnyp]

I just don't feel at this time like the benefits are worth the added complexity of having a compilation step at all

Isn't coffeescript a compilation step? My previous point was that with ES6 we wouldn't need one (on modern engines at least).

In any case if you don't feel there's much benefit to a rewrite at the moment that seems wise.

[ezzatron]

Yes, it's a compilation step. I'm saying that I agree with getting rid of CoffeeScript, I'd just rather replace it with already-browser-compatible ES5 instead of ES6.