Hacker News Reader

Comment by jlongster | Hacker News Reader

This sounds so much like some geeks wanting to hack. That's it. There isn't really a good reason to convert a codebase with tens of thousands of lines of code from js to CoffeeScript.

Not that there's anything wrong with that. But seriously, every single problem with javascript they mention is never a problem for javascript developers. You simply learn what's broken, and deal with it. Dealing with it is usually one line of code (or even less), making sure you just use ===, etc. It's really not a problem.

These kinds of posts smell a little like FUD to me, which is what I have a problem with.

View on HN

I've been writing JS for over a decade and never had a problem with it. I put off CoffeeScript for ages, because nothing was wrong with my JS code. "Besides," I thought, "CoffeeScript compiles to JS, it can't do anything JS can't do."

And that is true. Nothing is exactly wrong with JS. In fact many things are great about JS, which is how we end up with ClojureScript and CoffeeScript and x86 emulators. JS is very powerful -- maybe too powerful. There are a million ways to accomplish the same task, which means that during an initial look at a new JS codebase, the program flow is not obvious.

Some developers hate semicolons, some always put commas at the end of the line and some at the beginning, some always use braces and some don't use braces with single-line statements. One can never be sure where a statement ends, or what constitutes a code block, unless one hunts down all the trailing braces, parentheses, and semicolons. I'm not even going to mention all the possible inheritance patterns.

CoffeeScript is not nearly as flexible in syntax. There is one way to make a code block, one inheritance method. It doesn't need semicolons, braces, or parentheses because of its strict style. Therefore there is less to think about. There is less to go wrong. No one needs to use a CoffeeScriptLint, because CoffeeScript is not full of non-obvious 'gotchas'.

CoffeeScript code is more concise and more intuitive, because it reads more like an English sentence. When I read another developer's CoffeeScript I can begin understanding the meaning instantly, rather than having to spend time determining the structure and programming technique. List comprehensions, ranges, and other functional programming tools simply don't exist in pure JavaScript -- the JS equivalent is much more verbose and much less obvious. CoffeeScript encourages creating small flexible code blocks, which together make a powerful structure. This all leads to fewer opportunities for bugs to appear.

The only thing I don't like about CoffeeScript, is that I didn't keep an open mind and start using it sooner. I think anyone who considers themselves a serious JS developer should give CoffeeScript a try. It's a much more relaxing, simple way to write powerful JS.

(Credit goes to Spine.js switching to CoffeeScript to finally push me into it.)

EDIT: Of course it is possible to write ambiguous, unclear code in any language. CoffeeScript is an opportunity to let go of old habits and find a fresh perspective on problem-solving: Maybe there is a better way to do things. (I had to let go of semicolons!)

CoffeeScript's functional programming style has changed the way I approach programming. My code is now more robust and less complicated. Less bugs and less keystrokes mean I ship faster. CoffeeScript is a better language because it's a tool which makes me a better developer.

There's definitely improvements to the language in CoffeeScript. It makes sense; it was able to take 10 years of js experience and write a new language. But that doesn't mean CoffeeScript itself is without problems, or that it even improves development time.

There's certainly many different ways to do things in CoffeeScript, like even calling functions (parenthesis is optional). Talk about having to think about syntax! http://stackoverflow.com/questions/12077114/coffeescript-syn...

There are other ambiguities too due to the arrow pattern for defining functions. You have to be careful where you place stuff.

CoffeeScript is definitely an improvement in some ways, but please don't market it as superior to javascript (I certainly prefer brackets). It's just different. All of this really doesn't make much difference in how long it takes you to ship products.

> CoffeeScript encourages creating small flexible code blocks, which together make a powerful structure. This all leads to fewer opportunities for bugs to appear.

Personally I find single-line statements that do too much to be difficult to read.

I also find nested functions really difficult to read in CS. From a coffee mug I own:

  coffee.height drink coffee, e.angle

That's only 2 functions, it gets much more confusing when it's 3 or 4 which multiple parameters. Before you say "don't nest functions that way", I agree completely, however a large part of the appeal of CS is reducing LOC and these one-liners, so in real world code I've come across this often.

Respectable CS coders I've seen "never" code like that. Jeremy (among others) have always said that you should "always" use parenthesis when not using them makes code ambiguous even in the slightest bit.

So, you should write than as

    coffee.height (drink coffee, e.angle)

Also, understand that you can use parenthesis in a lot of places to remove ambiguity:

    setTimeout (
      # ...
    ), 400

