18 ms·

The Great CoffeeScript to Typescript Migration of 2017

307 points by dgoldstein0 6y ago

nosefrog 6y ago
I worked on this project, it was super fun. Open to answering any questions.
- faitswulff 6y ago
  What was fun about it?
  - nosefrog 6y ago
    I personally think compiler tech is really interesting, and 90% of the project was writing transformations on ASTs. There's something about working in such an exacting environment where bugs are especially bad because they often manifest in subtle and hard to catch ways that's exhilarating. :)
- city41 6y ago
  I’m curious why not allow implicit anys instead of creating the tool that inserted anys? Seems roughly the same outcome but implicit anys would take a lot less work?
  - dgoldstein0 6y ago
    Because of the way we had type checking set up - our existing code already used noImplicitAny, and we wanted to keep that, and we were typechecking it all in one shot, together, so we couldn't have different typescript flags for different files. Now as to why to use noImplicitAny in the first place: mainly because implicit anys are usually accidents - places where developers didn't realize they should put a type. And the explicit `any` in many ways is sitting there for anyone who cares to replace it with something better; whereas implicit anys are much harder to notice.
- Xt-6 6y ago
  Any chance some of the codemon used could be shared?
CapriciousCptl 6y ago
I fully remember picking up coffeescript because Dropbox had used it. I only ever used it on one project. I try and remember that every time I have the urge to go with Reason, Elm or even wasm compiling things. Long live JS.
- melling 6y ago
  Does any alternative have any traction? ReasonML is used by Facebook. Elm used to get more attention on HN.
  - wbc 6y ago
    Reason looks pretty cool but I'm weary given the outcome of flow
    - rashkov 6y ago
      Reasonml claims, as an explicit goal, to output very readable and modern JavaScript, so it shouldn’t be such a risk. That task is a work in progress, but even looking at the latest recent release you can see that it’s coming along nicely.
- city41 6y ago
  Since wasm has native browser support it doesn’t really feels like it fits into this group. I have a feeling in a few years wasm will be pretty common.
  - julianeon 6y ago
    Yeah, wasm is offering something those others aren't. You could say that Coffeescript to Typescript is a lateral move. Try as you might, you can't do the things wasm is best for - say, graphics - in Coffeescript.
- Roboprog 6y ago
  If you are trying to build for a business, or something you yourself will have to maintain for years to come, vanilla JS seems like the way to go. Perhaps Typescript isn’t a fad to be abandoned, unlike say GWT, CoffeeScript, et al, but why risk it? Javascript doesn’t feel painful to me like Java does. I don’t have a lot of problems with it that need solving with an alternate front end. Long live JS!
dgoldstein0 6y ago
Author here, also willing to answer questions
- pansa2 6y ago
  “Lack of delimiters“ is given as the most common complaint about CoffeeScript. I’ve never written any CoffeeScript - Is this referring to the language’s Python-like significant indentation, or something else?
  - dgoldstein0 6y ago
    something else. More that `()`, `[]`, `{}`, and `,` in a lot of places in the language syntax were optional. And we embraced that... way too much. E.g. foo: 1 bar: 2 is the same as { foo: 1, bar: 2, } for basically no good reason. When you start combining a lot of these, whitespace takes extra significance, and in extreme cases can easily change what you think the meaning of your code is, and what it actually is.
- molszanski 6y ago
  Thank you for the article! Very interesting!
- Xt-6 6y ago
  Thank you for sharing! Any chance you could share some of the codemods used?
bambataa 6y ago
As someone who came into development after the Coffeescript wave I’m interested to know: how much did it feel like the future? Was it always an early adopter, “look how forward we are” kind of thing, or was it just popular with Rubyists? I’m trying to calibrate it with other possibly-next-big-thing front end languages.
- wahnfrieden 6y ago
  Personally speaking from what I saw around the internet and my own experiences with peers using it, it was contentious whether it was so forward-thinking or sufficiently differentiated to make it worth it.
  - bartread 6y ago
    Back in 2013/14 I remember on a couple of occasions being quite annoyed when I found npm packages that I wanted to bugfix were written in Coffeescript rather than plain old JS. It always seemed so unnecessary, and tended to push me towards alternative solutions.
- chipotle_coyote 6y ago
  I think CoffeeScript was definitely popular outside the Ruby community, too, for a while. (After all, Dropbox was/is a Python shop, not Ruby!) Speaking strictly for myself, while I liked a lot of what CoffeeScript was trying to do, I didn't love the "one layer removed" feel of writing in a language that wasn't the one actually being executed. Also, I often found CoffeeScript to be cryptic in ways that vanilla JS, for all its quirks, really wasn't. So I think it felt like the future for a couple years, until JavaScript ES6 took off and it started feeling kind of superfluous -- ES6 felt like it was taking the good parts of CoffeeScript while leaving a lot of the quirks behind.
- dgoldstein0 6y ago
  It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a few years. I think the main thing to note is that we were supporting IE7+ when we adopted coffeescript. So we couldn't even write standard ES5 - ES3 would have been the lowest common denominator supported. So having classes, optional chaining, array comprehensions, for-in loops that actually looped over items in an array (like ES6 for-of) - all those features were super useful. And you didn't need to worry about function declaration hoisting (or any confusion it could cause) because coffeescript only compiled to function expressions, which got bound to variables. Unfortunately, coffeescript came with some others like implicit returns and tons of optional syntax that we didn't realize was problematic until far too late. And being a python-based org, having a frontend language that looked similar (space-delimited, a lot of similar features e.g. array comprehensions were like list comprehensions, ternaries that looked more readable) seemed like features. But some of these features bit us hard at times, because they didn't work like python - the worst, in my opinion, was that `is not` and `isnt` looked the same but meant very different things in coffeescript. `is not` meaning `=== !` and isnt meant `!==`. But given the alternative was writing prototypical-inheritance by hand, and dealing with various IE7isms directly? It was a sensible tradeoff at the time.
jtth 6y ago
This makes me miss CoffeeScript. Ah, well.
- city41 6y ago
  Only thing I still miss is noop functions are two characters. Everything else I liked is in JS now that nullish coalescing landed.
  - recursive 6y ago
    `_=>_` is technically more than two, but not by much.
    - hombre_fatal 6y ago
      Identity function is more confusing than just ()=>{} which is obviously noop because it doesn't return the input.
      - recursive 6y ago
        If you don't provide an argument, it will use undefined, which is the same thing yours returns. Maybe it's more clear, but it's about even for me.
eecc 6y ago
I wonder what happened with the devs that started the tumble towards the Coffeescript migration... still locked in the cellar?
- szhu 6y ago
  I don't think the CoffeeScript advocates did anything wrong at all. CoffeeScript was a popular solution with a healthy ecosystem, no one knew when JS was going to get these features, and TypeScript was still an emerging player (just like other typed JS variants like Flow). Also, when I wrote in CoffeeScript, (1) I loved the JavaScript ecosystem more, (2) I understood the code I wrote better and built and learned more quickly, and (3) I understood the nuances of an JS-extension language, which helped me quickly understand what TypeScript was when I heard of it. I'd assume that other developers got some of these benefits as well, and these benefits may have been well worth the cost of converting from CoffeeScript later.
