This is an interesting article. However, it makes one important error.
It compares the cost of hand translation with the cost of auto translation, but fails to account for any time developing the translation tool, as it was done "in my own time". Clearly not a valid comparison.
The author has also done lots of free ot-of-hours work for his company which he doesn't seem to realise.
In quite a few companies this would also cause problems with IP ownership, particularly due to alignment between in-work and outside-work work.
CoffeeScript is a match in the heaven with JSX IMO. You for example no longer have to face the bracket and semicolon hell. (Unless you have StandardJS or ESLint, which is pretty much default for all devs)
There’s also implicit return, so the code pattern is prettier, no more return (<JSX />)-ish thingy, and it feels closer to a template, but it is a boon and a bane at a same time since some devs got used to return like that.
Before CS2, we have to stick with coffee-react-transform, which is hacky and unmaintained and old. It transpile JSX to createElement directly, not good.
With CS2, you can write JSX expressions directly. A large subset of JSX is parsed, and only bracket/property expression will be transformed by the compiler, then processed with Babel. This is safer, more spec-conforming, and I could do some tricks like babel-preset-react-optimised.
CSX gets even better if you have MobX! It feels like PHP+Rails all the way while you’re also enjoying the MVVM ride. I'm already loving it and using it in my production heavily.
CoffeeScript is great, man. It is influential to ES6. Don't give up on CS yet. The ecosystem, however, is already shifted to JS. It took years to revive CS I guess.
I love the idea of using other open source projects and their test suites to test the tool. It feels like this approach could be useful for other projects as well. For example, what if you could test changes in your library by running the test suite of a couple of projects that depend on it?
The JS tools/libs ecosystem really reminds me of crypto currencies. There's a million of them to choose from and if you jump on one during the height of its popularity you just end up losing a bunch in the crash that inevitably follows the pump. Should have just stuck with plan JS / those 50 bitcoins you had back in 2012...
I found CoffeeScript to be a pain to work with.
CoffeeScript added some useful features, like destructuring assignments, and some syntax sugar for objects, loops, etc... but it also made some choices that in my opinion are bad:
- Making delimiters optional like parentheses, brackets, semicolons... in addition to implicit return statements: makes programs hard to read if abused. Makes code formatters get confused and corrupt your code.
- Not being able to distinguish an assignment from a variable definition: causes identifier typos to become new variables.
This implicitness makes programs error prone in ways that are hard to verify and work with. Plus, needs to be transpiled and you will need sourcemaps.
In the end, the benefits are not worth it, even back during the time it was created.
When I had to convert a CoffeeScript project to plain JS, I basically took the output from the coffeescript compiler, formatted it using prettify/standard and fixed up any obviously stupid things that the coffeescript compiler does by hand. Took only a few days, but it wasn't a large project either.
I guess the main reason to migrate off CoffeeScript is that popular JS tools like for example Serverless Framework do not maintain their CoffeeScript plugins.
I have about 30 old AWS lambdas written in CoffeeScript, which I tried to convert to serverless framework. I tried two serverless-webpack-coffeescript plugins and none of them works. Fixing them requires to know both serverless framework and webpack internals and their plugin APIs are constantly evolving without regard to backward compatibility.
It was much easier to either add a script that runs transpiling before running "serverless deploy" or just to port the source code to JS.
Decaffeinate make this even easier by porting to JS6.
Other types of businesses choose to maintain large chunks of code in a "legacy language" and paying people to maintain it overtime, at a cost (e.g., banks and COBOL).
Let's say there's a COBOL -> C/C++/Rust/someotherfancylang transpiler. Maybe there is one, maybe not. Would it make sense for a bank to invest in something like that, or is there really no incentive to do so? Why would there be an incentive for a startup to do so, but not for a bank?
There are many transpiled languages working on-top of js. As many things in JS world, they tend to end up as an abandonware.
This all make long-term mainainability of large JS + "featurelang" projects hard.
The liveliest JS add-on lang today is typescript, but even it gets seen less and less, despite Microsoft's backing.
It had initial burst of interest, but seem to be waning now.
My insistence on no featurelangs in my projects has paid off massively whenever I took post-delivery maintenance and support contracts.
I think it is quite funny how a tool to turn proper code into the mess that is ESxx can become so popular. I'm still using Coffeescript 2, it's awesome :)
Cool stuff, shows the importance of having a solid set of tests for your code.