CoffeeScriptRedux
CoffeeScriptRedux copied to clipboard
michaelficarra
ES6 support
I've started a discussion on the ES6 future of CoffeeScript here. Let me quote the introduction:
ES6 is gaining a lot of spread. It introduces a lot of new concepts into JS. Here are nice overviews: short, comprehensive.
And people already use those features! Thanks to the effort from such projects as 6to5, es6-transpiler and Traceur, for a modern JS developer who does not use CoffeeScript, there is simply no reason not to use ES6 nowadays. Many modern JS projects are already being written in ES6. Moreover, popular JS frameworks already demand that their users code in ES6 out of the box (this includes Angular 2 and EmberJS).
CoffeeScript is essentially locked at ES5. Some ES6 features are accessible via backticks, but others directly conflict with the CoffeeScript syntax, including said backticks. With CoffeeScript's main contributors having explicitly refused to support ES6, CoffeeScript is doomed to become a thing of the past.
I wonder what is the position of CoffeeScriptRedux maintainers on ES6 support. If CoffeeScriptRedux introduces full ES6 support, it is able to take CoffeeScript over completely.
The problem with ES6 support in CoffeeScript is that ES6 overlaps with CoffeeScript syntax. Some of core CS features conflict with ES6, namely backticks and fat arrows, others become redundant (splats, comprehensions, classes, etc). I think that the JS preprocessor of the future should not have its syntax elements mean things different from the modern JS.
I can think of three directions:
- CoffeeScriptRedux maintainers refuse to support ES6. CoffeeScriptRedux dies out together with CoffeeScript and some other ES6-capable preprocessor takes its place.
- CoffeeScriptRedux extends CoffeeScript syntax to support ES6. Nothing is deprecated, but identical syntax elements mean different things than those of the contemporary JavaScript. This makes CoffeeScript an even more hated language.
- CoffeeScriptRedux team decides to start a new preprocessor project, giving precedence to ES6 syntax features. The new preprocessor is as easy to learn for a ES6 user an CoffeeScript was for a ES5 user. Can't be used to compile CoffeeScript, but who needs ES6 support in old projects anyway.
What do you say?
- CoffeeScriptRedux maintainers pull their heads out of the sand and fix the language so that it matches ES6 semantics, breaking backwards compatibility—it is CoffeeScript's "2.0" after all, and breaking changes have already been made. CoffeeScript in the mean time remains compatible with legacy code. The CoffeeScriptRedux compiler is renamed
coffee2or some such shit in order to coexist alongside the already mutually incompatiblecoffee.
Though frankly I'm considering just making a fork with a new name and fixing this myself.
Or you can just jump on the ES6 bandwagon, and help me build a tool to convert CoffeeScript to ES6 :wink: I'm using CoffeeScriptRedux to make the necessary modifications to the source code.
Maybe when ES6 ditches the curlies for indentation. :stuck_out_tongue_closed_eyes:
I would consider that since active development stopped on this project almost 11 months ago (according to the commit log) that any major requests for change are going to fall on deaf ears.
I think we should focus on creating IDE and editor plugins that automatically and flawlessly insert es cruft for you, color it so it's hard to see (because you don't need to), let tc39 innovate the language, and libraries focus on making nice API's for one js.
In the meantime, recognizing import, export, and default as valid tokens and passing them through into the output would be a real painkiller for coffeescript-ember devs right now. This would allow @alexspeller to deprecate his coffees6 hack, and the ember community could use happily use coffeescript with the standard ember-cli-coffeescirpt plugin without the ugly escaped imports and exports.
@michaelficarra Any pointers as to how we could let the import, export, and default keywords pass through into the output?
@devinrhode2: "passing through" breaks the abstraction, and is not how this compiler works. It is a structural transformation, not a text-based one. Sure, we could easily add support for import/export declarations, but the implementation would probably not look like what you're thinking.
I think if you want to add support for import and export statements you should either for CSR and add support to the parser, or continue using a hack to fix it.
The "right" solution, in my opinion, is to move to ES6 using decaffeinate to translate from CoffeeScript to ES6, and babel to transpile from ES6 to ES5.
(I am a contributor to babel and the maintainer of decaffeinate, fwiw.)
The "right" solution, in my opinion, is to move to ES6 using decaffeinate to translate from CoffeeScript to ES6, and babel to transpile from ES6 to ES5.
ES6 is certainly is an improvement, but still nowhere near as nice to code in as coffeescript. It would still make a lot of sense, for people who like coffeescript, to have a way to make use of ES6 modules in coffeescript
@alexspeller I think your coffees6 project does just that. Since CoffeeScript itself does not have, and will likely never have, support for ES6-style modules it necessarily means using a fork or a hack to make it work. I guess I'm not seeing what's wrong with the status quo for those who choose to use CoffeeScript.
What? Why would coffee never see es6 modules going through? Did jeremy say that?
@eventualbuddha it seems like coffeescript is very likely to have ES6 modules eventually, just not immediately
A fork has obvious issues of keeping up to date with the latest version. A hack has issues of being a hack (regex substitution has a lot of caveats compared to real parsing). But it probably is the best compromise for now.
Huh, looks like I was a little hasty. I can't tell if this means "not until ES6 is final" or "not until major browsers implement it natively":
it's probably still better to wait until real JS modules are finished and fully described
If the former, that's pretty soon so maybe CoffeeScript would support ES6 modules sometime this year. If the latter, I'd put it next year at the earliest.
I spent several months switching a large CS codebase to ES6 because we can't see any glimmer of hope for supporting major features like type inference and up and coming ES6 features. My bet is many of those features will never get into CoffeeScript because it will mean major changes to the language itself.
That's why we need a new language, taking up the place of CoffeeScript, offering indentation-based semantics and at the same time reusing modern ES syntax constructs. It could produce modern ES code and rely on Babel for compatibility with runtimes.
@lolmaus that would be ideal, and if magically we could have that I'd be super happy. It seems like a big undertaking though - I wonder how much interest and momentum such a project could generate?
My main worry would be that CS has fallen out of fashion so it would be hard to find contributors, however if it targetted ESNext (i.e. babel) maybe more people would be interested.
And here's my two more cents
I think we should focus on creating IDE and editor plugins that automatically and flawlessly insert es cruft for you, color it so it's hard to see (because you don't need to)
ghetto coffeescript for sublime is where the idea of hiding js syntactical cruft came from.
By making es6 more aesthetically pleasing to work with, the coffeescript project could instead focus on innovating the language, instead of playing catch up. My feeling is that es has caught up to and surpassed coffeescript. Coffeescript has done a great job influencing this new standard; and there's no reason the coffeescript community can't focus on continuing to innovate the language, perhaps with an "automatic cruft insertion" or "use whitespace" directive implemented in an es.next transpiler like Babel.
Transpilers will continue to innovate the language, and I wish the coffeescript project would separate out syntactical sugar with language innovations.
@alexspeller, exactly!
Rewriting CoffeeScript from scratch is a barely feasible task, but we could start with small steps. E. g. collaboratively write an RFC for the new language, agree on nuances, attract more people.
OMG, i'm so happy this conversation has finally started! I almost lost hope.
As for syntactic sugar vs language innovation, there's no distinct line between them. Also, some extremely useful CoffeeScript innovations are still missing in ESNext. For example, ? (the existential operator), i just can't live without it.
I am in this existential crisis as well. I prefer the conciseness of CS, but ES6 is obviously the way forward. I've always thought that a small language that is a close relative to ES6 and CS would be a great alternative. Specifically it would be ES6 with the following minimal set additional CS-related features:
- Indentation-based (maybe optional curlies a la Stylus)
- Statements are always expressions when possible (e.g. if/else, functions return their last value etc.)
- Support for
@ - Some additional (but not conflicting) operators (e.g. the elvis operator)
All other features, classes, destructuring, for of loops, arrow functions, etc. would just rely on ES6. This minimal language (minscript?) would seems like it wouldn't be incredibly difficult to build as it would just output ES6 and then rely on an intermediate transpiler.
So I created an org and repo to explore this - anyone who's interested feel free to comment here https://github.com/babelscript/rfcs/pull/1/files?short_path=4e5e753#diff-4e5e75370db49a9550d4bbe7f0f6f57e
I've setup a repo here as well with a comparison between CoffeeScript and ES6: https://github.com/balupton/coffeescript-to-es6/blob/master/README.md
@alexspeller - Nice! I hope this gets some traction. I love the significant whitespace and lack of keyword noise (prototype, return, this, function) in CS, and really want to see that carried over to something next-gen.
@eventualbuddha I like your idea of using decaffinate and babel because it seems to more naturally fit the idea of extensibility and supporting different target environments.
From what I understand, both CoffeeScriptRedux and Babel generate code from a SpiderMonkey AST. Currently CoffeeScriptRedux is using escodegen to generate the final Javascript, but what if it used Babel for the final generation step instead? It looks like Babel is significantly ahead of escodegen in ES6/7 support, so using Babel would mean that CoffeeScriptRedux would only need to implement parsing support for ES6 features; the ES5-compatible Javascript generation part would be taken care of by Babel.
I have a bit of an additional agenda here, which is that I want to add support for DCI [1] programming to Javascript and eventually CoffeeScript as well, and proper support for it involves the introduction of at least one new keyword ('role') as well as source code rewriting. First I'm planning to implement it in Babel...if CoffeeScript used Babel for Javascript generation as well, then in order to support CoffeeScript I'd only need to modify the parser, rather than both the parser and the generator. So I think this could be useful for those like myself who are interested in adding custom extensions to JS and CoffeeScript, but obviously the more important point is what I said in the preceding paragraph.
[1] For more info on DCI (Data-Context-Interaction), see these links: http://fulloo.info/doku.php?id=what_is_dci http://folk.uio.no/trygver/2015/CommSense-1.14.1.pdf Desired Javascript code (currently implemented with a fork of TypeScript): https://github.com/mbrowne/typescript-dci/blob/master/samples/dci/js/TransferMoney-simplified/TransferMoney.ts
From what I understand, both CoffeeScriptRedux and Babel generate code from a SpiderMonkey AST.
Babel uses Acorn instead of Esprima which is why it's esnext support is way higher.
Yes, I saw that it uses acorn...I thought the esnext support was higher because they forked acorn (https://github.com/babel/acorn-babel - "Acorn fork used by babel - not supported outside of babel usage"), but I'm guessing acorn has better esnext support out of the box too.
I'll throw my hat in the ring of people excited about a new whitespace-based lang.
Personally, I think it should target es7 out of the box (it won't be done till that's out anyway) and support optional static typing, à la TypeScript. But I'm not sure how many people would be interested in such a thing.
One approach is this: https://github.com/rstuven/curlyfy-loader This is a webpack loader that you run before babel, but it could surely be implemented as a babel plugin. This is, I think, the easy part. The tricky thing is getting all the surrounding tooling in place (linting, etc) and getting wide usage.
@rattrayalex Check out PureScript. It is awesome and meets your requirements.
@eldh curlyfy actually looks awesome, almost exactly what I had in mind (would be great to see optional commas, etc).
@michaelficarra PureScript definitely looks awesome! However, I'm looking for something closer to the spirit of "unfancy javascript" - I want to be writing Type/JavaScript without the cruft, not writing another language in the browser.
So, is it not gonna happen? Maybe another kickstarter campaign? I'm starting a hobby project and I'm thinking about what language to code it in. If CSR won't support ES6-7 in future then I'll drop it in favour of the latter.
Ok, I see that I'll likely have to resort to ES6
For those who haven't seen it, there's a newish white-space significant JS language called Earl Grey, with a significant amount of ES6 support: http://breuleux.github.io/earl-grey/
@keithjgrant Thanks, looks cool. Not a fan of python myself but have a friend who will surely like it.
@keithjgrant omg, AWAITs, finally someone got it! no more bulky promise chains? that would be something.
Earl Grey looks quite good. And I noticed that it uses Babel, which seems to indicate that using Babel might be viable for CoffeeScript too (see my earlier suggestion).
I love Coffeescript's syntax over Earl Grey's syntax. I also think that Coffeescript is supposed to compile to javascript, and ES6 is the most recent version of javascript. By not compiling into the closest things(Coffeescript classes become ES6 classes) I think that Coffeescript is falling behind.
Now that many libraries like Angular 2.0 are using ES6 modules, and classes, I believe that coffeescript should be updated too.
(Note: When I say coffeescript I mean this project.)
Just for the fun of it, I wrote up a bit about my “dream compile-to-JS” language: https://github.com/lydell/frappe. If you also like fantasizing about syntax it might be worth a read ;)
@lydell, I've also had the idea of making such a proposal for quite a while now. I like your effort, but I strongly dislike certain implementation details.
I wrote you on Gitter, please respond if you would like to discus the matter.
@lolmaus Yeah, I'd like to discuss things, but it's very likely I'll forget logging in on gitter, because I don't hang out there very much.
(Side note: Frappe has no implementation yet, so there are no implementation details to discuss. But I get what you mean.)
since http://coffeescript.org/v2/ is targeting es6 can we contribute some works from here to there? or already contributed?