I’ve been looking through the source of some Atmosphere packages in Github lately and I didn’t realize how many of them were written in Coffeescript.
So I was wondering is it Meteor tradition of sorts to use Coffeescript? is learning Coffeescript something of a Meteor rite of passage? is that something we want to keep going in the face of Typescript’s growing popularity? I personally like when how different communities have their own idiosyncrasies and traditions, so I guess I was just interested in seeing what other people thought.
Rails ships with CoffeeScript by default, and so the rest of the examples in this guide will be in CoffeeScript. All of these lessons, of course, apply to vanilla JavaScript as well.
Meteor goes way back to the times when Babel was called 6to5, and beyond. Coffeescript was popular, because it was a nicer way to code JavaScript, at the time. Times have changed!
I doubt many Meteor developers today would start their projects with Coffeescript. Instead, probably TypeScript.
That’s kind of what i was wondering, like is there a sentimental attachment to Coffeescript among the Meteor community or have times changed and its Typescript that now fills the role that Coffeescript once did
I found a 10 dollar copy of Coffeescript in Action https://www.amazon.com/CoffeeScript-Action-Patrick-Lee/dp/1617290629 (a good book btw, even if you dont want to learn Coffeescript it just broadens your perspective) and after reading through it I can start to see the appeal of Coffeesccript to Ruby and Python developers. It kind of bridges the gap from Javascript to Ruby/Python,making Javascript more like Ruby/Python. Alot like how Typescript makes JavaScript more like C# for ASP.Net developers. I just thought I’d share that and see what people thought about that comment.
CoffeeScript and TypeScript are different tools. CoffeeScript (CS) adds some syntax sugar to JavaScript (JS) resulting in a lot less code remaing the type freedom of JS. TypeScript (TS) gives you a clear contract at the expense of wrting more code.
For a small team that looking for quick results I would use CS. When I have an external API, developers of different organizations working on the same app or the app is really big (dozens of developes) I would consider TypeScript.
If in doubt JS is a good alternative.
For the Meteor platform it makes a lot of sense to be rewritten in TS while for 9 out of 10 Meteor apps I would prefer CS or JS.
I would strongly advice against using CoffeeScript, even if you are a small team or alone (altough its a neat language). The amount of code with typescript is not much bigger these days. And you will spend most time pondering about code anyway and not typing code.
coffeescript is also not always more readable, it tends to be also good in hiding some nasty errors.
Also in small teams, if you get new teammembers, you will be glad if you use some more widespread technologies.
Many platforms will also support typescript out-of-the-box in the future.
I guess i like Coffeescript as like a fun language to play around with. Like Haskell and Ocaml.
But Typescript is a real improvement to the JavaScript language because static type checking is just a nice thing to have (much like in Haskell and Ocaml haha).
So how all this got started is because the Atmosphere package i forked and would like to update and publish is written in CS so i was like … should I keep it in CS cause its already written that way or port it over to JS, or maybe even write in TS. So then I found that book on Coffeescript and started to dig around the code and I guess I am still debating what direction I’ll go in, but its a fun discussion to have. so thanks everyone who posted a reply
There’s no CS in any Meteor (MDG) code and given Ben’s pre-Tiny statement of intent to refactor to TS, I’d say that if you’re forking solely for yourself, you should adopt the language most expedient to get your changes working. OTOH, if you intend offering the package to the community (which I think is what you’re saying), you should seriously consider refactoring to TS.
As @macrozone says, CS is not really a good choice these days. As you’ll be aware, many of CS’s advantages over the JS of 4 or 5 years ago have been adopted by modern JS (albeit not always with the brevity of CS), and there are cases where CS makes debugging much harder.
JS is a proper subset of TS, so the refactor may be a case of CS -> JS (automated) -> TS (incremental refactor). The tooling around JS and TS is really good and should be a primary concern in any refactoring.
