Does anyone use coffeescript

I think we'll ask the same question about Typescript in the future; I've integrated into a UI project I work with other people, to make one of our devs happy, but I won't use it myself. A few years ago I remember having one colleague who wanted to write in CoffeeScript but at that time we didn't know how to interoperate with JS, I believe?

Or our tooling or knowledge wasn't the best, so we decided not to let him write CoffeeScript; From time to time I hear from that team and the project is still alive - luckily they don't have to support CoffeeScript. I think you should use whatever makes you happy, for your own projects, but in a team, have in mind others and the future.

Typescript gives real benefits with type checking vs CoffeeScript which just looks sort of like Ruby. No, but it paved the way, in many respects, to those newer approaches — and Ecmascript itself evolving. 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. 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 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. 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?

Given that JavaScript is now very fast evolving, has most of CS features anyway, and adapting the JS tooling to "know" about the indentation change will be easier than creating a whole new thing.. If you just want to insert an implicit opening brace on each indent and n closing braces for n levels of dedent, it's trivial. You have to create your own logic for significant newlines as well though, assuming you don't want to use semi-colons.

That's not difficult, but users have to have a way of disabling them to continue a statement across multiple lines, and your parser needs to ignore them in certain places and infer them in others. 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:.

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.

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. 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. Therefore, I wish the best for the future of CoffeeScript, because my own future depends on that.

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 , 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.

There are some features that I really wish I had in JavaScript, like?. There are other features, like optional parens and commas, that I'm not personally a fan of, but I understand why people would want them. My personal opinion is that these extra features aren't valuable enough to diverge from official JavaScript in production code, but I do have some thoughts on how I would go about that if I wanted to:.

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?. You wouldn't need to design a language from scratch or argue about details that have already been decided in JavaScript; classes, destructuring, etc would all be there automatically because it would just be JavaScript with some syntax sugar.

People using this new language would mostly automatically be able to use eslint and other tools, and as new features get added to JavaScript, they would pretty much be pulled in automatically. To be honest, I haven't looked at the technical details of how to make this all work, but my impression is that it would be possible. 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?. This approach could also serve as testing ground for new JS features, just like how many of the best features in ES 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. 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. Hi, I just discovered this thread. 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. Coffescript CS is pretty much alive and kicking for me and my team. It seems silly, when put into the context of other programming languages, that a common question in JavaScript is ' What's the best way to define a class in JavaScript?

When asking how to define a class in any other language, would it as the StackOverflow mod put it ' likely solicit debate, arguments, polling, or extended discussion '? I would say NO. Most languages have a clear way to define classes, e.

JavaScript is a language limited by few rules and its ability to define OOP-ish classes in many ways is powerful, yet confusing to many. CoffeeScript solves this by adding the class keyword:. Note: is short for this. This compiles to the ugly JavaScript:. This JavaScript code is not as straight forward or trivial as the CoffeeScript code. It includes in it non-obvious fixes to some JavaScript gotchas. Note: in the podcast JavaScript Jabber Jeremy Ashkenas discusses why this particular class definition is used.

There are loads of other things that I like about CoffeeScript, but the things I discussed in this post are the reasons I love CoffeeScript. They remove the ugliest parts of JavaScript to show its real power.

Other things like list comprehensions, for loops, array slicing, splats The Little Book on CoffeeScript. Sign in. Why should you use CoffeeScript instead of JavaScript? Graham Jenson Follow. Maori Geek Tech, Programming, Whatever. Removing Dependencies to Scale Everything.