instead of

    setTimeout
      # ...
    , 400

    doSomethingWithHashAndOtherVars {
       var1: 1
       var2: 1
       var3: 1
    }, var4, var5

instead of

    doSomethingWithHashAndOtherVars
       var1: 1
       var2: 1
       var3: 1
    , var4, var5

-------

Rule of thumb: When in doubt (or fear of future doubt), throw a couple parens around expressions, and a couple braces around objects.

As a rule of thumb I use braces and parens as a standard. I think making parens and braces optional was a mistake and they are necessary punctuation to the language. There is simply too much ambiguity without them and then when you're mixing and matching things become unreadable.

looks terrible either way

I wonder whether people would be less skeptical of CoffeeScript if its syntax were a bit closer to Python's: more parens, but simpler and clearer. For instance, what are Perl-style backwards if statements doing in CoffeeScript? They make it impossible to tell what a statement does by looking at the beginning of it (e.g. in other languages, "foo = ..." is almost always semantically an assignment of foo, and always syntactically an assignment) and thus decrease readability, just to save a pair of parentheses.

Yeah, I'm with you on this one. However, you can add brackets if you want (and I often do):

    coffee.height(drink(coffee, e.angle))

You can even use sexpy syntax if you want to confuse people:

  (coffee.height (drink coffee, e.angle))

It looks like it borrowed that syntax from Haskell.

Haskell programmers hate parentheses. They would write it as:

    flip coffee.height e.angle $ drink coffee

Where "flip" is the function that reverses the order of two arguments of a function and "$" is basically like a set of parentheses that are implicitly closed at the end of the line.

The reason to use CoffeeScript over JavaScript is because it is better software engineering.

Number of lines of code has been shown to be one of the few good indicators for predicting defects. CoffeeScript significantly reduces the number of lines of code in a project and therefore the number of defects.

CoffeeScript is cleaner and easier to read, which is better software engineering. CoffeeScript solves many of the issues with JavaScript. The fewer warts and plumbing people have to deal with related to the language, the more they can focus on the actual problems they wanted to solve.

This is a little bit like the architectural decision to program user applications in languages and platforms with garbage collection and built-in frameworks rather than using a language like C or C++ with manual memory management and minimal standard libraries. Sure you get less control over the lower-level details such as allocation and deallocation of memory, but those lower level details actually are distracting from the application domain and were actually repetitive and could be automated. So the best way to solve those problems is to move to a platform that abstracts them away or handles them for you.

The reason that developers don't like CoffeeScript (other than the fact that they haven't learned it yet, and don't want to take the time) is simple, psychological rather than logical, and its the same reason that they don't like platforms like the ones I was talking about above: it makes things significantly easier, and that is problematic psychologically for programmers for two reasons:

1) The whole point of being a programmer is that you are mastering complex ASCII codes that other people can't decipher. Making things less complex takes away part of your identity as a programmer (not for everyone obviously, but for many).

2) Many programmers instinctively and falsely believe that any system which makes their job significantly easier must automatically come with compensatory trade-offs in things like performance or flexibility. This is intuitive, but false.

CoffeeScript improvements: indenting two spaces and using -> plus no closing parens and curly braces makes nested callbacks much easier to read and write, fat arrow binds this making it easier to use classes, class and extends provide a standard, simple way to create and extend classes, iterating over arrays and objects is much easier and cleaner, control flow and function definition is cleaner, better variable scoping, simplified closer wrapper in loops, more straightforward boolean operators, existential operator for cleanly and simply checking for variable existence.

Thought of one other explanation for not liking CoffeeScript: plain old status quo bias. http://en.wikipedia.org/wiki/Status_quo_bias

better variable scoping

CS's scoping is a bit... dangerous, because there's no indication of a variable's scope. If you're not paying attention to your environment, you'll inadvertently stomp on higher scopes or globals. You can lose assignments through typos too.

JS made a mistake by allowing globals by omitting "var", but that at least can be worked around by using a linter or "use strict". A number of languages have made this mistake, and many later followed a similar path to fix it.

CS has a lot of nice properties, but we should not laud conflating variable definition and assignment. It has always been a mistake, and I hope CS's author eventually comes around and fixes it.

>CS's scoping is a bit... dangerous, because there's no indication of a variable's scope. If you're not paying attention to your environment, you'll inadvertently stomp on higher scopes or globals. You can lose assignments through typos too.