Jare 6y ago
> it was absurd to expect anyone to want this as their full time job for even a month or two That gave me a true 'kids these days' moment... In my day within a spanish bank, as a team of 4 interns, we spent over 6 months reviewing/documenting an entire proprietary platform C codebase (full of gotos, endian-dependent hacks, post-compile patches and every horrible thing you could imagine), and then with a larger (~3x) team about 12 months cleaning, porting and expanding that codebase to a clean platform (if you can call SCO Unix 'clean'). What sort of dynamics prevent a product startup like Dropbox build an engineering team that includes the capability to do such a task?
- bcrosby95 6y ago
  Because startups tend to use how much you enjoy coding as a proxy for how good of a coder you are. So if you purposefully hire a bunch of people because they like coding, it's going to cause a shitload of problems once you unleash an "unfun" job like this on them for such a long period of time.
  - whynotminot 6y ago
    Wait what? So you should hire coders who don't like coding to do coding?
    - nojito 6y ago
      People who "like" coding tend to prefer hot new tech as a way of experimentation. They often ignore the actual business problem that needs to be solved, because it can be solved using "boring" technology.
      - koz_ 6y ago
        The thing is boring tech is often really just painful tech, where pain manifests in lots of different ways (error-prone repetition, painful manual testing, hard to read spaghetti code, etc). Programmers who are too insensitive to pain will continue to generate pain for themselves and others.
blitmap 6y ago
I truly do not understand why so many jumped from Coffeescript. I still use it and still believe I can be more concise and expressive in Coffeescript. Typescript and ES2015 picked up a lot of wonderful things, but I find myself writing a lot less boilerplate in Coffeescript. I will continue to "do me". I dev in Coffeescript and publish in JS. The project even made it a focus to transpile to readable/friendly JS. No biggie. I would not publish things like this, though :) console.log [ i if i % 3 and i % 5, 'fizz' unless i % 3, 'buzz' unless i % 5 ].join '' for i in [ 1 .. 100 ] Separately, I bought overpriced raspberry pi's instead of cheaper alternatives because I knew the community was a strong source of support. Modern JS has a much larger community than Coffeescript 2.
- dgoldstein0 6y ago
  I recall when we first adopted Coffeescript, the engineers who did it touted that we had about 20% fewer lines of code as an example of coffeescript being better - a lot of which was probably just the removal of lines that only had curly-braces. In hindsight, this wasn't a good metric to judge the language on. As a larger engineering organization, what we've definitely learned over time is that we need to prioritize readability (and maintainability) over writability - as our code is going to last a long time and the original engineer who wrote it, will likely move on to another project, team, or even company. And while maybe they train their replacement, after a second or third iteration of that, the knowledge can easily end up lost. Coffeescript, as a language, definitely prioritizes terseness, often at the expense of readability. And we didn't have internal coding standards that pushed back on this. But even if we had done a better job using coffeescript, we're still better off in typescript today, due to the stronger community and stronger set of available open source tools to work with the language.
  - blitmap 6y ago
    I think it does depend on how familiar the syntax feels to each individual. To me Coffeescript is the right balance. I absolutely love writing Literate Coffeescript. I am _not_ a fan of strictly typed languages but I do hope Coffeescript finds a friendly syntax for gradual typing like TS in the future. I usually prototype in a 'ducky' way and then lock down type expectations when I'm polishing.
29athrowaway 6y ago
Coffeescript tried to simplify the syntax, but it went too far. - A statement such as f(g(x)) becomes absurd without parentheses. - Indentation has a meaning, but it is legal to have inconsistent indentation. Code is written once, read many times. Coffeescript got that backwards. CoffeeScript is to JavaScript what Stenography is to Writing. Steno makes sense when you have to write something being dictated to you in real-time, but if you are not in a hurry, just write.
- dgoldstein0 6y ago
  precisely. Though some of their constructs, like classes and for-in loops - are great for reading and writing.
  - 29athrowaway 6y ago
    Coffeescript does have useful features, but problems such as the ones I described made CoffeeScript code inconvenient to maintain in practice. If we weigh the convenient aspects of CoffeeScript against the inconvenient aspects, in the end, CoffeeScript can be an inconvenient language to use. It was the case at least for me in various projects I had to maintain. Part of the inconvenience was all the JavaScript tooling you cannot use, and occassionally being forced to read JavaScript code generated by CoffeeScript.
    - dgoldstein0 6y ago
      Yup, totally agree. In 2012 when we adopted Coffeescript, it was less cut and dry - all the open source tools we love now - prettier, eslint, etc. - didn't exist. So the tradeoff was less obvious then.
      - spiralx 6y ago
        I loved coding CoffeeScript on my own a few years ago. Today the thought of having to review PRs written in CoffeeScript by my junior developers is terrifying.
- 6y ago
k__ 6y ago
CoffeeScript? 2017? I had the impression that CS was done when ES2015 came out in ... Well 2015 I personally prefered LiveScript, should have been.
- bcrosby95 6y ago
  They started the project of looking for a replacement language in 2015. You can't instantly rewrite all the code.
  - k__ 6y ago
    -can't +shouldn't My co-worker of that time did exactly that one week before I got hired. Also, he told noone. I just saw it one time, when I played around with a tool that would visualize Git commits, years later. Thousands of lines of code. Absolute mad lad.
lewis1028282 6y ago
Is CoffeeScript all but dead? I use Ruby and Python a lot so the syntax of CoffeeScript looks great to me!
- rogem002 6y ago
  I do Rails full time and most the CoffeeScript lives in the "legacy" side projects. Most projects I'm on have moved to vanilla JavaScript or ES6 via Webpack. I don't think it's dead (it's still popping up), but I think it's time has passed.
- jessaustin 6y ago
  Lots of people use it (I use it for all my personal stuff) and it sees regular updates. [0] I think it coordinates well with modern client-side frameworks like Mithril (... and experts agree [1]). It has kept up with the new stuff in javascript, and it often does the new stuff better than JS. Example: in coffeescript you don't need the goofy function declaration flags that JS requires: "*" and "async". In coffeescript a generator is a function that yields and an async function is a function that awaits. This is clearly better. Obviously, Typescript is more appealing to management. It may not be obvious from this thread, but bragging about how old-n-busted coffeescript is compared to... whatever was a lot cooler a couple of years ago than it is now. Nowadays the cool kids complain about npm or rollup or something. [0] https://github.com/jashkenas/coffeescript/commits/master https://github.com/jashkenas/coffeescript/commits/master [1] https://mithril.js.org/signatures.html#splats https://mithril.js.org/signatures.html#splats
fourseventy 6y ago
I worry about the long term viability of using an offshoot language of Javascript such as Coffeescript or Typescript. These types of languages have a habit of falling out of vogue and basically becoming a dead language, which is exactly what happened to coffeescript. If a company decided to write an app in coffeescript in 2010, today they have a big pile of code written in a dead language on their hands. If instead the company had chosen a mainstream language with a guaranteed future such as JS, Java, or c# it wouldn't be an issue.
- ryanianian 6y ago
  Typescript is nice in that it's a superset (mostly) of js. That doesn't mean it won't fall out of vogue, just that in a lot of cases converting from TS to JS is mostly straightforward, so you can "just" remove some type information and end up with valid JS.
  - city41 6y ago
    You should be able to let tsc do it for you with a properly configured tsconfig file. Mostly just want it to not emit any polyfills.
