Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep | Hacker News Reader

Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

eng.datafox.com

42 pointssudowork46 comments

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.

It validates my policy of not jumping on every new thing.

I loose "nerd cred" for it, but it's better for my clients that way.

The only bandwagon I've ever witnessed explicitly was this "I'll lose nerd points for being so anti establishment" thing, that's been going around forever.

I loose "nerd cred" for it. Please. Give me a break. Half the people here will fall over themselves agreeing with you and you know it. Heck, I agree with you.

Can we please, as a community, get over ourselves? Can we get over this "ermegerd I'm not gonna use the latest JS framework! Guess that makes me 'not cool'! Haha I'm so level headed teehee guiltyyy!" We get it! Most people, the silent majority, don't use new things. We know! We are them. It's ok. Stop. dont humblebrag about how productive you are on Procrastination News.

I've never been on Tumblr but I imagine this is what some of it is like.

Sorry for singling you out. It's just a bugbear, is all. You're probably a solid guy / girl and I do believe you deliver great value for your clients. Honestly.

I've been criticized (by other programmers!) for not going for the latest and newest stuff, so I'm a bit sensitive and glad to have some confirmation that I'm right.

I'm not trying to brag (didn't even realize it could be read that way), I'm trying to validate both myself and other people like me.

I would guess that nerd cred is not the reason for most people.

It's about competitive advantage. Some people just want an edge over other people in their career. Some don't want to miss the "next best thing". Some people just want to be stay relevant and be employed.

dont humblebrag about how productive you are on Procrastination News.

Haha that should be written across the header on the main page.

Yes, I had the feeling this had to do with the rise of Nodejs. Back in 2010 I was mostly a PHP dev and some Nodejs devs told me how cool and better it is and that there is CoffeeScript, which is also much better than JavaScript and PHP combined.

I also started a JS project in 2015 were the lead dev started 3 months before me with... CS! But he rewrote most of it in ES2015.

Wait, why were node devs talking about Coffeescript? Weird.

You can write CoffeeScript to target Node...

The question is, why?

Realistically, everybody who uses Coffeescript is/was a Rails developer at some point since the syntax is very opinionated towards rubyists.

The typical Node dev is more likely to use ES6/7 which fixes a lot of the same js issues as Coffeescript.

what a facile interpretation. CoffeeScript offered a large number of meaningful improvements over ES5, not including superficial syntax differences. It _still_ offers truly meaningful niceties that can make code _better_ than the JavaScript equivalent.

As far as I can tell, much of the ES6 changes came from people who were using CoffeeScript before.

I'd say you could see this coming as soon as it emerged. People didn't want to learn yucky JavaScript syntax, then they learned it anyway because that's always how this happens, and now here we are.

Whole technologies have been invented simply so that devs can avoid learning or touching JS. Once upon a time, I was one of them.

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.

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.

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

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.

Mmm, from my view it was driven more by Rubyists who disliked that JS was much uglier than their chosen language. JS devs just write JS, because they know it already.

It was the future… so many CoffeeScript niceties (spread operators, destructured assignment, class syntax, ARROW FUNCTIONS) were subsequently mainlined into ES6.

I can relate. I wrote an essay on this a while back:

https://www.nemil.com/musings/shinyandnew.html

Excerpt: Pity the modern web or mobile app developer on Hacker News. As a full stack startup developer in 2012, you were building websites using Ruby/Rails on the backend, Backbone/Coffeescript/Underscore on the frontend, while deploying your app with Capistrano (or the relevant Python analog). By 2013, you'd transitioned to Node/Express/Mongo on the backend, Grunt/Ember on the frontend. In 2014, you'd switched whole hog over to the MEAN stack (now with promises), but experimented with Koa and considered a shift to Go (after the Express core contributor made the jump).

In 2015, you're using Gulp/ES2015/React on the front end, Express/Go on the backend, React Native over the native mobile languages, and slowly transitioning your system over to microservices with Docker. Soon, you'll be transitioning to Phoenix, figuring out if Angular 2 is the right choice - and maybe even plotting a world where Go can work on Android and where an open sourced Swift might fit into your stack. (I’m clearly exaggerating for effect, though this is a fair representation of what is popular in HN headlines)

One minor upside to the rapid change is that I can sit out an entire stack and hop back into relevancy with some totally new stack a year later.

I'm not sure HN headlines - even ones like "we rewrote our codebase with X" - indicate that people are actually rotating libraries quickly. Rather, they indicate our quickly-shifting curiosity, and cherry-pick instances of people actually acting on it because they're interesting. Tellingly, the "rewrite" blog posts usually are coming not from the fad preceding the current, but something much older.

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.

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

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

Thanks for the tip! Given some of the lessons we've learned with CoffeeScript, we'll most likely wait until proposals hit at minimum stage 3 before adopting them.

I've been waiting for this for years. Even considered forking Babel... it's been a long time coming :)

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

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.

Given null is generally non-idiomatic in JS (it's there, but most best practices say to avoid it) I think that's likely by design.

However the `a?.b` form is coming (it's not just null propagation, it's an Existence Operator). It's called "optional chaining"

https://github.com/tc39/proposal-optional-chaining

> I think that's likely by desig

Fine.

s/null/undefined

The problem still exists.

I think calling it a problem is a bit melodramatic.

A cleaner syntax is nice for sure, but it’s not exactly unworkable as is (and promotes flatter data, generally a good thing).

But yes, it’ll be nice if/when the new syntax drops.

The first one kind of works with `a || b`. Returns b if a is falsey (null, undefined, 0, "").

> kind of works

!== works

The other killer feature that is still missing is multi-line regex with inline comments. I know, you shouldn't be writing big regexes if possible… but when you need to, it's so nice to be able to actually explain what the heck you are doing!

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

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.

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.

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

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.

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.

CoffeeScript 2.0beta has async/await and it works great.

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

No problem! Hope it comes in handy :).

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

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

Reply on news.ycombinator.com