Not just that, but adding a variable to an outer scope can break functions that were previously just fine. Isn't the whole point of scoping that changing code in one place won't affect unrelated code in another place?

It's been much discussed, but I'm afraid I'm still very strongly of the opinion that it's an idea that yields positive benefits -- and we should continue to do as much to avoid shadowed variables as possible.

Always open to debate though, and note that other dialects (Coco, perhaps LiveScript) have added another operator to distinguish higher scoped assignments.

> Number of lines of code has been shown to be one of the few good indicators for predicting defects.

Curious - is there evidence that that applies in a cross-language manner? It seems intuitively sensible that a smaller project will have fewer bugs than a big project, but that's not the same as saying that a big project rewritten in a language which causes fewer lines of code to be used will result in fewer bugs - in the latter case, the systemic complexity is the same.

The answer is yes. The research suggests that the rate of development and the error rate are both linearly correlated with length of code rather than how much the program does, and this rate seems fairly consistent across a range of languages. I believe that Code Complete makes reference to this fact.

From a random Google search, http://panko.shidler.hawaii.edu/HumanErr/ would seem like a promising online resource to try to find some of the literature on error rates.

interesting - thanks!

> > Number of lines of code has been shown to be one of the few good indicators for predicting defects.

The token reduction is not that significant and the OP is honest enough to note that "line" reductions boil down to lack of closing braces. Relevant study to cite would be one that compared languages with or without explicit notation of scope. Intuitively it seems to be that braces are a visual aid that reduce bugs and do not promot them.

Its not just a lack of braces. There are fewer lines of code. Less typing and clearer code.

Do yourself a favor and spend a day with CoffeeScript and then tell me what you think intuitively.

By that reasoning, it is "better software engineering" to give variables, methods, etc. the shortest names possible.

I took out the line about the number of characters.

Number of SLOC corresponding to defect count is not something you dispute is it?

I'll dispute it. If I cram more code into a single line it will not lower my defect count. In fact there is a chance that the concision may turn into clutter and become harder to read/maintain and that may increase defect count.

Is there a measurement term for number of symbols (in the lisp sense) in a given program? Example: '+', 'add', 'defn' would all be individual symbols. I could see a loose correlation between symbol count and defect count... maybe.

Or to go even more abstract: number of concepts per program is probably the ultimate measurement we are looking for: https://en.wikipedia.org/wiki/Concept

True.

But CS doesn't encourage cramming more code in a single line, like veteran C++ers do.

It just give you nice shortcuts for what you have to manually write in vanilla JS (like maps, array comprehensions, ...)

To a lot of people CoffeeScript promotes the intangible benefit of happiness. (Similar to ruby.) If working in CoffeeScript makes everyone's work much more enjoyable (for whatever reason), with minimal cost, isn't it worth it? I, for one, want to minimize the amount of things I need to "deal with" at work, be it shoddy programming language workarounds or a half-broken coffee machine.

No, the parent is correct. JavaScript developers do not lose any sleep because '1' + 0 = 10. We learned to do integer math with integers and moved on. We learned to just use === and moved on. The Dropbox devs apparently didn't want to go through that learning curve, which is fine, but rewriting your application in another language just so that you don't have to look at semicolons is a big bikeshedding mistake. Writing new code in CoffeeScript and only rewriting legacy code as needed would have been a more sane way to transition.

How can you say it was a mistake when it only took one week? There was a cost, they paid it, now they can reap the benefits.

I program in C++ extensively. I "deal with it" a lot. I write things like this all the time:

    MapType::const_iterator it = map.find(x);
    if (it != map.end()) {
        // x is in map, process it
    }

I've done it for years, I know how to do it, and there are great benefits to getting iterators back from my data structures. Yet, I always feel a warm fuzzy when writing data processing scripts in Python, and I get to say:

    if x in map:
        # x is in map, process it

My point: even though one can have learned to "deal with it," there can still be a benefit to not having to deal with it anymore.

> How can you say it was a mistake when it only took one week? There was a cost, they paid it, now they can reap the benefits.