- heipei 6y ago
  What do you mean by dead? It's still maintained and developed and still works great. Yeah, not many people are using it for new projects so if you're anxious about using something with the biggest "mindshare" then Coffeescript isn't for you, I give you that.
- int_19h 6y ago
  TypeScript is the best bet in that regard, because not only it's backed by a large software company, but that company also builds all of its web apps (and now also Electron desktop apps) using TS. The sheer amount of buy-in inside Microsoft is such that I'd expect it to be maintained for a very long time even if there were no external users at all. But then this reasonable expectation that it'll still be there 10 years from now is also what's driving external users to it, among other things. In fact, TypeScript is in PYPL top 10, and it's higher there than Go. It is a mainstream language now.
seemslegit 6y ago
Cofeescript will always be remembered as peak code hipsterdom.
thrower123 6y ago
The only people I ever knew personally who used CoffeeScript also used Rails. That was usually the combo then. The shine has kind of come off Rails, and the cool kids followed the shiny to the next thing, usually node, and so they moved to Typescript.
studentik 6y ago
CoffeeScript rocks for functional programming. Less chars and more sense per LoC, easier to learn than JavaScript and syntax sugar is sweet.
erichurkman 6y ago
My fond memory of CoffeeScript was an interview I did way back when at Olark. It was a full day 'paid work along' interview that was popular at the time. I'd never touched CoffeeScript prior. In less than the day, I was proficient enough even navigating a foreign code base to build out a small feature within the Olark platform. (I think it was managing chat operators as groups?) Fond memories!
freedomben 6y ago
CoffeeScript was an amazing companion to a Rails backend. While I did get bit a few times by unexpected CoffeeScript behavior (implicit returns and whitespace, ah!), it was substantially more beautiful and "developer happiness" than the options at the time (2014-ish). CoffeeScript will always have a warm place in my heart, tho I do use TypeScript as much as possible now.
ravenstine 6y ago
I stopped using CoffeeScript just because JavaScript fixed most of the issues that got me to use CoffeeScript back in 2014. Once ES2015+ became well supported, I decided I'd rather write code in the language that the interpreter understands, rather than something that precompiles. CoffeeScript isn't bad... it's just not significantly better than JavaScript is today. Also, I find it interesting how many people like the Python syntax but hate CoffeeScript syntax. They have a lot of similarities.
- eshyong 6y ago
  As someone who works with Python a lot, Coffeescript always looked more like Ruby to me, especially with all the syntactic sugar (lack of parens, keywords like `unless` or `isnt`, #{} for string interpolation, etc)
deanmkenzey 6y ago
You can easily test your Coffeescript code with a dynamic type checker and be perfectly type safe, even at runtime! Why for gods sake convert your code base to another language primarily for imaginary type safety? But for some strange reason entire armies of developers move to Microsoft's Typescript, living their imaginary type save dream. Moving from a language as Coffeecript to Typescript is like dropping at least 25% of your productivity. Not only you'll have to write more code, which in itself increases the chance for bugs, but you'll also be fighting countless compiler issues, installing numerous @types modules, having intellectual discussions about types and whatsoever to make it 'kind of work'. Oh, and almost none of the TS code bases I've seen are without the 'any' keyword, which is actually an instant breach of your type safe haven. IMAO 'any' should never pass a code review in a Typescript project if you want to stay true to your religion. With such a strict regime, like you are forced to with real strictly typed languages, would completely eliminate TS. Without 'any' it's practically impossible to write a large code base with it. I wrote numerous relatively bug free applications in Coffeescript, small and large as well. Just do good testing and you'll be fine, and as a bonus you'll have type safety at runtime! The mine field is not types IMAO, there is so much more to high quality code bases.
- matchbok 6y ago
  Using 'any' is perfectly fine, you just don't understand how most companies use TS.
  - deanmkenzey 6y ago
    Not using 'any' is also perfectly fine, as you can with Javascript, Python, Ruby, etc.. And I guess that most companies just don't understand how I use Coffeescript. Besides, I am not against others using Typescript, it's a fun experiment and a great opportunity for front-end developers to learn about static typing, enjoy it if you can! For me it unfortunately doesn't work, I've never gained from it because I generally don't have type issues. It's a pain in the ass that's constantly bugging me, pulling me out of the flow. It's a monster of a tool that tries to solve a problem I don't have.
- jondubois 6y ago
russellbeattie 6y ago
Hmm. I wonder how much longer it'll be before they migrate from Typescript to the next fad version of JavaScript that comes along?
d0m 6y ago
That bit was interesting: >> Manually convert a list of ~100 commonly edited files from Coffeescript to TypeScript. Seems obvious, but outlining it as a critical step probably helped in many ways.
apatheticonion 6y ago
Though I use it daily, my biggest criticism of TypeScript is that it's not opinionated enough. From inception it was designed as sugar on top of JavaScript but not a replacement, and therefor they decided not to make decisions outside of the ECMAScript specification. The advantage to this is developer buy in, the downside is how annoying it is to work with at scale. In a monorepo, running 10 compilers in watch mode because TS can only consume external source which is compiled to JS. You can't consume TypeScript source directly (which would be nice if you want to use github as a package repository). But it's fine. I'm happy paying the cost to not use JavaScript directly, but I am disapointed because it could be so much more.
- johannesgoslar 6y ago
  There are project references and build mode, so 1 compiler for a monorepo also works.
- edjrage 6y ago
  Have you seen Deno? Would it help with your issues? https://news.ycombinator.com/item?id=23172483 https://news.ycombinator.com/item?id=23172483
xvilka 6y ago
Instead of TypeScript which is very far from being all-typed, I hope there will be wider adoption for proper Web languages like ReasonML[1], BuckleScript[2], PureScript[3], Elm[4], etc. With a better WebAssembly adoption and once they solve the garbage collection problem[5] and direct DOM access[6] there will no even need in JavaScript "glue". [1] https://reasonml.github.io/ https://reasonml.github.io/ [2] https://bucklescript.github.io/ https://bucklescript.github.io/ [3] https://www.purescript.org/ https://www.purescript.org/ [4] https://elm-lang.org/ https://elm-lang.org/ [5] https://github.com/WebAssembly/gc/issues/44#issuecomment-623912377 https://github.com/WebAssembly/gc/issues/44#issuecomment-623... [6] https://stackoverflow.com/questions/42628328/wasm-access-dom https://stackoverflow.com/questions/42628328/wasm-access-dom
- Sebb767 6y ago
  Well, loose typing allows for far faster prototyping. I know some people will debate me on this, but mixing int and string in an array or returning an object or a string is far faster than going the 'proper' way. It's not great, but it gets you started earlier and that's a big point. Another thing is that it's extremely easy to migrate from vanilla JavaScript to Typescript. You simply add a compile step at first, which breaks nothing, and then you slowly move your js files to ts while still being able to cross use them. I've migrated a ~10k LOC app and it was a breeze - whenever I needed to touch a module, I simply took the 5 minutes to make it TS. Whenever I touched a function, I added the type parameter. Being able to slowly convert a big app without ever having a major breakage or a massive change is something extremely valuable and rare (looking at you, `async`).
  - arkanciscan 6y ago
    TypeScript just moves all errors from runtime to compiletime, even the ones nobody would ever realistically encounter. The user's browser is the only typechecker that matters, and that's why end-to-end tests are more important than type-linting.
- arkanciscan 6y ago
  Lol "proper". Type nerds!
jashkenas 6y ago
I started reading through these comments expecting a tall wave of negativity, and was surprised to see such a warm wash of mixed and fond memories from the "bad old days" when ES3 and IE ruled the roost. Full disclosure: I haven’t used it myself much since ~2012 or so, and modern JavaScript now contains many of the most important features that CoffeeScript offered at the time .... Although they did screw some things up (IMHO): null-vs-undefined in default arguments, super as a parent reference instead of a direct function call, optional parens for single-arguments arrow functions (Prettier agrees!), no shared semantics between arrow and normal functions, that class syntax only supports methods and not data as properties, and so on... When all is done and dusted, I hope that CoffeeScript can be looked back on with affection as a little experiment that showed surprising vigor, one that — with no corporate backing and zero financial support — spread by word of mouth through the web community of the early 2010s, and helped fuel the fire to get JavaScript moving and evolving as a language again. As a side note — and I write this without bitterness — I do find it a bit strange that extremely well-resourced companies like Dropbox, GitHub, CircleCI, Trello, Airbnb (and many, many more) would write so many hundreds and hundreds of thousands of lines of CoffeeScript without ever attempting to contribute changes or fix the issues that they wanted to fix. It’s open source! They probably would have been able to quickly and cheaply make most of the changes they wanted. Anyhow, cheers for the blast from the past!
- victorvation 6y ago
  Thank you as well Jeremy, for helping us realize how useful JS could be with a proper stdlib in underscore, or how JS could be evolved with Coffeescript. Part of the magic of JS in those days was observing how one OSS project (see: underscore, async, Q, Backbone, Node, Babel, Browserify, etc) could have such a profound impact on the JavaScript ecosystem.
- deleted 6y ago
  [deleted]
- jessaustin 6y ago
  Thank you so much for CoffeeScript. I find it an ongoing pleasure to use.
- 6y ago
bubba1236 6y ago
its glaringly obvious coffeescript was written by someone with no knowledge of language design
arkanciscan 6y ago
I eagerly await the Typescript to SpoonScript (what have) migration of 2027.
dzsekijo 6y ago
https://saagarjha.com/blog/2020/05/10/why-we-at-famous-company-switched-to-hyped-technology/ https://saagarjha.com/blog/2020/05/10/why-we-at-famous-compa... :P
- madmaniak 6y ago
  Awesome! Thank you for this article.
neya 6y ago
I use coffeescript in 2020. It's a great language of choice especially if you come with a background of good programming languages like Ruby, Python, Elixir, Etc. Coffeescript makes code more succinct, readable and javascript tolerable. I tried typescript, but, it's not my cup of tea and it has it's own quirks. I work with large scale media companies and never has coffeescript been in my way. If anything, it has made javascript bearable. These days, my choice is to avoid Javascript if I can and use something like Phoenix LiveView if I can get away with it. I wish the coffeescript developers can ignore all the hipster noise and continue to support the project for their effort has saved so much valuable developer time.
- lioeters 6y ago
  I used CoffeeScript for a few years, and I went in deep. I loved the succinct and elegant syntax, it made coding in JavaScript a joy. I still think it's a wonderfully designed language with merit and worth. When I decided to move on to ES2015, one reason was that JavaScript grew up, adopting some of the ideas of CoffeeScript, and the non-standard aspects of the latter became incompatible. (I recall some ECMAScript features couldn't be implemented in CoffeeScript, at least for a long time, due to existing syntax.) A bigger reason was the mindshare of the developer community. When the majority adopted Babel and staying "future compatible", using modern language features that are guaranteed to be in the standard. I want the code I write to be accessible to the majority, so more people can read, understand, and contribute to it. This is important for team work, such as easier onboarding of new members, so they don't have to learn a new (flavor of) language. Choosing an "alternative" language also has long-term implications. When a developer moves on to a different project or company, they leave behind the code for others to maintain and develop. I realized that CoffeeScript would become legacy code, that someone will have to convert back to "normal" JavaScript eventually. I couldn't justify my developer convenience with that associated cost to others. Funny enough, these days I prefer to write in TypeScript, another alternative flavor. I'm not "all in" yet, mainly because other developers at my work haven't picked it up. I have the impression that TypeScript is more of a standard than just a flavor, so I believe that writing it will not incur a long-term cost, but rather be a benefit, as more maintainable, type-safe(r) codebase. Still, time will tell if that's true. Maybe I'm again contributing to legacy code, this time in TypeScript.
