CoffeeScript or plain JavaScript? [closed]

Question

when the average ASP.net C# programmer (with very poor JavaScript knowledge other than scripting some hide() show() effects) would have to switch from building ASP.net WebForms apps to a RIA JavaScript application (client-server architecture like).

What would probably be less pain for him:

• Learn CoffeeScript and use it for "coding JavaScript"??
• Properly learn JavaScript and use that directly??

I'm thinking about

• Proper debugging
• Coding syntax
• ...

Does anyone have experiences in a similar scenario??

Answer 1

TL;DR: The best thing to do is Learn JavaScript.

Books:

• JavaScript: The Good Parts
• CoffeeScript: Smooth CoffeeScript

Cutting Corners:

If you want to cut corners / have dead lines to hit look at Script# or other C# -> JS compilers.

On CoffeeScript:

However I disagree with @jAndy on parts. I believe CoffeeScript is stable enough to use.

You could learn from which doesn't require JavaScript knowledge.

If you like the coffeescript use it. I prefer the JavaScript syntax so I use that.

Learning RIA:

I personally find that CoffeeScript vs JS is a matter of preference, you still have to learn HTML/CSS/DOM.

There is a lot more to RIA development then just knowing JavaScript.

Problems with CoffeeScript:

However there is a big problem with not learning JavaScript, Debugging coffeescript means debugging auto generated JavaScript and that is a pain if you have no knowledge.

Personal Recommendation: Learn ES5. Debugging without JS knowledge is a nightmare.

JavaScript is not a bad language:

Some people think JS is a horrible language, this reasons for this are mediocre implementations of ES3. But EcmaScript5 is a solid and lovely language. People confuse Browser compliance and browser bugs with the language. I'd personally be tempted to say learning ES5 is nicer then learning CS

Answer 2

I'm the author of CoffeeScript: Accelerated JavaScript Development, which is just coming out in print. The approach I took in writing that book—in contrast to Smooth CoffeeScript, which others in this thread have mentioned—is that I try to teach readers both CoffeeScript and JavaScript. My opinion on the "Which should I learn?" question has always been: You shouldn't learn CoffeeScript without learning JavaScript.

Debugging is one good, and obvious, reason to understand JavaScript. A less obvious reason is that as a CoffeeScript developer in the real world, you'll be relying on JavaScript libraries (like jQuery). You need to be able to understand the documentation for those libraries (and ideally, their source code).

The good news is that the two languages are very, very close to each other. CoffeeScript has no standard library of its own; it doesn't modify prototypes; and output is in the same order as input (except for very minor exceptions like being able to write f() if x instead of if x then f()). So if you already have a little JavaScript knowledge—if you're one of the many developers who doesn't entirely understand what this means, or how prototypal inheritance works—then I think you should start learning CoffeeScript. Along the way, you'll become a better JavaScripter.

Think of CoffeeScript and JavaScript as two dialects of the same language. Achieve fluency in one, and you'll find that the other comes naturally.

Answer 3

We had a pretty long discussion about that topic in the Stackoverflow Javascript Chat over the past days. General conclusion was, that CoffeeScript is a nice tool which might create "ok" javascript code. However, if you know what you're doing you probably want to code directly in javascript without a 'higher level' language which semi compiles down to it.

I'm not really experienced with CoffeeScript so if I'm saying something wrong I'd be happy to get corrected. For instance, I can't tell how CoffeeScript reacts on ECMAscript3 to 5 (maybe even to 6) differences. Does CoffeeScript automatically create fallback code for each or does it just produce ES3 code ?

All those questions and doubts are one reason for me to go with plain Javascript as far as possible. If you not care so much whats going on under the hood and you need quick results, it's probably a good way to go.