The cost is not just time (although that's certainly a big cost). They rewrote working production code for fun. Why this is a bad idea will likely derail the conversation so I'll just direct you here:

http://www.joelonsoftware.com/articles/fog0000000069.html

Joel's excellent essay does not apply here. The Netscape re-write was a re-write. That is, it was not a translation. Netscape looked at their code base, and decided, "We don't like the design of the architecture of our code. We're going to throw it out, re-design it, and re-implement it from scratch."

The Dropbox team clearly did not do that. They translated it from one language to another; the design did not change. Much of that translation was with an automatic tool. Again, there is a difference between re-implementing something, and translating it.

Further, the examples in Joel's posts took years. This took a week. The situations are completely different.

Personally, I find it disingenuous to link to an article and say "He has my argument" without actually stating what your argument is.

The scope is much smaller, but the problems are still the same, namely introducing new bugs to working production code and surrendering ground to competitors.

The scope is so small that it's on par with any other feature.

That essay is a classic. It is also wrong.

See http://www.perlmonks.org/?node_id=115511 for my original opinion when I read it. Nothing I've seen since has changed that basic option. (But wow, the technologies that I thought would go somewhere. It is humbling to see how wrong I was. But the points are still good.)

Now years later consider carefully that the "failure" that Joel criticized is what lead to Mozilla, Firefox, and the second browser wars. Furthermore consider that Netscape had no real choice with its rewrite. As a company they were going to die. Hence their effort to open source the code. But they didn't have licenses to everything in their browser, therefore the open source version couldn't even run!

Now I'll grant that the decision to rewrite working production code is always to be undertaken carefully. It can easily go wrong. But in this case Dropbox decided to do it, they've done it, they've had no ill consequences (the lack of consequences is not an accident - they knew how to do it well), and they are more than satisfied with the result. Given those facts it would probably be a good idea for you to be taking notes and asking yourself how come your immediate prediction turned out wrong instead of saying, "They were stupid to try that."

I've mentioned this on HN already but despite the fact that I agree with Joel about many things, I really hate when people pull that article out of their hat like it is some sort of debate ender.

Netscape was already fucked prior to starting the rewrite, mostly due to their ill-conceived forays into "groupware".

If Navigator wasn't rewritten when it was the layout engine from the rewrite wouldn't have existed to power Firefox and Mozilla probably wouldn't exist as an entity right now. So in a very indirect way, the Netscape rewrite actually saved the Netscape browser lineage and probably helped the web from falling into a much longer mini-dark-ages than it did around the NS/IE 5-6 era. And there's not really any good evidence that it did the old "Netscape" any harm since it isn't like Navigator was ever a significant profit center anyway (I know they did charge for corporate usage of Navigator, but that was never going to be a sustainable business, so the rewrite had no impact on that).

If they really rewrote it in a week, then either it was trivial or they were able to reuse the bulk of it. The Spoelsky article applies to neither of those cases.

Read the article. Their first step was to run their existing JavaScript through a js2coffeescript converter.

In C++'s defense in the one example you gave, you could have just done this and had the same amount of code:

   if (map.find(x) != map.end()) {
   }

No, because then I would need to find it again (eiter through the find() member function, or through operator[]) to get a reference to it. Without a reference, I can't process it.

Why? In your original example you said "process x". You can also "process x" in mine:

if (map.find(x) != map.end()) { // do stuff with x }

You don't need the iterator to do anything with x. And if you do need the iterator (to perhaps keep iterating or something?) then you would also need to do extra work in the JavaScript example.

> There was a cost, they paid it, now they can reap the benefits.

Quick example of how you're wrong: their version history is now trashed. They're going to pay the price for that for years.

And the price will be about zero.

> The Dropbox devs apparently didn't want to go through that learning curve

That's not a fair statement. I'm a competent js developer, having trudged up that curve, and I still love cs. Not for lack of learning, but because I value brevity and reduced keystrokes.

Yeah, I'm not anti-CoffeeScript, but from the article this sounds like a big reason why they switched, which is a perfectly valid reason.

I didn't come away with that impression - what sections of the article made you lean that way?

Ummm... i'm pretty sure that the devs over at DropBox know their JavaScript inside and out. These "rules to master" are in no way complex to understand.

First, it's not a matter of just learning to do something and moving on. There is incremental mental baggage that comes with every one of these "tricks". Since we are both Javascript developers, I won't list any, but I think we both know that some of the things you need to remember to do go beyond adding an additional equals sign. The sum of this is you can often find yourself falling into one of these traps, even after many years of experience, because there are just so many places you can be tripped up.

Second, I'm going to disagree with you on having a polygot codebase. If the developers decided that CoffeeScript is a better environment than Javascript (which you may disagree with), then I think it's clear the ideal scenario for them is their entire codebase is in a single language. Since it was tractable for them to convert the existing code, it seems logical to do that (not withstanding concerns like version control history, etc, which seems like an academic concern not really that important in practice.)

In fact, converting an existing code base is a common way to learn CoffeeScript and come to a judgement if it is suitable for future development. Such seems to have been the case here.

Some people seem to enjoy more hacking than doing what makes business sense.

Every hour spent converting JavaScript to CoffeeScript code, could have been spent improving Dropbox.

Doing the math of salary per hour that each Dropbox coder involved in such conversion earns, what is the cost of converting the code to CoffeeScript?

Developers aren't machines. "What should we work on today?" should not always be calculated as a function of "what provides the most immediate business value." Happy developers attempt harder problems, don't leave their current job to go work on $shiny_thing, and think about their latest project in the shower. All of which are of significant benefit to Dropbox.

That's not to say that you can't lose a lot of money refactoring working code — I dislike rewrites, they always cause unforeseen problems. But great software isn't a function of how many hours you've put into it. It's a complex result of developer morale, time, energy, experience, and skills, and there's a huge benefit to "hey I can think in a language that makes sense to me, instead of remembering weird bugs I have to work around." It's thinking on a higher plane. It lets you more easily load the program into your head. [1] And it can be all the difference if you want a truly exceptional product. [2]

[1] http://www.paulgraham.com/head.html

[2] http://www.paulgraham.com/power.html

In this specific situation, the conversion was done as part of a Dropbox hackweek.

There are almost certainly other projects they could have worked on for that week that would have resulted in a more tangible business gain for Dropbox as a company, but the point of teamwide hackweeks/hackathons/etc is more employee morale than anything else. It seems to me that it succeeded pretty well at that goal.

Rewriting working production code is not something to be done for fun at a hackweek. It's a very serious thing. And since it took a week they had a significant amount of code to rewrite.

What new bugs were introduced by the rewrite? Did they open the door to any XSS attacks? Who knows.

You really seem to be on a crusade to convince people that this was a reckless, short-sighted, waste of time. Clearly these developers are professionals because they went into detail how they prevented regressions. I wouldn't be surprised if they inadvertently fixed a number of bugs due to the fact those bugs are impossible to make in CoffeeScript, or because they filled in gaps in their test coverage.

Porting JS code to CoffeeScript is not very hard to do safely. I've done it myself for fairly large pieces of code (not this big.) In this case, it was for a hack week project and was a modest amount of code. It sounds like they got buy-in from the rest of the team that using CoffeeScript is a net win. It sounds like they are moving forward, it was a good decision and use of time, and they are happy with the result. Why do you think you can make arguments that it is in fact not any of these things, when the people who did it are stating otherwise, and the organization is acting otherwise? Why do you think you can make arguments against re-writes that suggest avoiding them because they never ship, when this project has, in fact, shipped, and did so in a week? Either you are missing something, or Dropbox is deluding themselves and are just falling for hype. What do you think is more likely?

Did you read the article? A lot of that week was spent testing that there were no regressions in the code, and not actually rewriting.

I'd be comfortable that no new attack vectors were opened.

Upgrading to CoffeeScript is an investment. In my experience, it's a low-risk and fairly high-reward one. A sensible investment which many have a hard time identifying.

The authors' arguments were correct and showed an understanding of their tools' histories.

If you're unable to deal with broken, buggy, or poorly designed things, that makes you a bad developer.

Just deal with it and move on. It's really not worth trying to achieve some sort of "Wow I love this language the best it's brilliant" state. It's far better to achieve a "I'm creating some cool stuff that solves a problem" state.

Language syntax is simply not very important. Every single language has quirks. Learn them, and move on.

If you're unhappy working in a particular language, maybe you're not cut out to be a software developer. You should be happy you're creating things that solve problems - if you're not, reconsider your career choice.

Nice false dichotomy you got there.

I'm just saying... Good developers concentrate on building things. Bad developers concentrate on how much they like their tools.

You see it in everything in life though. The best way to become a fantastic cyclist say, isn't to buy the best bike out there. It's to buy a crappy cheap bike, and learn how to get the most out of it.

That's a curious metaphor, because the best cyclists - the ones who win professional races - have very expensive bikes.

Seriously... if I were to pick something I'd pick music. Miles Davis on a $100 trumpet could make better music than almost anyone else with a $10k one.

That's still missing the key element. While people who are the best at something (cycling, trumpet, archery, programming) could outperform 99.999% of the population using crappy tools, that's not the point. They don't compete against 99.999% of the population. They compete against the 0.001% of the population who are their peers. And at that level of competition - when everyone is so good, and the margins of victory so slim - they use the best tools they can find.

I suppose that's true in situations where there is a significant advantage to being 1st over third or just being in those top percentiles. Splitting hairs over a topic I didn't disagree with you on from 24 hours ago, but I'd say that sorta breaks the metaphor for this particular situation. There isn't really an advantage to being the world's greatest programmer vs the world's top 1% of programmers. When you get to that level it's all gravy.

Which makes me realize I have no idea who the world's best programmer is.

Also Brian May (Queen) built his own guitar with his dad. I'm sure it's not the best guitar out there, but he learnt how to play it pretty well.

You're missing the point. They didn't learn on the best bikes.

So? We're talking about professional developers, not students.

Yes, and at some point in your development of competence you become hindered by bad tools. Otherwise we would not be using debuggers, high-level languages, big monitors, or anything beyond a simple text editor and console.

The danger is when you become obsessed by your tools.

For example, obsessing over the use of a semi-colon to signify the end of a statement in your language syntax.

Call me obsessed with my pinkies hitting all those semi-colons and curly braces. As if return and backspace weren't enough of a cruel joke.

In other words, why would anyone use Emacs?

"Good developers concentrate on building things. Bad developers concentrate on how much they like their tools."

serious lol

The best way to become a fantastic cyclist is to cycle a whole heck of a lot. Buying a good or bad bike doesn't make you a good cyclist. But having a good bike can help you enjoy cycling more, and make you a better cyclist by virtue of the fact that you do it more often as a result.

And then to buy a better bike.

This is like saying people should avoid jquery because everything jquery does can be done with javascript. Some of us enjoy the convenience of not dealing with hacks.

Can you give an example of a javascript hack that you have to deal with?

I don't like having to manually check for globals. Other people's code tends to be loaded with missing 'vars'.

CoffeeScript won't fix other people's code for you.

It does fix that specific issue.

so does jslint...

Regarding missing vars, JSLint will alert you that you've made a mistake, Coffeescript prevents it from happening in the first place, not quite apples to apples.

Dealing with inconsistent API's across browsers.

CoffeeScript can't help you there.

It can and does. Coffeescript will never write:

["dog","cat"].forEach(function(animal){ console.log(animal) });

Which will run just fine on your development browser, but will break for real customers.

FYI, I don't use coffeescript, but I am at least aware of some problems with Javascript.

CoffeeScript will write that if you tell it to:

[1, 2].forEach (i) => alert i

Array.prototype.forEach and friends are trivial to shim and shouldn't be broken for anybody.

But jQuery can. Which was the argument.

jquery improves the crappy DOM API and its vendor inconsistencies, not javascript the language. if anything improves javascript in terms of syntax, it's underscore/lodash or coffeescript.

"Dealing with it" adds cognitive load. Both when programming, and when reading code others wrote, or you wrote a while ago. Eliminating that cognitive load may (note, again, I said "may", not "will") be worth it.

I like it that it partially solves the callback hell problem - at least you don't have to routinely align/indent closing }); }; )}; ); }); etc...

Everything else, like being easier on the eyes, having built-in classes, not having to spell "function" a million times, etc, is a welcome bonus.

Seriously. You're doing it all wrong if you're lost in the callback hell.

Honestly, it makes it much worse for me. With brackets, I can place my cursor over the end one and my editor highlights the beginning one. While I'm coding that lets me double-check where I am while I'm working inside a callback.

There is a good reason: If they offered me a job and it was in JS I wouldn't take it. If they offered it in CoffeeScript: I would probably say yes.

But how many are the reverse? I'd wager a lot, given the number of people out there that code in JS vs CS.

I refuse to use CoffeeScript and I avoid using libraries that are written in the language.

This is what I was thinking. Convert to CS and then struggle to find developers in a few years when the guys that's thought this was a great idea have moved onto the next big thing.

Honestly I've been hearing this argument about CoffeeScript for what feels like a long time. I don't think it's going anywhere.

CoffeeScript is only two years old. It hasn't been around for a "long time".

Well the industry does tend toward standards for a reason.

except you'd still be touching JS every single day during debugging... what nonsense. CS is a preprocessor, hardly a language.

Linting provides the same benefits with more edification instead of sweeping language nuance under the rug.

Reply on news.ycombinator.com