root_axis 6y ago
I loved CoffeeScript... I just loved types more. If CoffeeScript had a type system akin to TS or Flow, I'd be in heaven.
d3nj4l 6y ago
> In 2012, we were still a fairly scrappy startup of about 150 employees. Perhaps it's just the changing definition of the word "startup", but the idea of a 150-employee startup being described as "scrappy" made me chuckle.
jondubois 6y ago
CoffeeScript never made any sense. The drawbacks of having a build/bundling step and having to run/debug transpiled code were never worth the tiny benefits it offered. I think the drawbacks of bundling are still not worthwhile even for TypeScript, but I'm not surprised that people who liked CoffeeScript would like TypeScript even more. It is unquestionably more useful; at least you get some value in exchange for having to spend most of your development time waiting for the build to finish. What is mind boggling to me is just how popular CoffeeScript became. It makes no sense at all. I guess it just got a lot of celebrity endorsements. I think the problem is that 'real programmers' held such prejudiced and condescending views of JavaScript that they were not willing to learn it and figure out best practices. They were too proud for JavaScript but they still needed to use it for their job so that's why they were prepared to use any possible alternative; better or worse - At least their ego was protected. Same thing with TypeScript; its main purpose is protecting developers' egos by allowing them to leverage the power of JavaScript without actually having to admit to themselves that they're using JavaScript. IMO, it's self-deception. JavaScript has proven itself to be an amazingly flexible, adaptable and backward-compatible language. It has flaws just like any other language but it's an objectively amazing language. It has proven itself. Some developers will insist that it was because of JS's monopoly on browsers that it was successful but you'd be surprised by how many set top boxes and car navigation systems are powered by JavaScript (and they could have used any other language). JavaScript achieved this in spite of being constantly undermined - The fact that it was able to grow and dominate in such adverse social environment speaks to how truly great it is as a language.
- ricardobeat 6y ago
  > the tiny benefits it offered It allowed using language features that only now, nearly a decade later are commonplace. It offered huge benefits.
