
Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep - sudowork
http://eng.datafox.com/javascript/2017/07/18/decaffeinating-large-coffeescript-codebase/
======
Dirlewanger
It's pretty wild having seen CoffeeScript spread like a wildfire in the early
2010s, only to be discarded nearly as fast a couple years later.

~~~
s_kilk
Same, the JS cool-kids swore up-and-down that CoffeeScript was the future and
we'd be fools to not jump on.

It's another reminder that no-one knows the future.

~~~
treehau5
CoffeeScript always felt forced onto me during the height of 37Signal's
influence of software development trends at the time. At the only rails shop I
ever worked at it was heavily resisted.

It was at the same time I was reading more and more of Resig blogs and books
(Secrets of the JavaScript ninja) and I really began to learn and grok just
plain normal JavaScript. I said to myself, "you know, this really isn't that
bad"

Haven't looked back since. I hate the direction ES is going.

~~~
mercer
What do you dislike about ES' direction? The increase in language features in
general, or more specific things?

~~~
treehau5
Increase in features yes and the continual succumbing to developers who just
can't seem to think outside the strict OO paradigm.

Prototypical inheritance is really not that hard to understand.

I would rather see JavaScript fix the existing functionality, such as
sometimes the prototype chain not being correctly established when
instantiating a new object.

------
smilekzs
Plain vanilla JS (and therefore TypeScript) still lacks one killer feature
from the Coffee family: Null propagation operators (`a ? b` => `a != null ? a
: b`, `a?.x` => `a == null ? null : a.x`, etc). Even C# has it.

~~~
sudowork
I agree, it's one of the features we'll miss.

There is a Stage 1 Null Propagation proposal:
[https://github.com/tc39/proposal-optional-
chaining](https://github.com/tc39/proposal-optional-chaining)

~~~
evan_
There's a babel transform for this in case you want to start using it now,
before browsers support it:

[https://github.com/babel/babel/tree/7.0/packages/babel-
plugi...](https://github.com/babel/babel/tree/7.0/packages/babel-plugin-
transform-optional-chaining)

~~~
smilekzs
I want to use TypeScript too, which will probably not adopt it until
standardization.

~~~
DanRosenwasser
We definitely want to implement it! But many parts of that specification are
still in flux, so like you said, we'd like to see the proposal stabilize first
to avoid problems.

------
matthewmacleod
CoffeeScript was great, and I'm pleased how relatively easy it's been to move
away from it now that ES6 offers most of the same benefits.

I've recently started moving our existing CoffeeScript + React codebase – it's
been okay, though I still miss the terse CoffeeScript syntax. A similar blog
post that's helped is Bugsnag's: [https://blog.bugsnag.com/converting-a-large-
react-codebase-f...](https://blog.bugsnag.com/converting-a-large-react-
codebase-from-coffeescript-to-es6/)

~~~
meowface
If you miss the syntax, why not wait out for CoffeeScript 2? They're going to
add all of the ES6 features, to my understanding.

~~~
matthewmacleod
There are a few reasons we made the switch:

\- Familiarity. Most of our team have a little experience with Javascript, but
none at all with CoffeeScript. It's not that different, but there's still a
cognitive overhead.

\- Documentation. Almost all documentation for front-end work, especially with
React, is in ES6 now. There's an additional overhead in translating it.

\- React – CJSX was IMO awesome, but there's no ongoing support for it.
Embedding JSX in CoffeeScript is less satisfactory.

\- Webpack. We've had various problems getting features of Webpack 2 to work
correctly with pre-2.x CoffeeScript – HMR etc. that only really work with ES6
modules. We could wait for CoffeeScript 2, but it's already becoming a drag on
velocity.

In short, CoffeeScript was great, but the benefits are much more marginal now.
My preference for terse syntax isn't that high a priority for the rest of my
team, so I'm happy to take advantage of the more standard ES6 that we can now
use.

~~~
mambodog
Actually if you still really want JSX in CoffeeScript, it's now built in:
[https://github.com/jashkenas/coffeescript/pull/4551](https://github.com/jashkenas/coffeescript/pull/4551)

------
luketheobscure
This article is missing one important thing: CoffeeScript now supports native
import and export statements, but decaffeinate doesn't. I recently migrated
several large codebases and had to escape all the import and export statements
(which wasn't very hard), but it got a little hairy where we were directly
exporting instead of assigning it to a variable first.

I'm going to miss CoffeeScript, but being able to use ES7 features (notably
async/await) is worth it.

~~~
sudowork
When we performed our conversion, decaffeinate@2 did support ES2015
import/export - it was actually the default which could be disabled using
(`--keep-commonjs`).

With decaffeinate@3, you can convert using ES2015 module syntax with the
`--use-js-modules` flag.

Although we don't plan on using CoffeeScript for the reasons outlined in the
article, I do want to mention CoffeeScript 2 does aim to target ES.next
features and offer interoperability. Specifically, CoffeeScript 2 does support
async/await [http://coffeescript.org/v2/#async-
functions](http://coffeescript.org/v2/#async-functions).

------
orta
Thanks, this is something I've been thinking about for a while.

~~~
sudowork
No problem! Hope it comes in handy :).

------
expertentipp
Hopefully the fate of TypeScript will be the same. If one wants Java in the
browser, one can just create Java applets.

~~~
chadrs
I can't tell if you're joking; applets are being officially deprecated in Java
9 and browsers disable them by default now.

