I'm not sure if getting some extra syntactic sugar is worth adopting a whole other language into a codebase: at least, that seemed to be one of the lessons from CoffeeScript.
Back when there was no async/await and no promises, passing callbacks like this was extremely tedious, and node.js had a lot. CoffeeScript was worth using for the fat arrows alone.
CoffeeScript didn't die. JavaScript (ES3/5) died and we are all using CoffeeScript now!
As someone who used to be a big CoffeeScript advocate, I agree that adopting CoffeeScript over modern JavaScript isn't worth it. However adopting CoffeeScript when it came out over what JavaScript looked like at the time was a much bigger win.
That being said, as much as I liked using CoffeeScript in my own personal projects, adopting it for a non-trivial project at work probably turned out to be a net mistake all things considered. The only positive was that the .js output files where clean any easy enough to work with that we could quite easily just drop CoffeeScript and continue developing directly with those .js file
Eh, as long as the team is on board, and the sugar is simple enough and maps well to the underlying language without a ton of extra code, then I have no issues with it.
If it ever becomes a liability, you just check in the "transformed" code and it's gone.
You check in the transformed code and it’s gone, except for the Ghost of Syntactic Sugar which will haunt your codebase forever and make the juniors wonder why all the code is so awful.
> If it ever becomes a liability, you just check in the "transformed" code and it's gone.
I've done this and regretted it - CS transpires to ES3 and specifically null chaining is completely unreadable.
From a backend perspective it's no biggie to instead keep the CS dependency and gradually convert files manually when you have to make changes anyway, or when you have 15 minutes to spare between meetings.
You become fluent enough to not even need tests after a while (yikes!).