skilesare 6y ago
Still use coffeescriot when I need to do something quick. It has added all the async goodness of the more recent js implementations and it is still 10x easier to read and makes me 10x more effective.

307 points by dgoldstein0 6y ago

nosefrog 6y ago

I worked on this project, it was super fun. Open to answering any questions.

faitswulff 6y ago
What was fun about it?
- nosefrog 6y ago
  I personally think compiler tech is really interesting, and 90% of the project was writing transformations on ASTs. There's something about working in such an exacting environment where bugs are especially bad because they often manifest in subtle and hard to catch ways that's exhilarating. :)
city41 6y ago
I’m curious why not allow implicit anys instead of creating the tool that inserted anys? Seems roughly the same outcome but implicit anys would take a lot less work?
- dgoldstein0 6y ago
  Because of the way we had type checking set up - our existing code already used noImplicitAny, and we wanted to keep that, and we were typechecking it all in one shot, together, so we couldn't have different typescript flags for different files. Now as to why to use noImplicitAny in the first place: mainly because implicit anys are usually accidents - places where developers didn't realize they should put a type. And the explicit `any` in many ways is sitting there for anyone who cares to replace it with something better; whereas implicit anys are much harder to notice.
Xt-6 6y ago
Any chance some of the codemon used could be shared?

CapriciousCptl 6y ago

I fully remember picking up coffeescript because Dropbox had used it. I only ever used it on one project. I try and remember that every time I have the urge to go with Reason, Elm or even wasm compiling things. Long live JS.

melling 6y ago
Does any alternative have any traction? ReasonML is used by Facebook. Elm used to get more attention on HN.
- wbc 6y ago
  Reason looks pretty cool but I'm weary given the outcome of flow
  - rashkov 6y ago
    Reasonml claims, as an explicit goal, to output very readable and modern JavaScript, so it shouldn’t be such a risk. That task is a work in progress, but even looking at the latest recent release you can see that it’s coming along nicely.
city41 6y ago
Since wasm has native browser support it doesn’t really feels like it fits into this group. I have a feeling in a few years wasm will be pretty common.
- julianeon 6y ago
  Yeah, wasm is offering something those others aren't. You could say that Coffeescript to Typescript is a lateral move. Try as you might, you can't do the things wasm is best for - say, graphics - in Coffeescript.
Roboprog 6y ago
If you are trying to build for a business, or something you yourself will have to maintain for years to come, vanilla JS seems like the way to go. Perhaps Typescript isn’t a fad to be abandoned, unlike say GWT, CoffeeScript, et al, but why risk it? Javascript doesn’t feel painful to me like Java does. I don’t have a lot of problems with it that need solving with an alternate front end. Long live JS!

dgoldstein0 6y ago

Author here, also willing to answer questions

pansa2 6y ago
“Lack of delimiters“ is given as the most common complaint about CoffeeScript. I’ve never written any CoffeeScript - Is this referring to the language’s Python-like significant indentation, or something else?
- dgoldstein0 6y ago
  something else. More that `()`, `[]`, `{}`, and `,` in a lot of places in the language syntax were optional. And we embraced that... way too much. E.g. foo: 1 bar: 2 is the same as { foo: 1, bar: 2, } for basically no good reason. When you start combining a lot of these, whitespace takes extra significance, and in extreme cases can easily change what you think the meaning of your code is, and what it actually is.
molszanski 6y ago
Thank you for the article! Very interesting!
Xt-6 6y ago
Thank you for sharing! Any chance you could share some of the codemods used?

bambataa 6y ago

As someone who came into development after the Coffeescript wave I’m interested to know: how much did it feel like the future? Was it always an early adopter, “look how forward we are” kind of thing, or was it just popular with Rubyists? I’m trying to calibrate it with other possibly-next-big-thing front end languages.

wahnfrieden 6y ago
Personally speaking from what I saw around the internet and my own experiences with peers using it, it was contentious whether it was so forward-thinking or sufficiently differentiated to make it worth it.
- bartread 6y ago
  Back in 2013/14 I remember on a couple of occasions being quite annoyed when I found npm packages that I wanted to bugfix were written in Coffeescript rather than plain old JS. It always seemed so unnecessary, and tended to push me towards alternative solutions.
chipotle_coyote 6y ago
I think CoffeeScript was definitely popular outside the Ruby community, too, for a while. (After all, Dropbox was/is a Python shop, not Ruby!) Speaking strictly for myself, while I liked a lot of what CoffeeScript was trying to do, I didn't love the "one layer removed" feel of writing in a language that wasn't the one actually being executed. Also, I often found CoffeeScript to be cryptic in ways that vanilla JS, for all its quirks, really wasn't. So I think it felt like the future for a couple years, until JavaScript ES6 took off and it started feeling kind of superfluous -- ES6 felt like it was taking the good parts of CoffeeScript while leaving a lot of the quirks behind.
dgoldstein0 6y ago
It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a few years. I think the main thing to note is that we were supporting IE7+ when we adopted coffeescript. So we couldn't even write standard ES5 - ES3 would have been the lowest common denominator supported. So having classes, optional chaining, array comprehensions, for-in loops that actually looped over items in an array (like ES6 for-of) - all those features were super useful. And you didn't need to worry about function declaration hoisting (or any confusion it could cause) because coffeescript only compiled to function expressions, which got bound to variables. Unfortunately, coffeescript came with some others like implicit returns and tons of optional syntax that we didn't realize was problematic until far too late. And being a python-based org, having a frontend language that looked similar (space-delimited, a lot of similar features e.g. array comprehensions were like list comprehensions, ternaries that looked more readable) seemed like features. But some of these features bit us hard at times, because they didn't work like python - the worst, in my opinion, was that `is not` and `isnt` looked the same but meant very different things in coffeescript. `is not` meaning `=== !` and isnt meant `!==`. But given the alternative was writing prototypical-inheritance by hand, and dealing with various IE7isms directly? It was a sensible tradeoff at the time.

jtth 6y ago

This makes me miss CoffeeScript. Ah, well.

city41 6y ago
Only thing I still miss is noop functions are two characters. Everything else I liked is in JS now that nullish coalescing landed.
- recursive 6y ago
  `_=>_` is technically more than two, but not by much.
  - hombre_fatal 6y ago
    Identity function is more confusing than just ()=>{} which is obviously noop because it doesn't return the input.
    - recursive 6y ago
      If you don't provide an argument, it will use undefined, which is the same thing yours returns. Maybe it's more clear, but it's about even for me.

eecc 6y ago

I wonder what happened with the devs that started the tumble towards the Coffeescript migration... still locked in the cellar?

szhu 6y ago
I don't think the CoffeeScript advocates did anything wrong at all. CoffeeScript was a popular solution with a healthy ecosystem, no one knew when JS was going to get these features, and TypeScript was still an emerging player (just like other typed JS variants like Flow). Also, when I wrote in CoffeeScript, (1) I loved the JavaScript ecosystem more, (2) I understood the code I wrote better and built and learned more quickly, and (3) I understood the nuances of an JS-extension language, which helped me quickly understand what TypeScript was when I heard of it. I'd assume that other developers got some of these benefits as well, and these benefits may have been well worth the cost of converting from CoffeeScript later.

