I think we'll ask the same question about Typescript in the future; I've integrated into a UI project I work with other people, to make one of our devs happy, but I won't use it myself.
A few years ago I remember having one colleague who wanted to write in CoffeeScript but at that time we didn't know how to interoperate with JS, I believe? Or our tooling or knowledge wasn't the best, so we decided not to let him write CoffeeScript; From time to time I hear from that team and the project is still alive - luckily they don't have to support CoffeeScript.
I think you should use whatever makes you happy, for your own projects, but in a team, have in mind others and the future.
Typescript gives real benefits with type checking vs CoffeeScript which just looks sort of like Ruby. It’s hard for me to imagine why someone would prefer endless “Cannot read property foo of undefined” runtime errors in normal Javascript over Typescript’s in-line linting of those errors.
A lot of its ideas got folded into subsequent versions of ECMAscript, so in a way everyone uses it now. But for the actual "language" and runtime, it seemed from the start to have a built in expiry date, so I tried to avoid it as much as possible, mostly successfully.
Ultimately, if you want tomorrow's language features today, Babel feels like a better approach. You can choose your level of "buy-in" and then one day, certain things "just work" because they've been built into the runtime, and your code stays the same. Or at least, that's the hope. Making a new sub-language to get a handful of cool features/syntax involves a lot of pain for not enough gain, IMO.
As a longtime Coffeescript hater I'm happy to say I haven't seen it in many years in the wild. That said there are certainly many new sugary compile-to-JS languages (besides Typescript and Flow), but I don't anything comes close in notoriety.
5 comments
[ 1.5 ms ] story [ 21.0 ms ] threadI think we'll ask the same question about Typescript in the future; I've integrated into a UI project I work with other people, to make one of our devs happy, but I won't use it myself. A few years ago I remember having one colleague who wanted to write in CoffeeScript but at that time we didn't know how to interoperate with JS, I believe? Or our tooling or knowledge wasn't the best, so we decided not to let him write CoffeeScript; From time to time I hear from that team and the project is still alive - luckily they don't have to support CoffeeScript.
I think you should use whatever makes you happy, for your own projects, but in a team, have in mind others and the future.
Ultimately, if you want tomorrow's language features today, Babel feels like a better approach. You can choose your level of "buy-in" and then one day, certain things "just work" because they've been built into the runtime, and your code stays the same. Or at least, that's the hope. Making a new sub-language to get a handful of cool features/syntax involves a lot of pain for not enough gain, IMO.