Live data from Hacker News

Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

eng.datafox.com

21–30 of 47 posts

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#21

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…

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.

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

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

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#23
post #20
post #4

Earlier quoted context omitted.

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.

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#24

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.

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#25
post #3

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.

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

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#26
post #20
post #4

Earlier quoted context omitted.

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

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

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#27
post #3

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.

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.

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#28
post #25
post #3

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.

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

> kind of works

!== works

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#29
post #20
post #4

Earlier quoted context omitted.

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

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

Re: Decaffeinating a Large CoffeeScript Codebase Without Losing Sleep

#30

Earlier quoted context omitted.

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.

Post reply on HN