Jare 6y ago

> it was absurd to expect anyone to want this as their full time job for even a month or two That gave me a true 'kids these days' moment... In my day within a spanish bank, as a team of 4 interns, we spent over 6 months reviewing/documenting an entire proprietary platform C codebase (full of gotos, endian-dependent hacks, post-compile patches and every horrible thing you could imagine), and then with a larger (~3x) team about 12 months cleaning, porting and expanding that codebase to a clean platform (if you can call SCO Unix 'clean'). What sort of dynamics prevent a product startup like Dropbox build an engineering team that includes the capability to do such a task?

bcrosby95 6y ago
Because startups tend to use how much you enjoy coding as a proxy for how good of a coder you are. So if you purposefully hire a bunch of people because they like coding, it's going to cause a shitload of problems once you unleash an "unfun" job like this on them for such a long period of time.
- whynotminot 6y ago
  Wait what? So you should hire coders who don't like coding to do coding?
  - nojito 6y ago
    People who "like" coding tend to prefer hot new tech as a way of experimentation. They often ignore the actual business problem that needs to be solved, because it can be solved using "boring" technology.
    - koz_ 6y ago
      The thing is boring tech is often really just painful tech, where pain manifests in lots of different ways (error-prone repetition, painful manual testing, hard to read spaghetti code, etc). Programmers who are too insensitive to pain will continue to generate pain for themselves and others.

blitmap 6y ago

I truly do not understand why so many jumped from Coffeescript. I still use it and still believe I can be more concise and expressive in Coffeescript. Typescript and ES2015 picked up a lot of wonderful things, but I find myself writing a lot less boilerplate in Coffeescript. I will continue to "do me". I dev in Coffeescript and publish in JS. The project even made it a focus to transpile to readable/friendly JS. No biggie. I would not publish things like this, though :) console.log [ i if i % 3 and i % 5, 'fizz' unless i % 3, 'buzz' unless i % 5 ].join '' for i in [ 1 .. 100 ] Separately, I bought overpriced raspberry pi's instead of cheaper alternatives because I knew the community was a strong source of support. Modern JS has a much larger community than Coffeescript 2.

dgoldstein0 6y ago
I recall when we first adopted Coffeescript, the engineers who did it touted that we had about 20% fewer lines of code as an example of coffeescript being better - a lot of which was probably just the removal of lines that only had curly-braces. In hindsight, this wasn't a good metric to judge the language on. As a larger engineering organization, what we've definitely learned over time is that we need to prioritize readability (and maintainability) over writability - as our code is going to last a long time and the original engineer who wrote it, will likely move on to another project, team, or even company. And while maybe they train their replacement, after a second or third iteration of that, the knowledge can easily end up lost. Coffeescript, as a language, definitely prioritizes terseness, often at the expense of readability. And we didn't have internal coding standards that pushed back on this. But even if we had done a better job using coffeescript, we're still better off in typescript today, due to the stronger community and stronger set of available open source tools to work with the language.
- blitmap 6y ago
  I think it does depend on how familiar the syntax feels to each individual. To me Coffeescript is the right balance. I absolutely love writing Literate Coffeescript. I am _not_ a fan of strictly typed languages but I do hope Coffeescript finds a friendly syntax for gradual typing like TS in the future. I usually prototype in a 'ducky' way and then lock down type expectations when I'm polishing.

29athrowaway 6y ago

Coffeescript tried to simplify the syntax, but it went too far. - A statement such as f(g(x)) becomes absurd without parentheses. - Indentation has a meaning, but it is legal to have inconsistent indentation. Code is written once, read many times. Coffeescript got that backwards. CoffeeScript is to JavaScript what Stenography is to Writing. Steno makes sense when you have to write something being dictated to you in real-time, but if you are not in a hurry, just write.

dgoldstein0 6y ago
precisely. Though some of their constructs, like classes and for-in loops - are great for reading and writing.
- 29athrowaway 6y ago
  Coffeescript does have useful features, but problems such as the ones I described made CoffeeScript code inconvenient to maintain in practice. If we weigh the convenient aspects of CoffeeScript against the inconvenient aspects, in the end, CoffeeScript can be an inconvenient language to use. It was the case at least for me in various projects I had to maintain. Part of the inconvenience was all the JavaScript tooling you cannot use, and occassionally being forced to read JavaScript code generated by CoffeeScript.
  - dgoldstein0 6y ago
    Yup, totally agree. In 2012 when we adopted Coffeescript, it was less cut and dry - all the open source tools we love now - prettier, eslint, etc. - didn't exist. So the tradeoff was less obvious then.
    - spiralx 6y ago
      I loved coding CoffeeScript on my own a few years ago. Today the thought of having to review PRs written in CoffeeScript by my junior developers is terrifying.
6y ago

k__ 6y ago

CoffeeScript? 2017? I had the impression that CS was done when ES2015 came out in ... Well 2015 I personally prefered LiveScript, should have been.

bcrosby95 6y ago
They started the project of looking for a replacement language in 2015. You can't instantly rewrite all the code.
- k__ 6y ago
  -can't +shouldn't My co-worker of that time did exactly that one week before I got hired. Also, he told noone. I just saw it one time, when I played around with a tool that would visualize Git commits, years later. Thousands of lines of code. Absolute mad lad.

lewis1028282 6y ago

Is CoffeeScript all but dead? I use Ruby and Python a lot so the syntax of CoffeeScript looks great to me!

rogem002 6y ago
I do Rails full time and most the CoffeeScript lives in the "legacy" side projects. Most projects I'm on have moved to vanilla JavaScript or ES6 via Webpack. I don't think it's dead (it's still popping up), but I think it's time has passed.
jessaustin 6y ago
Lots of people use it (I use it for all my personal stuff) and it sees regular updates. [0] I think it coordinates well with modern client-side frameworks like Mithril (... and experts agree [1]). It has kept up with the new stuff in javascript, and it often does the new stuff better than JS. Example: in coffeescript you don't need the goofy function declaration flags that JS requires: "*" and "async". In coffeescript a generator is a function that yields and an async function is a function that awaits. This is clearly better. Obviously, Typescript is more appealing to management. It may not be obvious from this thread, but bragging about how old-n-busted coffeescript is compared to... whatever was a lot cooler a couple of years ago than it is now. Nowadays the cool kids complain about npm or rollup or something. [0] https://github.com/jashkenas/coffeescript/commits/master https://github.com/jashkenas/coffeescript/commits/master [1] https://mithril.js.org/signatures.html#splats https://mithril.js.org/signatures.html#splats

fourseventy 6y ago

I worry about the long term viability of using an offshoot language of Javascript such as Coffeescript or Typescript. These types of languages have a habit of falling out of vogue and basically becoming a dead language, which is exactly what happened to coffeescript. If a company decided to write an app in coffeescript in 2010, today they have a big pile of code written in a dead language on their hands. If instead the company had chosen a mainstream language with a guaranteed future such as JS, Java, or c# it wouldn't be an issue.

