(Author here.) > fails to account for any time developing the translation tool There are (at least) two ways of looking at it: 1.) If you're an open source p

(Author here.) > fails to account for any time developing the translation tool There are (at least) two ways of looking at it: 1.) If you're an open source project or a company with a large amount of CoffeeScript that you want to move to JavaScript, should you convert it by hand, use decaffeinate, or take some other approach, and how long should you expect it to take? This is the viewpoint I was focusing on because that's the real situation people are in today now that decaffeinate exists and is stable. Hopefully the article convinced you that decaffeinate is the best tool for this job, but that you should still expect tens or even hundreds of hours of investment, depending on the size of your codebase, the level of code quality you're targeting, and the amount of risk you can accept. 2.) If you're a project or company with a codebase in language A and you want to convert it to language B, should you develop an in-house translation tool for that purpose? I think that in most cases, the answer is "no", unless you're a very large company, and this case is no exception. (Really, it depends on many factors, and tools like jscodeshift are a great way to lower the barrier to entry for large-scale codebase changes.) Not only did decaffeinate take a long time to develop, it was unclear how well it would work and how safe it would be. And, frankly, CoffeeScript to JavaScript is one of the easiest programming language conversions you can do. I mostly worked on decaffeinate because it was fun, rewarding, and educational, not because it was meant to be an efficient use of time for my company in particular. But given the number of people who have said "thank you" and the number of open source projects and companies that have already used it, hopefully it's a net benefit for the world.