Converting a large React Codebase from Coffeescript to ES6 | Hacker News Reader

Converting a large React Codebase from Coffeescript to ES6

blog.bugsnag.com

42 pointsconversar15 comments

> The javascript language has advanced considerably. Not only has it adopted many of the syntax sugar features such as classes and fat arrow function, it has gone beyond coffeescript with features such as async/await and object spread properties.

Just like CoffeeScript's good parts got into JavaScript, JavaScript's new features are being merged into CoffeeScript. 'async/await' becomes just an elegant 'await' in CS and pure generators are just functions that yield, without special annotations (i.e function*()).

CoffeeScript is nearing its 2.0 release [1]. So the language is not "dead", and there is still room for "innovation" repeating the cycle anew.

1. https://github.com/coffeescript6/discuss/issues/71

Since python has had generators that "are just functions that yield, without special annotations" like, forever, I was surprised when vanilla JS decided generators need more punctuation.

They had to, since changes cannot break backwards compatibility with the legacy web.

That seems plausible, but what would "yield" have meant before?

It might have been a function or variable name. In finance and farming domains it's a somewhat likely function/variable name.

You just made my heart happy. I've been hoping for an updated and backwards compatible coffeescript update for a while. Glad to see it is coming along.

Coffeescript 2 has some breaking changes, most notably classes since it is moving to ES6 classes instead of its own implementation.

I'm with you though, I much prefer Coffeescript syntax over Javascript so I'm really happy to see it coming along.

This is a very valuable article about what it would take to do such a migration. I also work on a large CoffeeScript + React codebase (https://github.com/sagemathinc/smc), write a lot of new CoffeeScript every day, and I have no plans to do a rewrite. I just don't see the value of doing a rewrite, given how hard it would be. I like CoffeeScript, find it expressive, and I think it would be easier to fix or maintain the relevant CoffeeScript tooling than to do a rewrite (just because a rewrite would be so damned difficult). Also, CoffeeScript really is sufficiently close to Javascript, and it interoperates effectively enough for now.

CoffeeScript is not totally dead. There's pretty regular activity this month (see https://github.com/jashkenas/coffeescript/commits/master). That said, personally, I find the stability of CoffeeScript to be kind of nice, considering how much churn there is in the rest of the Javascript world. The language barely changes at all, and that's kind of nice.

I believe articles like this should get more attention. There is a lot of hype about new technologies around JavaScript, but also there are many successful brownfield projects still actively developed. They may benefit from the new technologies, but rewrite is rarely a good idea, and there are not much info on migration process (speaking from personal experience).

"According to The State of Javascript survey, only 6% of responders that have used coffeescript before said that they would consider using it again."

Nit: the calculation seems wrong to me.

- Used it before, would use again: 6%

- Used it before, would not use again: 25%

- Therefore, "responders that have used coffeescript before said that they would consider using it again" shall be: 6% / (6% + 25%) = 19.4%

That chart was kind of weird itself, though. Can we really believe that more people have heard of CoffeeScript than "Plain JavaScript"?

We did exactly the same a year or two ago with my last startup. Just did it component by component with a general rule along the lines of "if you have to edit it, convert it to JS". The project was moving so fast that components would often become obsolete within a year anyway. Plus they were all very small so converting manually was trivial.

Here you go op https://www.npmjs.com/package/babel-plugin-null-safe-accesso...

That's deprecated :(

Related: invig.io

Reply on news.ycombinator.com