ryanianian 6y ago
Typescript is nice in that it's a superset (mostly) of js. That doesn't mean it won't fall out of vogue, just that in a lot of cases converting from TS to JS is mostly straightforward, so you can "just" remove some type information and end up with valid JS.
- city41 6y ago
  You should be able to let tsc do it for you with a properly configured tsconfig file. Mostly just want it to not emit any polyfills.
heipei 6y ago
What do you mean by dead? It's still maintained and developed and still works great. Yeah, not many people are using it for new projects so if you're anxious about using something with the biggest "mindshare" then Coffeescript isn't for you, I give you that.
int_19h 6y ago
TypeScript is the best bet in that regard, because not only it's backed by a large software company, but that company also builds all of its web apps (and now also Electron desktop apps) using TS. The sheer amount of buy-in inside Microsoft is such that I'd expect it to be maintained for a very long time even if there were no external users at all. But then this reasonable expectation that it'll still be there 10 years from now is also what's driving external users to it, among other things. In fact, TypeScript is in PYPL top 10, and it's higher there than Go. It is a mainstream language now.

seemslegit 6y ago

Cofeescript will always be remembered as peak code hipsterdom.

thrower123 6y ago

The only people I ever knew personally who used CoffeeScript also used Rails. That was usually the combo then. The shine has kind of come off Rails, and the cool kids followed the shiny to the next thing, usually node, and so they moved to Typescript.

studentik 6y ago

CoffeeScript rocks for functional programming. Less chars and more sense per LoC, easier to learn than JavaScript and syntax sugar is sweet.

erichurkman 6y ago

My fond memory of CoffeeScript was an interview I did way back when at Olark. It was a full day 'paid work along' interview that was popular at the time. I'd never touched CoffeeScript prior. In less than the day, I was proficient enough even navigating a foreign code base to build out a small feature within the Olark platform. (I think it was managing chat operators as groups?) Fond memories!

freedomben 6y ago

CoffeeScript was an amazing companion to a Rails backend. While I did get bit a few times by unexpected CoffeeScript behavior (implicit returns and whitespace, ah!), it was substantially more beautiful and "developer happiness" than the options at the time (2014-ish). CoffeeScript will always have a warm place in my heart, tho I do use TypeScript as much as possible now.

ravenstine 6y ago

I stopped using CoffeeScript just because JavaScript fixed most of the issues that got me to use CoffeeScript back in 2014. Once ES2015+ became well supported, I decided I'd rather write code in the language that the interpreter understands, rather than something that precompiles. CoffeeScript isn't bad... it's just not significantly better than JavaScript is today. Also, I find it interesting how many people like the Python syntax but hate CoffeeScript syntax. They have a lot of similarities.

