What is the future of coffeescript? #4288
Comments
|
I'm stuck in the same situation, and am unsure if I should continue to use coffeescript or move to bare ES6. That said, I think I'll miss the coffeescript indentation. The other issue I have is that I can't take advantage of some of the new features of ES6 with coffeescript. It feels like coffeescript will no longer evolve and is 'final'. |
|
There is a discussion about creating "CoffeeScript6", but it seems to have quickly devolved into an effort to build a different language with the same name, to be honest. Hopefully something good will come of it. There's plenty of enthusiasm. I am trying to contribute to CoffeeScript6, but the way the discussion quickly turned away from ES6 support, and towards adding novel features and changing things that are not even broken, convinced me that it's better to gamble on a future centred around DSLs, where every big project has its own dialect of ECMAScript, and people create new languages every week. I've started working on a library that helps you quickly create handwritten Pratt parsers that will be compatible with all the standard ES language tools. These days, a library that lets people write their own languages will probably end up more popular than the most popular language anyone uses the library to create. |
|
Yeah I agree completely with what you're saying. I can't see CS evolving here - rather, I imagine a fork will take over (although I'm doubting CS6) |
|
Similar case. I've start working with coffeescript because the new "ecmas" were not to my liking. For such a good project, that helps productivity immensely, it feels like it doesn't receive the deserving attention. Best regards to your project @carlsmith ps: nowadays, suggesting CS has became a fast way to get the "for real, man?" look. |
|
Ugh, please let's not have a fork. I'm using Coffeescript on some legacy applications, and if I have to change languages from "CS" to "CS-ES6 Hybrid" to get the latest and greatest features, then why not go the whole hog and switch directly to ES6? I'd strongly support any attempt to improve Coffeescript, not to let it die off and be replaced by a pretender. Of the Coffeescript successors, the one that I like the most is Iced-Coffeescript which is a superset of Coffeescript and simply adds additional features to an existing Coffeescript codebase. However, I have not used Iced Coffeescript yet, primarily because I haven't needed those additional features that Iced promises. So I don't know if Iced would actually be something I want to use in production. |
CoffeeScript classes can not extend ES6 classes, which makes CoffeeScript incompatible with ES6 JavaScript libraries. Unless someone thinks up something clever, CoffeeScript will have to break backwards compatibility, so a fork seems inevitable. Using language like "ugh", "die off" and "replaced by a pretender" is just being negative for no reason.
Because CoffeeScript is better than ES6. We're not trying to support legacy codebases, else we'd be maintaining the current compiler, not trying to gather support for backwards incompatible version. No one is creating a hybrid. A growing part of our community are concerned about the future of CoffeeScript, especially its incompatibilities with ES6. Discussion was taking place, but it was all in CoffeeScripts Issues, which isn't the best place for it. We now have a dedicated place for the this section of the community to gather, where we can share our knowledge and ideas in open discussions, and where we can build a wiki documenting features (actual and requested) and relevant previous discussions about each feature. We're currently just figuring out what we know and what we eventually want to build, establishing consensus where possible and documenting any conflicts. Our ultimate ambition is designing a popular dialect of CoffeeScript (that's fully compatible with ES6) with the language tools we need to use it. Realistically, that may never happen (in part, due to that fact that every other CoffeeScript user wants to design their own language), but we're still building a useful resource for anyone designing new languages for the Web. I've learnt a lot from the discussion so far, and it's really early days. If we can build a larger community, there's a lot of scope for establishing common goals, collaborating on open source projects that pursue those goals, and maybe ending up with a happy ending to this story, whatever it eventually looks like. It's fun, worthwhile, and you're very welcome to join us. |
|
I'd strongly appreciate it if we didn't get to ad hominems or promotion of everyone's pet project in this one thread (unless they work nicely with ES6, of course.) |
|
@carlsmith what's the current state of the discussion? I don't see a major reason not to break backwards compatibility and start with a strong "dialect" of CS that takes as much of the language as possible and brings it to a more current and future-proof version. It just needs momentum, exposure, backing etc... |
No, I'm not being negative (and I apologize if it comes off like that). I'm just expressing disappointment about how the only possible solution at the moment is to write a brand new language that breaks backwards compatibility. That's a new language, not the CoffeeScript I know. It may be better than the CoffeeScript that I know, but it's still a new language, which means it will be a pain to migrate a legacy codebase to it. This new language (or languages, if your Pratt project succeed) will thus have to compete on the language marketplace like everyone else. I can have some traditional loyalty towards CoffeeScript, but none towards their successors; I have to evaluate them equally like every other language. I can understand why you have to do this, and I wish you the best of luck in your endeavors...but...as you said:
And I can understand your priorities, which means that I hope you can understand why I prioritize the support of legacy codebases more. |
I'm hopeful we're going to keep the original front end, just fork the codegen part, and keep it close to the official CS project. There'd be a breaking change to make CoffeeScript classes compatible with ES6 classes, then we'd just incrementally update the code generation logic to output ES6, but not change the semantics. If we do it that way, we'll always still have the exact same language (except for classes), so it'll be fairly easy for people to migrate CoffeeScript they still maintain to the ES6 compiler. New ES6 features added to the official compiler will compile to ES6 anyway, so they'd be relatively easy to merge. There's no new language then. We'd just be adding a new code generator for the official frontend, that targets the latest engines, and leaves support for old browsers to other tools. You could still use the old generator, and the only breaking change is where ES6 broke CoffeeScript. There's been a lot of feature requests in the other repo, and it's been pretty fun, but I think we realistically have to limit the scope to just ES6 support, and not add features that are not in the official CoffeeScript compiler. It is a perfect opportunity to fix things, while we're breaking BC, so it's tempting to try, but it seems like we'll just end up bikeshedding forever. We can use those features for our own projects. |
|
@carlsmith @tra38 @erichonkanen @vendethiel @jackytedy @celicoo @ozjd |
|
If indentation is the most important feature for most of the commenters here (I'm included), wouldn't it make more sense to strive for an ES6 equivalent with support of indentation style instead of brackets? |
|
If you just want to insert an implicit opening brace on each indent and The real issue with languages that support significant indentation is that they normally disable significant indentation inside expression groups, args lists, and array and object literals, so anything that uses a block (like a function) can't be a part of one of those expressions. If you look at this broken Python code: def f(): # indentation is significant here
pass # no problems
array.forEach( # indentation is insignificant from here...
def _(each): # this is a syntax error
print each # can't indent a block inside an args list
) # indentation is significant from here...You can toggle significant indentation on a stack, which is what CoffeeScript does: # indentation is significant from here...
array.forEach( # indentation is insignificant from here...
(each) -> # indentation is significant from here till the end of the function...
console.log each # can now indent a block inside an args list
# indentation is insignificant from here...
) # indentation is significant from here...Python rejected a PR for adding this logic because it's too complicated and creates the problems CoffeeScript has with array literals, where the comma often has to be on its own line. Still, as CoffeeScript users, we've found in practice that it's intuitive enough that you almost never have to really think about it. It's easy to make indentation significant, but to get a JS syntax with significant whitespace that really works is more complicated than it seems. |
|
indentation is definitely one of the major reasons I like CS... that's of course coming from years of writing python... |
|
Still not sure why everyone still jumping over each other to support ES6. ES6 doesn't even work in Safari and has some known performance issues. What you can do is just take ES6 and take the curly braces out of it? Viola, you have a new CS6. |
Because we use JavaScript for more than cross-browser Web applications.
Why not do it then? It'd only take 20 minutes, and you'd have a very popular project that requires zero maintenance. |
|
I am probably not the best one to opine, since I have only been using CoffeeScript for a few months, but it seems to be the most popular alternative to JavaScript, and I think that it does fairly well in this aspect, I really enjoy using CoffeeScript over JavaScript, probably due to the expressiveness and the elegant syntax (I'm a sucker for elegant syntax). The integration with tools like Grunt is really good, probably due to the popularity. I can only imagine switching to Iced CoffeeScript (callbacks are really a thing in JavaScript land*), or ClojureScript (I think its syntax is elegant ¯_(ツ)_/¯ in its own way, no commas!). Therefore, I wish the best for the future of CoffeeScript, because my own future depends on that. So keep up the good work, and thanks to everybody contributing to the project! .* Disclaimer: I have been using Iced CoffeeScript for the last few days. |
|
Honestly, why can't we just change the backend to es6, add await/defer and be done with it? |
|
I'm evaluating this decaffeinate tool. Any comment is helpful. |
|
Hi, I'm a contributor to the decaffeinate project (the most active contributor recently), and I figured I'd throw my opinion/perspective in here. To be up-front and avoid any possible confusion: the main goal of the decaffeinate project is to help people migrate a codebase away from CoffeeScript and to modern JavaScript. Both the primary maintainer and I view CoffeeScript as a dying language and want to make it possible for people to move their code to JavaScript, where there's a much more active community and much better tooling. In my particular case, the company I work for is writing new code in JavaScript, but there are still about 200,000 lines of legacy CoffeeScript code that would be nice to move over to JS if possible. Decaffeinate still needs a lot of work before it can run on a large codebase without crashing or introducing bugs, but it's already quite useful for converting individual files in a one-off way. That said, I do have plenty of respect for the CoffeeScript features that aren't (yet) in JavaScript. There are some features that I really wish I had in JavaScript, like In my opinion, a new CoffeeScript should be an extension of modern JavaScript, among the same lines as JSX and Flow. Babel, eslint, and the rest of the JS ecosystem already have fairly good support for language extensions and custom parsers, so you would be in good company. This also would make it easy to work incrementally: you could release little improvements to JS one at a time (maybe The problem, of course, is that it wouldn't be real CoffeeScript anymore. While modern JavaScript and CoffeeScript have many similar-looking features, there are lots of subtle differences. Classes, destructuring, and default params all work a little differently, among other things. It's basically impossible to take this "JS extension" approach and end up with a language that's backcompat with existing CoffeeScript. I suggest that you give up on these old semantics. They weren't what made CoffeeScript great, and the behavior in JavaScript is now accepted and here to stay. So how do you deal with old CoffeeScript codebases? Well, one idea is to run the codebase through decaffeinate and then write some follow-up jscodeshift transforms (or a similar tool) to migrate the JS code to this new CoffeeScript-like language. Another approach is to fork decaffeinate or write a similar tool that can take advantage of what the code looked like in CoffeeScript. It would hopefully be an easier problem than decaffeinate, since a lot of the challenges in decaffeinate are dealing with features like As I mentioned, I'm not particularly interested in using these types of experimental/non-standard features in real production code, but if they got enough traction and stability I would seriously consider some of them. This approach could also serve as testing ground for new JS features, just like how many of the best features in ES2015 were pioneered by CoffeeScript. Anyway, I realize that there are lots of different approaches that people want to take for the future of CoffeeScript, but I thought I'd throw this suggestion out there (and I realize it has overlaps with some previous suggestions). Rather than trying to compete with the JS ecosystem, this would allow a new CoffeeScript-like language to be a part of the JS ecosystem and benefit from its community. The backwards-incompatibility would add a lot of friction, but my impression is that it would still be the best way to modernize CoffeeScript. |
|
I'm actually working on a library that lets users define and parse custom dialects of JavaScript into Babel ASTs. It's not precisely JavaScript that it parses, as it simplifies whitespace (so you can safely omit semicolons) and the API assumes your dialect uses Paren Free Mode, but it parses dialects of a language very similar to JavaScript. It lets you define a dialect by just cherrypicking the features you want, from a growing list of grammar definitions that are bundled with the library, and there's an API for defining new ones. It's all working, but still being written, and not ready for use yet, but it's certainly possible to do a general purpose parser that can easily be extended. You need to write the parser by hand though. I should have something to show people within a couple of weeks. |
|
Hi, I just discovered this thread. So regarding the coffeescript6/discuss repo, its original owner @rattrayalex turned it over to me because he was more interested in creating a new language inspired by CoffeeScript, whereas I am more interested in reviving CoffeeScript’s market share. I’ve been working to shift the focus from a freewheeling “what kind of language would we want if we didn’t care about backward compatibility” to a specific “what are the most important ES2015+ features to add support for in CoffeeScript, and how; and after those are done, then what?” You can get a good summary of the direction by reading the updated readme. In particular, I and a few others are prioritizing adding support to the current CoffeeScript compiler for any features that imperil interoperability between CoffeeScript and modern JavaScript libraries and frameworks. At the top of our list is adding support for modules, which is now a nearly-complete PR. Next on the list is classes. I encourage anyone who has an interest in the growth of CoffeeScript to join the discussion, and especially to help with coding some of these features. |
|
It all depends on your perspective, the way you view or want to view things. Coffescript (CS) is pretty much alive and kicking for me and my team. We are about to start a new project for a hybrid mobile app (based on Cordova), and we will use CS, as we did in the last three projects. Companies like Microsoft, Facebook and Google put a lot of resources to promote their alternative to Javascript, like paid forum posts and articles in magazines/websites and improving search rankings so that links related to their products appear first. That creates the impression that "everybody" is using those products. They know that people are easily impressionable by an article titled "X is dead", in this case, "X" is CS. And again, articles like those are ranked high on Google searches. Search for "coffeescript future" and see it for yourself. From my point of view (perspective) decaffeinate is pointless and ES6 is stillborn, along with Typescript. Those 2 languages have copied features from CS, but not its conciseness, elegance, agility. I have studied them and I don't see a logical reason to stop using CS. And even if there were something, CS could do what those languages have done, and copy their ideas. |
|
@alangpierce your proposal sounds fantastic, is it something you think you'll ever intend to pursue? |
|
@DomVinyard no, most likely not. Frankly, I'm pretty happy with modern JavaScript, and I think that, at least for me, the potential benefits of the new language features wouldn't be worth the huge amount of effort that it takes to build a new language (or even a language extension). However, I recently had a chat with @rattrayalex, and he's working on a language that takes a similar approach. So something like that may end up happening. |
|
All, I've just created a Survey for devs/teams with maintained Coffescript codebases: happy with CS, or considering migrating? over at coffeescript6/discuss. Many of the 'Coffeescript nextgen' issues currently raised are about which ES6 features should be added to Coffeescript. I presume this is driven from the viewpoint of "why should Coffeescript be chosen when starting a new project"? It would be great to get opinions from the viewpoint of "why should we keep using Coffeescript in an existing project?" |
|
fwiw I'm using coffeescript in 2 new ambitious projects despite some reservations personally and from my business partner... I refuse to give in! |
|
The reasons for CoffeeScript haven't changed. ES6 is still a flawed language: it still has the |
|
Some guys recommend me to learn and use TypeScript, which is being used with Angular2. "CacaoScript" |
|
If Crystal can have type inference, why not CacaoScript? If CacaoScript has type inference and not significant modifications in the look and syntax of CoffeeScript, why making yet another language? I'm already using Iced CoffeeScript, and I think the fragmentation is already too much. I would like to see reunification. I understand that producing readable JavaScript is a nice feature, but also a strong limitation. If CoffeScript doesn't cross that line, many will (many are doing), all that it takes is a strong support from some company to take the lead and do that reunification. Alternatively, there are languages that may take the frontend from the backend. I'm thinking specifically of Scala.js and ClojureScript. Certainly they are less popular than CoffeScript, for good reasons, but being less constrained to evolve and improve, that may not be that way for long. |
Just swap TypeScript with Flow or Inferno. No idea why you're pointing at Crystal, they have nothing in common. CoffeeScript only knows about a file at a time.
That ship sailed 3 or 4 years ago. And with yield/async now in CoffeeScript, there are less and less reasons to use Iced.
I have no idea where you're coming from. They are far more constrained than us. We don't have a JVM backend or hundreds thousands lines of compiler code. |
|
I come from outside of the JavaScript community, and the continuation passing style is horrible no matter what. Iced is not a perfect solution, but still much (much) better than yield/async. CoffeScript syntax is more similar to Ruby/Crystal than JavaScript, that example makes my point easier to picture out, IMHO. I would expect something to be to CoffeeScript what Crystal is to Ruby, which is very different from what Flow is to JavaScript. ClojureScript has macros. They are experimental now in Scala. I don't think you understand what being constrained means (in this case by staying too close to JavaScript), and I cannot (should not) give you a lecture on compilers. BTW you probably mean Infernu, Inferno is for React. |
YMMV.
I don't think it is, but hey again: YMMV. Also I still fail to see the relationship between syntax and semantics.
So you expect CoffeeScript to target LLVM and have static type checking and be totally incompatible – so really, just to copy bits of syntax? That's exactly the opposite of what CoffeeScript is.
Well, scala macros have been experimental for more than 3 years now. If you want macros, use BlackCoffee (or something along those lines). And if you want something that doesn't say close to JS, CoffeeScript is the wrong tool.
I don't understand why you feel the need to point out you know all and we know none, we're just discussing stuff.
Yup correct, I didn't correctly keep track of the renames. |
|
Thanks to @GeoffreyBooth, @lydell, @rattrayalex and others — it looks like CoffeeScript has a pretty well defined future direction at this point: CoffeeScript 1.X is backwards-compatible, runs-on-toasters CoffeeScript, and CoffeeScript 2+ targets modern JavaScript features to the greatest extent possible. Scripts are not generally compatible between the two versions. That's the plan. |
But, conversion should be reasonably trivial right? Some sort of wording to evoke the desire to keep coffeescript as coffeescripty as possible. |
|
@DomVinyard yes, the idea is to maintain as much backward compatibility as possible, within reason. There might be a few cases where backward compatibility is broken deliberately, such as dropping support for code in class bodies, to conform with ES specs. Many of the breaking changes will be a result of outputting ESNext, like how the ES We’re not planning to make “cleanup” changes like renaming |
Conversion will be reasonable — but I wouldn't call it trivial. If you've taken advantage of some high-end CoffeeScript features (executable class bodies for metaprogramming for example) and we're not able to support them in 2.X, there will be a bit of rewriting you'll have to do. |
|
Nice if CoffeeScript 2.x is being developed, but, please, it should be a coffee with ice. |
CS 2.0 could/should do those cleanup changes, The 2.0 project presents you with the opertunity to refine CS, make it better, since it has breaking changes anyway. I say it again, discuss/newSugars has to get resolved and I think that this kind of discussion should go there too. It's a general issue. |
|
@jashkenas is there any sort of milestone date for 2.0 release planned? Or is it at a conceptual state at this point? |
|
Not conceptual since some code is there already. But certainly not as polished. |
|
The Coffee Style Smart Computer Language should be the future: coffeescript6/discuss#49 |
|
Any comments on WebAssembly? Even though it's in early stage, it seems to be a gamer changer in the future. Will CoffeeScript be compiled to wasm directly? |
|
No, at it doesn't make sense to do so. |
|
This will be the same answer we've given over the years e.g. with asm.js: CoffeeScript has JS' semantics. WebAssembly doesn't even have a GC. |
|
I guess there maybe languages other than JavaScript we need to consider, if WebAssembly becomes a big thing. That's why I raised the question. Maybe it's in the too far future:
|
|
@jiyinyiyong I will be glad to see some language compiled to wasm with similar to CS syntax. But that's another story. |
|
how can we help out? I've never helped write a language or anything like CS but if I can help on some specific tasks I can contribute... written plenty of js/python for years so I'm not novice or anything |
|
@erichonkanen we would love help. See https://github.com/coffeescript6/discuss, coffeescript6/discuss#36 and https://github.com/jashkenas/coffeescript/milestone/10 And the wiki pages on this repo, especially https://github.com/jashkenas/coffeescript/wiki/%5BHowto%5D-Hacking-on-the-CoffeeScript-Compiler and https://github.com/jashkenas/coffeescript/wiki/%5BHowTo%5D-How-parsing-works |
and others
I am a long time user and proponent of coffeescript, much preferring the indentation-based/python-like syntax to native javascript. I've worked on some very large codebases that were written entirely in coffeescript with 50+ developers around the world touching it. I've used it for all of my personal projects etc.
That being said the past 1+ year I've switched to using the ember.js client framework which is a big proponent of babel/es6/es7 etc. Initially there were developers that also used coffeescript but lately it seems like it has died off completely. If I bring it up that I prefer and use it, it's usually scoffed at.
Recently I'm working on a new project using ember on the client and a concern my partner brought up is "where is javascript heading?" and "will we be able to find good coffeescript/ember developers in X amount of time?"
So now I'm pondering, with everyone seemingly pushing es6+, what is the future of coffeescript?
The text was updated successfully, but these errors were encountered: