Announcing CoffeeScript 2
coffeescript.org
coffeescript.org
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
He also redid the website and the docs for good measure: http://coffeescript.org/
Bravo.
A bunch of people helped out: https://github.com/jashkenas/coffeescript/wiki/CoffeeScript-...
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 which turned into a cooperative effort with jashkenas to move CoffeeScript forward in a responsible way. An interesting story in its own right.
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).
I would still use it though, if there were JSX style xml/html tags. But React changed everything for me and as a full stack dev, I can use only few frameworks on one level.
Edit: Ok, JSX is now supported. http://coffeescript.org/v2/#jsx
And I'm glad they broke the different behaviour of =>. It might need a fix in a lot of code bases, but this price is cheaper than having the mental burden of it.
I wrote a comparison about it a couple years ago: http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/
I'm not doing much react these days (cough elm), but I think it's still mostly relevant.
Here some benchmarks for several of the FWs that are popular in these languages (Elm has the FW built-in, ReasonML-React is missing but should be close to React.js).
https://medium.com/@saurabhnanda/benchmarks-fp-languages-lib...
(args...) =>some small aspects of CS i forgo because they (in my opinion) are a little too concise such that they sacrifice readability, but all in all it has my favorite syntax of any language.
I personally think calling .map() on an array is more readable than an array comprehension. But since CS is "just JavaScript" you are free to use the native JS array methods (and even more elegantly, at that).
result = if condition then success else failureBut wow, "not elegant" is an understatement.
The home page talks a little about achieving this by using Flow annotations in Coffeescript source and then having the build system pass the Javascript output to Flow: http://coffeescript.org/#type-annotations
It is a dilemma, but so far I have gotten by without type-checking.
(I'm joking, but actually.. why not?)
Good interop with Flow isn't quite there yet, though.
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 `;`.
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/ [1]https://github.com/prettier/prettier
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.
; are eyesores to an already fairly technical debt heavy/bloated language.
There's also some odd ASI issues within class bodies.
https://github.com/prettier/prettier/pull/1129 can be a useful reference (and tool!)
I continue using it in my Vue projects and it's a pleasure.
I appreciate the work the team has put into bringing elegance and brevity to my daily life.
You can write JavaScript just fine without semicolons. I used to be in the same camp, but Feross eventually convinced me to try dropping em. Despite being cautious and a bit skeptical, I tried it out in a few projects by removing all semicolons with a search and replace. In every single case, I encountered zero issues.
But for the folks who still do — or have existing codebases — this update is for you.
I hope that this release (and hopefully future releases) will help to keep CS alive. Thanks to all contributors!
To parent post, why should we settle for "good enough"?
Because it's an actual standard and benefits from wider mindshare and support.
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.
i understand the problems these tools are trying to solve, but i don't like that you have to learn two (or more) grammars and syntaxes, and the quirky interactions between them, to get those benefits (because you can't debug one without debugging the other). it's a lot more cognitive overhead for what amounts to a little syntactic sugar.
standard es-whatever javascript needs to be "good enough", and, despite my disdain for using coffeescript, the improvements that coffeescript induced in javascript are heartily welcomed.
This isn't really accurate with respect to meta languages like SCSS that add new features not present in the underlying language, like variables.
You really are missing out on a lot by not using the meta languages.
Well, this is how a lot of JS (if not most) is done today anyway.
These days we have typescript as another option, and I feel like there's more gains from that than the syntactic niceness of coffeescript.
Before anyone tells me, yes I know the semantics are slightly different, but muddling the semantics with arcane syntax is not an optimal solution.
As for () =>, it can make a big difference in scenarios like `myArray.map(a => a.foo)` versus `myArray.map(function(a) { return a.foo })`
I can't think of any other examples. Closures get used heavily in JS and arrow functions do make their use quicker and more concise, as well as fixing `this`. Compared to other languages like Scala, OCaml, Elm and Haskell, with symbols for functional combination and pipelining, pattern matching, and whatever you call the thing where you can miss out parameters and use underscores in function bodies in Scala ... JS is relatively light on symbols.
All these things are irrelevant today.
1/ Most of CS features are supported by javascript
2/ ECMASCRIPT spec is big and complex. Learning another syntax on top of something every front end developer should know is a wasted effort in my opinion.
And for loops (which double as list comprehensions). And the existential operator. And "this." shorthand. Among other reasons. To my team it's also more clean-looking than Python (which used to be my favourite language), esp. when using a good syntax highlighter like Atom's (or at least that differentiates function calls, like Github's).
Yes, there's not much difference now from ES6 regarding features, but for some of us it's still worth it.
It really is a matter of taste, but the large majority of us didn't like it. It is pretty, but I felt like fighting against the language all the time (implicitly returning an bracketless object is not something that's easily readable)
In my experience it has only been a problem when porting existing code bases. We only had to be a bit careful putting a return after a for loop at the end of a function so it doesn't build a list unnecessarily (otherwise implicit returns of unused random values don't hurt). For clarity, one of the few rules we have is to use return explicitly when a function is more than a single expression.
> objects without brackets
The language allows it but it doesn't mean you must use them. We have a loose style guide where we forbid a few confusing uses (like bracket-less one liners or returned objects). So loose it's shorter than this comment.
> no spread operator
It always had a spread operator (except for the first month of life). It's just called splat instead of spread, like in Python. Now it also allows ES6 syntax which is very similar (...foo vs. foo...).
> significant whitespace
That's not a bug, it's a feature ;)
> no variable declaration keyword
In the last year or two, that only bite us once. If it's more frequent than that your functions are way too long.
But as you say, it's a matter of taste.
however i like to point that our entire codebase, CS, JS, TS, Python, Java, Swift, 100% of it already has significant whitespace.
...it's just that the JS/TS/Java also have curly brackets.
The end result (or arguably, driving force) is that even in languages where whitespace isn't significant, people read the whitespace, not the curly braces. So the curly braces are basically redundant noise.
I agree about { } being mostly noise but I think they are the lesser evil. I'm making most of my money with Python and I still believe significant whitespace is a very bad idea. The Ruby alternative of using end is better even if not super elegant (and Ruby is my language of choice). It's on par with curly braces. After 30+ years of programming I still have to find a satisfying solution to the problem.
This could easily be fixed by adding a -!> operator that disables implicit returns, but no, they are so opinionated that a change like that will ruin their perfect little universe. I know that there are forks that add this sort of functionality among fixing some of my other gripes with CS but my point still stands: I'm not going to invest my time into a cult.
The old joke was that Perl is a write-only language, and CoffeeScript et al are essentially thought experiments for how deep into the write-only abyss people are willing to plunge as a non-joke. It's no mystery that CS primarily attracts people who heavily discount the importance of long-term maintainability.
The core issue seems to be that some people have conflated prescience with elegance. We must stop deluding ourselves into pretending there are languages that can read our minds. Put your intent in the code, avoid ambiguity. If the answer is not obvious and consistent, do not rely on either the computer or the human to extract your intent from the ether.
It's not that ES6 is good enough; it's that CoffeeScript is actually "bad".
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.
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.
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...
Edit: Added "in javascript" after reference to make it obvious I was talking about JS behavior for the binding.
Seems to map fairly well conceptually.
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.
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.
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).
Coffee also has -> which desugars to a regular function() {}
I think we're getting our wires crossed. Both Javascript and CoffeeScript have (more or less, for the common use cases) the same `this` behaviour for =>. It preserves the `this` value from the context.
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.
That might be a little naive. I pick Coffeescript in a reflex without even considering ESxx, and I regularly start new projects large and small with it that go into production. It's a breeze compared to some of the modern Javascript codebases I have to work on. My overall development speed is definitely faster in Coffeescript, less bugs, no countless babel add-ons, no linters etc.. and the codebase often speaks for itself, less annotations, less code. Efficiency means a lot to me.
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/
- Less distractions on things that don't really matter in 98% of use cases. Like var/const/let declarations
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
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.
Since this is just keeping up with the already existing ES6, why would anyone bother to move from ES6 to Coffee?
Edit:
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.
Why would ES6 being more widely adopted hurt TypeScript? TypeScript is and always has been ES6 compatible. Are you imagining people would suddenly lose interest in static typing?
JSX wasn't adopted by CS2 at all. It's just that certain things are passed unmolested into the compiled output, which happens to make it jsx compatible. Other similar preprocessors would work, too.
I could imagine TS going to suffer some plague like this to another language that is statically typed like Elm, Haskell, etc., but probably not to JS.
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.
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.
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.
capitalStringsWithX = _.chain array
.map (item) -> item.toUpperCase()
.filter (item) -> item.includes "X"
.value()
var capitalStringsWithX = _.chain(array)
.map(function(item) { return item.toUpperCase(); })
.filter(function(item) { return item.includes("X"); })
.value();Your jQuery example would simply be written:
$ -> _..code here.._
However, the codebase I was working in had no clear style guidelines about when it was acceptable to drop braces/parens and so it left me wanting for Python's "there's one way to do it" aesthetic.
It is even more frustrating in .js repositories today. People use various ESXX flavours and syntaxes that might not compatible with each other.
Just look at this list: https://babeljs.io/docs/plugins/ My favorite is: babel-plugin-transform-decorators-legacy (A plugin for Babel 6 that (mostly) replicates the old decorator behavior from Babel 5)
Talk about code reuse
- Only use {}-free object literals in assignment
- Always add () to nested single-line function calls, and calls with expressions.
def foo(bar):
a = bar + 1
vs
foo = (bar) ->
a = bar + 1So invoking jquery and everything is totally 100% supported. In fact that is how I used coffeescript a few years ago.
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.
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.
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?
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.
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.
> 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.
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.
My question is: Why would you adopt coffeescript in a new project?
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.
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 ;-)
CoffeeScript has saved me thousands of hours of parentheses closing alone.
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 !
http://coffeescript.org/#breaking-changes
Edit: Seems that my computer doesn't consider the cert authority valid for bootstrapcdn.
I know, I know, "what about types". Perhaps it'll get there one day. There's always flow.
Thanks again.
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.
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.
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.
just do it.
If you quit once, what's the likelihood you'll quit again? And how soon? Why waste everyone's time? You'll need to make a seriously good case as to why the company should rehire you.
In Jeremy's case, he wrote a lot of code that a lot of people use around the globe. That adds a lot of value to him. Luckily, for him, the NYT is lenient to bring him back on the job.
Some other companies aren't so nice.
Just ask! And if it's not ok, do it anyway and then get another job. Maybe this is more common over here in europe but basically everybody who really wants to travel does it like this.
On my travels (mostly most of asia, south and middle america, some europe) I have met nurses, doctors, military doctors, journalists, devs (a lot), sound engineer, hair stylists, bankers (he was hilarious), DJs, salespeople, night watchman, ....
Travelling the world gives you more experience, more insights and more perspective than just being another desk jockey like everybody else in the company.
Also never let your actions be determined by fear ("will not be hired again, will not be as valuable in the workforce if I travel for a year, ..."). if you want to travel, just do it. (and read books about stuff that really interests you while you do it.)
And: companies are usually not nice, but the people within companies are most of the time pretty decent, and they usually like people which just do their thing.
I understand that you didn't write anything professionally about your trip, but did you ever write anything casually about it - blog posts or the like? It sounds like it would make for interesting reading :)
Kind of curious about the "bribes" part...
You have to get a temporary import/export permit and country-specific insurance every time you cross a border. I ended up crossing 33, so that's plenty of paperwork to potentially get fouled up on. And in some countries checkpoint cops love busting gringos for their paperwork, because if they're missing something mandatory, that's easy money.
I screwed up the US/Mexico border first by not having done my research. Crossing from Presidio to Ojinaga, I made sure to get Mexican insurance, but didn't think to set Banamex bond for the temporary import permit — not required in the border zone, so the customs officials don't mention it. I didn't have it, and if any official in the length of Mexico had asked me for my paperwork (despite passing multiple checkpoints), that would have been full legal grounds to seize the bike. But I made it to the Guatemalan border trouble-free, and the customs exit officer nailed me for it there. "It's easier if you just pay me the fine." Around $50, I think. I got change from his wallet.
The second not doing my research screwup was not bringing my original title document to the motorcycle with me, just some color photocopies. In most cases, copies are fine — after all, we don't drive around with our titles in our glove boxes. But leaving El Salvador, at the Honduras border, a cop in front of the immigration building decided to make an issue of it. "I'm sorry, but without the original title document, there's nothing that can be done." After about half an hour, with some help from a roadside border-crossing fixer (there are many on the El Salvador / Honduras border, because these situations are notorious there) and a little over $200, the bike and I were through.
Of course, the first thing I did after arriving in Choluteca, Honduras, was to head over to the police station and file a false report, saying that I had left the original title in the top bag of the motorcycle and someone had stolen it, along with a few other miscellaneous documents. When getting yourself out of paperwork trouble, an officially stamped police report is as good as gold. From that point on, at any border where the photocopied title wasn't good enough (Peru, in particular, gave me a really hard time about it), I could show them the police report, show them that the VIN on the report matched the VIN on the photocopied title matched the VIN on the bike, and we were good to go.
Like I said, not NYT-standards behavior.
Are you kidding? Spin the bit about the border-crossing fixer into a homily about capitalism, italicize a list of the meats you ate, and you've got a Friedman column.
I'm sure if the company has a person who creates a tool that is used all over the world under its watch, they would allow that person to take as much time off as he or she needs.
Still, I know people who are --- no pun intended -- the backbone of codebases at their company, and taking a year off and being rehired is out of the question.
What's to stop the company from finding a replacement who can be up to speed with the code in a short amount of time?
The fact that it's very, very hard and the competition is fierce?
Also, this is not a romantic relationship we're talking about. If you leave your place of work, no matter how irreplaceable you are the company is going to carry on as best they can. If a year later you are available again and they still need a person for this position that they know you would fit well, why would they not rehire you?
If the former, then the company is an advantageous position to pick someone from the pool. It's not like ZERO people will apply for the job.
If you're talking about the latter, then it's irrelevant. I'm mainly focusing on the company.
The pool of people as talented as jashkenas, that are looking for a job, and want to work in the NY Times is tiny.
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.
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.