eshyong 6y ago
As someone who works with Python a lot, Coffeescript always looked more like Ruby to me, especially with all the syntactic sugar (lack of parens, keywords like `unless` or `isnt`, #{} for string interpolation, etc)

deanmkenzey 6y ago

You can easily test your Coffeescript code with a dynamic type checker and be perfectly type safe, even at runtime! Why for gods sake convert your code base to another language primarily for imaginary type safety? But for some strange reason entire armies of developers move to Microsoft's Typescript, living their imaginary type save dream. Moving from a language as Coffeecript to Typescript is like dropping at least 25% of your productivity. Not only you'll have to write more code, which in itself increases the chance for bugs, but you'll also be fighting countless compiler issues, installing numerous @types modules, having intellectual discussions about types and whatsoever to make it 'kind of work'. Oh, and almost none of the TS code bases I've seen are without the 'any' keyword, which is actually an instant breach of your type safe haven. IMAO 'any' should never pass a code review in a Typescript project if you want to stay true to your religion. With such a strict regime, like you are forced to with real strictly typed languages, would completely eliminate TS. Without 'any' it's practically impossible to write a large code base with it. I wrote numerous relatively bug free applications in Coffeescript, small and large as well. Just do good testing and you'll be fine, and as a bonus you'll have type safety at runtime! The mine field is not types IMAO, there is so much more to high quality code bases.

matchbok 6y ago
Using 'any' is perfectly fine, you just don't understand how most companies use TS.
- deanmkenzey 6y ago
  Not using 'any' is also perfectly fine, as you can with Javascript, Python, Ruby, etc.. And I guess that most companies just don't understand how I use Coffeescript. Besides, I am not against others using Typescript, it's a fun experiment and a great opportunity for front-end developers to learn about static typing, enjoy it if you can! For me it unfortunately doesn't work, I've never gained from it because I generally don't have type issues. It's a pain in the ass that's constantly bugging me, pulling me out of the flow. It's a monster of a tool that tries to solve a problem I don't have.
jondubois 6y ago

russellbeattie 6y ago

Hmm. I wonder how much longer it'll be before they migrate from Typescript to the next fad version of JavaScript that comes along?

d0m 6y ago

That bit was interesting: >> Manually convert a list of ~100 commonly edited files from Coffeescript to TypeScript. Seems obvious, but outlining it as a critical step probably helped in many ways.

apatheticonion 6y ago

Though I use it daily, my biggest criticism of TypeScript is that it's not opinionated enough. From inception it was designed as sugar on top of JavaScript but not a replacement, and therefor they decided not to make decisions outside of the ECMAScript specification. The advantage to this is developer buy in, the downside is how annoying it is to work with at scale. In a monorepo, running 10 compilers in watch mode because TS can only consume external source which is compiled to JS. You can't consume TypeScript source directly (which would be nice if you want to use github as a package repository). But it's fine. I'm happy paying the cost to not use JavaScript directly, but I am disapointed because it could be so much more.

johannesgoslar 6y ago
There are project references and build mode, so 1 compiler for a monorepo also works.
edjrage 6y ago
Have you seen Deno? Would it help with your issues? https://news.ycombinator.com/item?id=23172483 https://news.ycombinator.com/item?id=23172483

xvilka 6y ago

Instead of TypeScript which is very far from being all-typed, I hope there will be wider adoption for proper Web languages like ReasonML[1], BuckleScript[2], PureScript[3], Elm[4], etc. With a better WebAssembly adoption and once they solve the garbage collection problem[5] and direct DOM access[6] there will no even need in JavaScript "glue". [1] https://reasonml.github.io/ https://reasonml.github.io/ [2] https://bucklescript.github.io/ https://bucklescript.github.io/ [3] https://www.purescript.org/ https://www.purescript.org/ [4] https://elm-lang.org/ https://elm-lang.org/ [5] https://github.com/WebAssembly/gc/issues/44#issuecomment-623912377 https://github.com/WebAssembly/gc/issues/44#issuecomment-623... [6] https://stackoverflow.com/questions/42628328/wasm-access-dom https://stackoverflow.com/questions/42628328/wasm-access-dom

Sebb767 6y ago
Well, loose typing allows for far faster prototyping. I know some people will debate me on this, but mixing int and string in an array or returning an object or a string is far faster than going the 'proper' way. It's not great, but it gets you started earlier and that's a big point. Another thing is that it's extremely easy to migrate from vanilla JavaScript to Typescript. You simply add a compile step at first, which breaks nothing, and then you slowly move your js files to ts while still being able to cross use them. I've migrated a ~10k LOC app and it was a breeze - whenever I needed to touch a module, I simply took the 5 minutes to make it TS. Whenever I touched a function, I added the type parameter. Being able to slowly convert a big app without ever having a major breakage or a massive change is something extremely valuable and rare (looking at you, `async`).
- arkanciscan 6y ago
  TypeScript just moves all errors from runtime to compiletime, even the ones nobody would ever realistically encounter. The user's browser is the only typechecker that matters, and that's why end-to-end tests are more important than type-linting.
arkanciscan 6y ago
Lol "proper". Type nerds!

jashkenas 6y ago

I started reading through these comments expecting a tall wave of negativity, and was surprised to see such a warm wash of mixed and fond memories from the "bad old days" when ES3 and IE ruled the roost. Full disclosure: I haven’t used it myself much since ~2012 or so, and modern JavaScript now contains many of the most important features that CoffeeScript offered at the time .... Although they did screw some things up (IMHO): null-vs-undefined in default arguments, super as a parent reference instead of a direct function call, optional parens for single-arguments arrow functions (Prettier agrees!), no shared semantics between arrow and normal functions, that class syntax only supports methods and not data as properties, and so on... When all is done and dusted, I hope that CoffeeScript can be looked back on with affection as a little experiment that showed surprising vigor, one that — with no corporate backing and zero financial support — spread by word of mouth through the web community of the early 2010s, and helped fuel the fire to get JavaScript moving and evolving as a language again. As a side note — and I write this without bitterness — I do find it a bit strange that extremely well-resourced companies like Dropbox, GitHub, CircleCI, Trello, Airbnb (and many, many more) would write so many hundreds and hundreds of thousands of lines of CoffeeScript without ever attempting to contribute changes or fix the issues that they wanted to fix. It’s open source! They probably would have been able to quickly and cheaply make most of the changes they wanted. Anyhow, cheers for the blast from the past!

victorvation 6y ago
Thank you as well Jeremy, for helping us realize how useful JS could be with a proper stdlib in underscore, or how JS could be evolved with Coffeescript. Part of the magic of JS in those days was observing how one OSS project (see: underscore, async, Q, Backbone, Node, Babel, Browserify, etc) could have such a profound impact on the JavaScript ecosystem.
deleted 6y ago
[deleted]
jessaustin 6y ago
Thank you so much for CoffeeScript. I find it an ongoing pleasure to use.
6y ago

bubba1236 6y ago

its glaringly obvious coffeescript was written by someone with no knowledge of language design

arkanciscan 6y ago

I eagerly await the Typescript to SpoonScript (what have) migration of 2027.

dzsekijo 6y ago

https://saagarjha.com/blog/2020/05/10/why-we-at-famous-company-switched-to-hyped-technology/ https://saagarjha.com/blog/2020/05/10/why-we-at-famous-compa... :P

madmaniak 6y ago
Awesome! Thank you for this article.

neya 6y ago

I use coffeescript in 2020. It's a great language of choice especially if you come with a background of good programming languages like Ruby, Python, Elixir, Etc. Coffeescript makes code more succinct, readable and javascript tolerable. I tried typescript, but, it's not my cup of tea and it has it's own quirks. I work with large scale media companies and never has coffeescript been in my way. If anything, it has made javascript bearable. These days, my choice is to avoid Javascript if I can and use something like Phoenix LiveView if I can get away with it. I wish the coffeescript developers can ignore all the hipster noise and continue to support the project for their effort has saved so much valuable developer time.

lioeters 6y ago
I used CoffeeScript for a few years, and I went in deep. I loved the succinct and elegant syntax, it made coding in JavaScript a joy. I still think it's a wonderfully designed language with merit and worth. When I decided to move on to ES2015, one reason was that JavaScript grew up, adopting some of the ideas of CoffeeScript, and the non-standard aspects of the latter became incompatible. (I recall some ECMAScript features couldn't be implemented in CoffeeScript, at least for a long time, due to existing syntax.) A bigger reason was the mindshare of the developer community. When the majority adopted Babel and staying "future compatible", using modern language features that are guaranteed to be in the standard. I want the code I write to be accessible to the majority, so more people can read, understand, and contribute to it. This is important for team work, such as easier onboarding of new members, so they don't have to learn a new (flavor of) language. Choosing an "alternative" language also has long-term implications. When a developer moves on to a different project or company, they leave behind the code for others to maintain and develop. I realized that CoffeeScript would become legacy code, that someone will have to convert back to "normal" JavaScript eventually. I couldn't justify my developer convenience with that associated cost to others. Funny enough, these days I prefer to write in TypeScript, another alternative flavor. I'm not "all in" yet, mainly because other developers at my work haven't picked it up. I have the impression that TypeScript is more of a standard than just a flavor, so I believe that writing it will not incur a long-term cost, but rather be a benefit, as more maintainable, type-safe(r) codebase. Still, time will tell if that's true. Maybe I'm again contributing to legacy code, this time in TypeScript.

root_axis 6y ago

I loved CoffeeScript... I just loved types more. If CoffeeScript had a type system akin to TS or Flow, I'd be in heaven.

d3nj4l 6y ago

> In 2012, we were still a fairly scrappy startup of about 150 employees. Perhaps it's just the changing definition of the word "startup", but the idea of a 150-employee startup being described as "scrappy" made me chuckle.

jondubois 6y ago

CoffeeScript never made any sense. The drawbacks of having a build/bundling step and having to run/debug transpiled code were never worth the tiny benefits it offered. I think the drawbacks of bundling are still not worthwhile even for TypeScript, but I'm not surprised that people who liked CoffeeScript would like TypeScript even more. It is unquestionably more useful; at least you get some value in exchange for having to spend most of your development time waiting for the build to finish. What is mind boggling to me is just how popular CoffeeScript became. It makes no sense at all. I guess it just got a lot of celebrity endorsements. I think the problem is that 'real programmers' held such prejudiced and condescending views of JavaScript that they were not willing to learn it and figure out best practices. They were too proud for JavaScript but they still needed to use it for their job so that's why they were prepared to use any possible alternative; better or worse - At least their ego was protected. Same thing with TypeScript; its main purpose is protecting developers' egos by allowing them to leverage the power of JavaScript without actually having to admit to themselves that they're using JavaScript. IMO, it's self-deception. JavaScript has proven itself to be an amazingly flexible, adaptable and backward-compatible language. It has flaws just like any other language but it's an objectively amazing language. It has proven itself. Some developers will insist that it was because of JS's monopoly on browsers that it was successful but you'd be surprised by how many set top boxes and car navigation systems are powered by JavaScript (and they could have used any other language). JavaScript achieved this in spite of being constantly undermined - The fact that it was able to grow and dominate in such adverse social environment speaks to how truly great it is as a language.

ricardobeat 6y ago
> the tiny benefits it offered It allowed using language features that only now, nearly a decade later are commonplace. It offered huge benefits.

skilesare 6y ago

Still use coffeescriot when I need to do something quick. It has added all the async goodness of the more recent js implementations and it is still 10x easier to read and makes me 10x more effective.