
Announcing CoffeeScript 2 - GeoffreyBooth
http://coffeescript.org/announcing-coffeescript-2/
======
jashkenas
In open source, it's lovely, and fairly rare, to see someone pick up the ball
on a quiet project, and run with it to completion without getting frustrated
or losing interest first.

Geoffrey Booth — with big assists from Simon Lydell and Chris Connelly — has
really gone the distance here, spending a full year working on drafts of
CoffeeScript 2.0 to upgrade it from a language designed around ES3, to make it
as ES6+ friendly as possible.

[https://github.com/jashkenas/coffeescript/commits/master](https://github.com/jashkenas/coffeescript/commits/master)

He also redid the website and the docs for good measure:
[http://coffeescript.org/](http://coffeescript.org/)

Bravo.

~~~
rattray
You can also see on the "Contributors" graph a major increase in CoffeeScript
contributions in the past year or so:
[https://github.com/jashkenas/coffeescript/graphs/contributor...](https://github.com/jashkenas/coffeescript/graphs/contributors)

A bunch of people helped out:
[https://github.com/jashkenas/coffeescript/wiki/CoffeeScript-...](https://github.com/jashkenas/coffeescript/wiki/CoffeeScript-2-Honor-
Roll)

And GeoffreyBooth coordinated the effort, posting regular status updates &
calls for help, handling bugs / feature requests, etc. I didn't realize he was
also writing most of the code!

CoffeeScript2 started with a manifesto at
[https://github.com/coffeescript6/discuss](https://github.com/coffeescript6/discuss)
which turned into a cooperative effort with jashkenas to move CoffeeScript
forward in a responsible way. An interesting story in its own right.

------
ralmidani
CoffeeScript is still very relevant for me. I have two medium-sized Ember
projects written in CoffeeScript (and Emblem and Sass--the original, indented
variety, thank you very much).

I have been looking at React (will probably skip due to the patent license)
and Vue, but cannot imagine going back to semicolons and (excessive) curly
braces and parens.

If you married CoffeeScript just out of convenience (being able to avoid
prototypes, bind, etc.), then it no longer serves much of a purpose. But if,
like me, you fell in love with CoffeeScript's beauty, then no amount of ES6+
features will make it obsolete (as long as you can also keep using those
features directly in CoffeeScript).

~~~
methyl
> cannot imagine going back to semicolons

Actually, Javascript does not require semicolons to be present. If you skip
them, the only edge-case is when you try to start your line with `[` or `(`.
In that case, you can prefix the line with `;`.

~~~
ralmidani
I like consistency. And I am paranoid. When I write JS, I always include
semicolons. When I write CS, it is a non-issue.

~~~
pramodliv1
> And I am paranoid

You _should_ write tests when building a project in a dynamically typed
language to alleviate some paranoia anyway. As long as you have decent test
coverage and use a decent linter/formatter such as StandardJS[0] or
prettier[1], you'll be fine.

[0][https://standardjs.com/](https://standardjs.com/)
[1][https://github.com/prettier/prettier](https://github.com/prettier/prettier)

~~~
sli
Yeah, if your linter/build tool can't handle Javascript that doesn't have
semicolons, it should be considered fundamentally broken and/or incomplete.

So the question to me becomes, if the build tool doesn't correctly parse the
JS that's lacking semicolons, should you really trust that build tool with the
_rest_ of your code? You already know at that point that it doesn't handle
your otherwise-valid semicolonless JS correctly.

------
city41
I can't imagine CoffeeScript will see much adoption these days as most people
seem to think ES6+ is "good enough". I miss how concise functions are in
CoffeeScript and also miss being able to do object literals without the
braces. But there's no chance at all in convincing my team to adopt it, as
modern JS really is "good enough".

~~~
jashkenas
And that's totally fine! I don't get a chance to use it much these days
either.

But for the folks who still do — or have existing codebases — this update is
for you.

~~~
tmzt
Hey, I'm working on a template language that compiles into Redux +
IncrementalDOM. Part of it involves a pipeline syntax similar to underscore or
lodash. I'm wondering what you would consider a modern equivalent of those two
libraries using native methods, iterators, etc. or if vanillajs is sufficient
now.

If anyone wants to take a look it's at tmzt.github.io/isymtope and
github.com/tmzt/isymtope

The #cleanup-symbols branch is much further along and has a mostly working
TodoMvc.

~~~
jashkenas
Hmmm. If you're doing the compilation yourself, I'd imagine you could rely on
what browsers provide these days, and compile to what you need. For the kinds
of data transformations that templates tend to need, I wouldn't imagine that
you'd really find a utility library to be necessary. Check out the Svelte
output, for example.

------
kibwen
Never used CoffeeScript in anger, and I don't see it regaining the level of
hype it once had, but despite its lack of dominance I think it emphatically
suceeded in helping to push Javascript towards its modern (and much improved,
IMO) incarnation. A good recent example of how a technology doesn't need to
capture marketshare in order to have a positive impact on the market.

------
srb-
As a CoffeeScript fan things were looking pretty bleak a year or two ago. In
particular there was zero momentum for new features.

How things have changed! Major kudos to Geoffrey Booth and all involved.
Coffee's beautiful syntax combined with async/await has taken a lot of the
'ick' away from coding in JS, at least for me.

~~~
maxscam
Exactly. I'm glad to see people arent absolutely shitting on it here like they
have been over the past year or two, which is when I started using it,

------
neya
I love Coffeescript. Even with ES6+ around, I ALWAYS used coffeescript when I
work on projects. Because, my end goal is a business user who cares if his
software functions correctly or not, not whether my stack consists of bleeding
edge.

It's easy to oversee the benefits of CoffeeScript - "It just has a nice
looking syntax", but in reality, it saves me a ton of time, not having to type
all those braces. I'm a Ruby guy, it's really the difference between Ruby and
PHP for me.

This is perhaps one of the best news items I woke up to.

------
kbenson
> So a CoffeeScript => is now output as =>

Wait, using the arrow function notation doesn't bind _this_ , _arguments_ ,
_super_ , or _new.target_ [1] in javascript, as opposed to the normal function
syntax. Not being a user of coffeescript, did coffeescript not do that
already, or did they also throw in code to change that in the generated code?

It seem to me it would make sense to map items that match conceptually, not
just notationally (unless it's common to have both coffeescript and JS side by
side). Can someone comment on how this is handled?

1: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)

Edit: Added "in javascript" after reference to make it obvious I was talking
about JS behavior for the binding.

~~~
madeofpalk
Coffeescript's => binds this. Javascript's => also binds this (more or less)

Seems to map fairly well conceptually.

~~~
kbenson
> Javascript's => also binds this (more or less)

Javascript's => doesn't bind this though, and function does, which was my
point (and is what the reference I included was saying). That's a specific
change in JS, and either coffeescript had code in place to emulate the current
behavior in prior versions where they used function(), or they have code in
place now to emulate function() now that they're using =>.

I'm going to update my original comment to be a bit more clear on what I was
saying.

~~~
irishsultan
Old Coffeescript behaviour for => was to use a function where this was bound
to that of the environment. This seems subtly different from having this not
being bound at all (in that you can't rebind it under the new translation),
but that's unlikely to have been a common use case.

The main other difference seems to be that there is no arguments object for
the local function anymore, although once again that's unlikely to be a
problem in most functions defined with a fat arrow.

As someone else also said, there were two ways to define functions, one using
=>, one using -> the latter maps to a normal JS function.

~~~
kbenson
> Old Coffeescript behaviour for => was to use a function where this was bound
> to that of the environment.

Okay, so it sounds like coffeescript 1.0 => was effectively doing what JS =>
does now, so it makes sense to move to the newer JS syntax Thanks for
elaborating! (It's interesting how "binds this" can, and was interpreted in
multiple ways, Perhaps there's a better, more specific wording I could have
used to cut through those misunderstandings, whether they be with those that
replied or me reading their replies).

------
dtech
I respect CoffeeScript for what it did and playing a part in making Javascript
and its ecosystem better.

That said, for a new development, is there any reason to use it over ES6? If
you don't like the current Javascript, Cofeescript isn't going to convince you
(Elm, Purescript, Scala.JS etc. might). The only direct value is see in this
version is as an upgrade target for existing codebases.

~~~
molszanski
> That said, for a new development, is there any reason to use it over ES6?

Obviously your mileage may wary. I think, the biggest reason is a time boost.

\- Less noisy code (no braces etc) that is easier to scan

\- No time wasted on flirting with new ESXXXy stuff

\- There is no callback hell to deal with

\- Writing React code is sweet. As previously noted:
[http://rapin.com/blog/2015/02/03/reactjs-with-
coffeescript/](http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/)

\- Less distractions on things that don't really matter in 98% of use cases.
Like var/const/let declarations

~~~
cos_
\+ very lightweight dependency to pull in, in contrast to installing the
operatingsystem-size babel (tip: there´s also buble)

------
sidcool
CoffeeScript has lost a lot of adoption after Typescript and ES6 gaining its
turf. But by all means it's a good wrapper to JavaScript. Congrats on
shipping.

------
AriaMinaei
I'd happily go back to CoffeeScript if I could keep using Flow/TS/ESLint and
the rest of my toolset.

That's entirely possible, and the setup would look like this:

CS would produce a babel-compatible AST, instead of producing the final ES6
source code. It would simply leave the job of generating the final code to
babel (via babel-generator).

You'd then be able to re-use some (though not all) of babel plugins on top of
CoffeeScript. babel-macros for example will work out of the box:
[https://github.com/kentcdodds/babel-
macros](https://github.com/kentcdodds/babel-macros)

ESLint would mostly work out of the box. Syntactic rules won't be relevant
anymore, such as the one that enforces semicolons, but other rules will be
fully useful. You could still enforce no undeclared vars for example.
Importantly, you'd still see ESLint errors in your editor exactly where they
occur in the .coffee source file, and not in the final transpiled file. This
would work, because ESLint can read a babel-compatible AST which is what CS
would produce. I've already tried in a small POC.

I'm sure it would be trivial to patch TypeScript to accept babel-compatible
AST instead of doing the parsing itself. You'd then use TypeScript as a type-
checker and not as a transpiler (This is already possible iiuc with babylon
7). Type checking would then work in .coffee files just like it would in .ts
files. Some language-server commands like find-references, goto-definition,
and show-type would also work. Refactoring commands of course wouldn't work,
because they are specific to the typescript syntax.

Flow would work out the same way too. Right now it has its own parser written
in OCaml, which produces an AST that is compatible with that of babylon 7. All
you have to do is to bypass that parser and get the AST from CS. You'd then
get type errors inside .coffee files, and all the other goodies you expect
from flow.

\---

There is no reason why one should have to choose between CS and the rest of
the JS ecosystem. The fact that you have to give up type-checking and linting
in exchange for CoffeeScript/SweetJS/your-favorite-stage-1-proposal, is only
because the tools don't play nicely together. They could. And with all the
recent standardisation work already done, that is a low-hanging fruit.

~~~
Fudgel
You might like Lightscript:
[http://www.lightscript.org/](http://www.lightscript.org/)

------
fiatjaf
Since you were changing everything, I thought it would include a bunch of new
revolutionary syntax and features, just like Coffeescript 1 did many years ago
and made the world jump into ES6+.

Since this is just keeping up with the already existing ES6, why would anyone
bother to move from ES6 to Coffee?

~~~
bayesian_horse
Because it's more concise and readable.

------
forty
At work we started node with node 0.6, CS was nice at the time, it would bring
cool stuffs such as arrow functions. Nowadays we are using Typescript, and we
love it. To be honest, I am quite happy we are getting rid of CS, the lake of
variable declaration specific syntax (as opposed to assignment statements) is
really a big bug of the language IMO which can lead to really awful bugs in
your code if you are not careful. We have been using
[https://github.com/decaffeinate/decaffeinate](https://github.com/decaffeinate/decaffeinate)
to help getting rid of our CS files, it works quite well.

------
chicago_wade
Is the language refrence at
[http://coffeescript.org/#language](http://coffeescript.org/#language)
completely up to date with CoffeeScript 2 or only partially?

Edit:

[http://coffeescript.org/#whats-new-in-
coffeescript-2](http://coffeescript.org/#whats-new-in-coffeescript-2) answers
this I think.

> The biggest change in CoffeeScript 2 is that now the CoffeeScript compiler
> produces modern JavaScript syntax (ES6, or ES2015 and later). [...] There
> are very few breaking changes from CoffeeScript 1.x to 2 [...]

So probably that means that the language reference is up to date.

------
maxpert
As much as I love CoffeeScript (because I love Python), I think over time the
project is loosing it's value due to ES6 (Frankly I believe even TypeScript is
going to suffer the same plague soon). One possible incentive for me might be
the toolkit and the pre-built stuff that I can get out of box from such
transpilers (JSX is a good addition for example, however I am surprised why
something like PUG, or HAML was not adopted instead of JSX from syntax
perspective). None the less I greatly appreciate the hard work team is doing
and look forward for stuff like pattern patching and some functional
inspirations.

~~~
breuleux
For what it's worth, Earl Grey has a more lightweight syntax to build HTML,
advanced pattern matching, and looks more like Python: [http://www.earl-
grey.io/](http://www.earl-grey.io/) (Disclaimer: I made this).

~~~
maxpert
You just read my mind... makes me wonder why is this project so underrated.
Will try it out for compile speed and stability.

------
XCSme
TypeScript still seems the much better choice.

~~~
shallot_router
I wish someone could take the best parts of TypeScript and CoffeeScript and
put them together.

~~~
maxscam
I think its likely that at some point in the future cs will get strong type
support. Iirc the creator is opposed to it but theres interest from others.

------
no_wizard
This is honestly the first time I have looked close at CoffeeScript. At a
passing glance, it looks really close to Python with javascript elements added
in. Is that a correct assessment? If it is, this might be for me.

My other question is: how nice does coffee script play with other libraries?
We (unfortunately) use jQuery a lot. I have also been using underscore and
lodash as well. Are those two even needed when writing coffee script? I'm kind
of assuming not, since they're both largely just adding methods/functions.

~~~
ralmidani
If you like Python, you will love CoffeeScript. :)

I have not used Underscore/Lodash in production, but I use jQuery a lot with
CoffeeScript. CoffeeScript does not replace jQuery, although it can make your
jQuery a lot nicer.

As far as other libraries, there really are no restrictions; CoffeeScript
compiles transparently to JavaScript. The only thing holding it back would be
poor support in the specific ecosystem you are working with, such as a lack of
plugins that automate the build process. In that case, you may need to compile
manually or set up your own build script. But other than that, you can use
CoffeeScript in place of JS pretty much anywhere.

~~~
no_wizard
I figured jQuery would be fine. Now that I think about it, I can't imagine why
most things wouldn't really, since all javascript libraries are just
extensions of those things.

Does CoffeeScript just convert the modules methods/functions accordingly when
needing to be called?

Just curious how that works.

Since so much of JavaScript development, especially nowadays, ties into a lot
of frameworks/libraries (modules? I'm not always sure what we want to call
it), I just didn't see a reference (maybe I missed it) on their page in
regards to what it actually looks like to invoke module/framework/library
specific things.

~~~
ralmidani
CoffeeScript does not do anything framework- or library-specific. It simply
compiles your code to JavaScript, which is then parsed and executed as usual.

~~~
no_wizard
Good point. I guess I'm not making myself clear. If I'm working with jQuery,
for instance, do I need to do anything different than I do now in terms of
invoking say, the simplest thing, $(function({_..code here.._}) (or for you
old schoolers $document.ready({_..code here.._}). Thats what I guess I mean.
Maybe I just need to toy with it. I suspect I might be overthinking this in my
head.

~~~
maxscam
Its actually a great example of Coffeesctipt conciseness, the jQuery ready
function is just $ ->

------
jonnytran
Will the next version of Rails include this by default? ...Unfortunately, it
would be a breaking change, so maybe not until Rails 6?

------
jondubois
I never understood the need for CoffeeScript. I especially don't understand
why someone would want it now.

Compilation of JavaScript is a terrible idea. I have worked with loads of
different compile to JS languages. The compile step is a huge pain. The
language has to be much much much better than JS for it to be worthwhile. I
think that even JSX or TypeScript don't cut it... Close but still not worth
the hassle! I used CoffeeScript for 6 months, it was a very lucrative contract
but I had to quit in part because I really didn't like CoffeeScript.

What I love in a language is simplicity and unfortunately, you cannot make
something simpler by adding a layer of complexity on top of it. It might look
simpler at first glance, but it isn't once you start debugging, messing with
source maps and buggy source code watchers.

If there was a native CoffeeScript interpreter inside browsers, then I might
consider using it... Otherwise, no.

~~~
molszanski
Do you use any modern JS tools? Webpack? Require or import? Babel? In my
experience any es6 tooling is much of a bigger pain compared to coffeescript
tooling.

~~~
jondubois
I'm full stack so when I saw the monstrosity of the React ecosystem rear its
ugly head a couple of years ago, I retreated to back-end work mostly (I'm
waiting out the storm).

For my side projects I currently use the Polymer framework so I don't need a
bundler, a compile step or 100 pointless dependencies. The only compilation
that happens is when I vulcanize the front end for production (purely as an
optimization). No transpiling happens when debugging and this saves me so much
time and frustratiom - I just cannot bring myself to use React or TypeScript.

~~~
molszanski
That is kinda the point. CoffeeScript pipeline is literally nothing compared
to modern a frontend pipeline complexity. And it brings tons of goodies. That
is why people use it, even now.

------
ricardobeat
So great to see a good release after all these years. Congratulations to all!

I'm curious though about what happened to the Kickstarter project that took a
few grand to write what was to be "CoffeeScript 2" at the time - did any of
that code end up in this release?

~~~
jashkenas
It didn't.

Although Geoffrey and folks considered a rewrite of the compiler along the
lines of Michael Ficarra's CoffeeScriptRedux, they decided it was more
pragmatic just to work with the existing compiler and get it to produce Modern
JS instead of the Lowest-Common-Denominator JS it previously output.

A wise choice, especially given 2017 interest and energy levels.

 _Edit:_ To be clear, to the extent anything can or can not be considered
official in open source, Michael's project was his project, and never made it
in to the main repo. We encouraged it just as we'd encourage anyone to try and
make an independent implementation — but CoffeeScript has never asked for
financial support.

~~~
ricardobeat
Agreed, getting this upgrade out the door in 2 months is a monumental
achievement and I can't imagine a full rewrite happening at anything close to
that pace. I'll be happily hacking away with CoffeeScript 2 + Crystal this
weekend! Thanks for being awesome :)

------
Yaggo
Huge thanks to CS2 team! Great to see CoffeeScript alive again and targeting
ES6, making lot of easier to to choose it for new projects.

I never abandoned CS or converted existing codebases to ES6, as I feel that
ES6 hasn't much to offer compared to CS, and you lose the elegant syntax,
which was always the major selling point for me (former Pythonista).

CoffeeScript is closer what Javascript was originally meant to be, before
Brendan Eich had to adopt Java-like syntax, a decision made by Sun marketing
team.

------
kuon
I really liked CoffeeScript, it's a good way to generate sane JavaScript. But
I have switched to Elm for larger projects. The maintainability it brings is a
lifesaver.

------
rw2
I love coffeescript, I don't find anything else in Javascript that reflects
the strict spacing of python and also shorten the code in a pleasantly
communicative way.

------
kodablah
While I understand the let vs var thing, I wish I could tell the compiler that
I promise not to non-obviously reference a local var (e.g. in an eval). Then
CoffeeScript could determine it is only written at decl time and could use
const. Technically, this could be used for var scoping too in the let vs var
issue.

> Keep in mind that const only protects you from reassigning a variable

While I haven't looked, I'd suspect there are performance implications too.

------
ludicast
Congrats!

I loved the elegance coffeescript & it was the language that convinced me JS
was a reasonable target.

Though I, like many, moved to TS, I use CS every day via its spiritual child
es6.

------
brad0
I think this is great! It allows people using an existing coffeescript code
base to transpile to the latest ES.

My question is: Why would you adopt coffeescript in a new project?

------
feelandcoffee
I don't know what to think about coffeescript anymore. I love it back then
before babel and ES6, but right know I didn't even know how to use coffee and
a library used today. Still miss the python/ruby-sque sintaxt witouth
brackets.

Edit: After reading more about the changes about CS 2.0, I may give it one
more chance, let's see how it work now.

------
virtualwhys
Huh, just finished migrating a small 5K front end from CS to Scala.js.

Miss the concision of CS, both in terms of syntax and generated output, but
otherwise really enjoying _typed_ JS. Also, it's kind of cool not immediately
knowing whether a particular source file is for the front end or back end --
like, oh, wait, this is the front end ;-)

------
skilesare
Been following for a while. Great job getting it out!

CoffeeScript has saved me thousands of hours of parentheses closing alone.

------
elbywan
I used CoffeeScript for personal projects and absolutely loved the syntax.

Wasn't able to promote it at work though, because of the lack of support at
that time (it felt kinda rusty, most 3rd party libraries were deprecated, and
no jsx).

Glad to see things are changing, the new release looks great !

------
bpicolo
The breaking changes page is ironically quite broken (latest chrome)

[http://coffeescript.org/#breaking-changes](http://coffeescript.org/#breaking-
changes)

Edit: Seems that my computer doesn't consider the cert authority valid for
bootstrapcdn.

~~~
SquareWheel
Seems to work here okay. Also latest Chrome.

~~~
83457
I tried before and after the very latest update without a problem.

------
enturn
It would be nice to have a date on the announcement page. I can only assume it
was published on/around September 17, 2017 by looking at the changelog.

------
ajobaccount2017
I wish someone would do the same for LiveScript.

------
root_axis
I love CoffeeScript. Thanks for this.

I know, I know, "what about types". Perhaps it'll get there one day. There's
always flow.

Thanks again.

------
catacombs
Jeremy,

First off thank you for Underscore, Backbone and CoffeeScript. Your work
really has helped me and my development team.

This question is a little off topic but one I've been wanting to ask for a
long time:

Last year you took a year off from The New York Times to ride your motorcycle
across the Western Hemisphere. Just recently you were hired back at the paper,
doing what it appears to be the same thing in the graphics department.

From a hiring perspective, did you have to reapply for your job, or did the
Times just give you the necessary time off?

If this was considered a "sabbatical," how did you justify traveling around
the Americas as something that could benefit the paper?

I don't mean to offend. I'm genuinely curious. A lot of people aren't
fortunate enough to take a year off for traveling and then be rehired at their
company, especially in the journalism industry with the revenue declines, job
cuts and managers wanting to hire cheaper people.

Thanks again for all you've contributed.

~~~
jashkenas
Happy to answer, although this is a bit of a funny forum for it:

From a work perspective, it's pretty simple. I quit, and then was rehired to
the same position a year later.

But The Times' Graphics Desk was super nice about it. We had a handshake
agreement that I'd come back when I got back, and they even lent me a laptop
to maybe file some travel-ish bits and bobs from along the road. So in that
sense, it was partially justified.

In the end I didn't end up writing anything for them for a few reasons: I
didn't want to turn the ride into work; I wasn't on my best NYT-standards
behavior (booze, bribes, women) — well, one spectacular woman, and we're
married now; and finally, I personally hew somewhat to the Janet Malcolm
attitude:

“Every journalist who is not too stupid or full of himself to notice what is
going on knows that what he does is morally indefensible. He is a kind of
confidence man, preying on people's vanity, ignorance, or loneliness, gaining
their trust and betraying them without remorse.”

Especially with respect to travel writing. You can do it right, but you really
have to take the time and be invested and involved. And I was riding to follow
the seasons and wasn't.

Ultimately, even though the industry as a whole is in decline, the NYT and
other world-class news sources are still strong, and in some ways, getting
stronger. In particular, the visual journalism The Times publishes every year
keeps pushing the state of the art.

~~~
catacombs
I admit it is a funny forum to ask this, but, hey, here we are.

Thanks for the response. It seems your situation was unique, and you're
definitely fortunate to have a department willing to make this agreement.

The Average Joe more than likely can't pull this off, especially if the
company can hire a replacement.

~~~
markdog12
I'd say NYT was fortunate to have him, and realized it.

~~~
jgalt212
agreed, he's a star. And companies, rightfully so, do pretty much all they can
to retain stars.

------
FractalFlows
Great!

------
Akujin
Augh. Anytime I see a Coffescript project all I see is wasted money trying to
recruit engineers who actually want to use it. 90% of people who write
JavaScript roll their eyes and move on.

~~~
ralmidani
Another way to look at it: you will only draw developers who share your
appreciation for whitespace-significant languages.

I have worked on two startups with a fellow programmer who knew Python but not
CoffeeScript. He picked it up very quickly, along with Emblem (indented
Handlbars alternative, useful for Ember projects) and indented Sass. Once we
told the text editor to insert 4 spaces in place of tabs, we had much less to
worry about in terms of stylistic disagreements.

------
camus2
First congrats, this is hard-work. Second I implore people not to use a
language where the designers think breaking changes are OK, while giving no
real advantage over plain modern Javascript or the use of a linter. Worse,
since CS has slighly different semantics than JS it will lead to so much
confusion. Coffee Script served its purpose, now let it rest.

~~~
creatonez
>Second I implore people not to use a language where the designers think
breaking changes are OK

This is a big deal when you also have to use libraries written in the same
language. Python 3 being a fundamentally different language (the underlying
bytecode is not backwards compatible) from Python 2 made the transition very
difficult.

However, this will never be a problem for a javascript transpiler.

And also, the list of breaking changes really isn't too incredible. I imagine
it'll be fine for most coffeescript projects to take this update quite
liberally, as it shouldn't be too hard to write CoffeeScript 1.x/2.x polyglot
code to transition to the new version.

