4 ms·

I use CoffeeScript in my day job for the last 2 years. I've been using TypeScript in my startup the last 6 months. They are definitely not the same. TypeScrip

by judah 13y ago

I use CoffeeScript in my day job for the last 2 years. I've been using TypeScript in my startup the last 6 months. They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.) CoffeeScript tries to do clever things for you, which often results in inefficient code. For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array. (Looping over 1000 elements at the end of a function? CS just allocated a new array which will be dynamically resized at runtime multiple times, allocated 1000 buckets for the elements.) CoffeeScript also can't make up its mind about whether parens are necessary. Function with multiple params? Not necessary. Chained function, like jQuery? Necessary. Most of the time. Function with no params? Necessary, unless you use the 'do' syntax. It's a mess. TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through. Bottom line: Both are better than vanilla JS, I'd say. But I work with CoffeeScript when I have to. I work with TypeScript because I choose to.

k3n 13y ago
I guess I should have phrased it better -- that both are basically trying to "improve" upon perceived faults in vanilla JS, as well as adding perceived useful functionality. It's just that "improve" and "useful" is an implementation-specific definition that's defined by the particular project owners. Thanks for the thorough info though, I've only used TS a little and CS none at all, though from what I've seen I'd side with you in that CS tries to be too clever and/or is too foreign for my non-Ruby brain, whereas TS more closely melds with my skillset.
lowboy 13y ago
> For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array. Simple, just return anything else, or nothing at all: myFn = () -> for el of array # loop body return > CoffeeScript also can't make up its mind about whether parens are necessary. Well, in some cases they're optional, but it's predictable and hardly "can't make up its mind". I've never run into a problem with this. Implicit parens wrap to the end of a line or block expression, and it feels pretty natural: f g h obj -> f(g(h(obj))) f g, h, obj -> f(g, h, obj) f().g().h obj -> f().g().h(obj) Every time there's a space, you're introducing a new fn call. Every time there's a comma, it's adding a parameter to the fn call. So yeah, you will have to use parens for any chaining style (a la jQ and many others), and to disambiguate complex nested fn calls, but that's expected. I prefer to think of parens as sometimes optional.
c0achmcguirk 13y ago
I've used both extensively and I'd disagree with you on almost every point. > For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. This myth won't die. False. Typescript will choke on most JavaScript files from the web. Because you will need to include definition files for any external library calls. If you use jQuery, for example, the compiler won't like your $('.class').doStuff() calls because it won't recognize it until you go find the jquery.d.ts file to include at the top of your file. Also, TypeScript will struggle with the dynamic-ness of JavaScript. To prove this to yourself, paste the contents of typeface.js into the play compiler at www.typescriptlang.org/Playground/ and you'll see all the red squigglies that you have to fix. On the other hand, if you can do it in JavaScript, you can do it in CoffeeScript, because CS is NOT statically typed. You can use js2coffee to convert any valid JS on the web to coffeescript. In my testing it takes me 25 times longer to take legacy code and convert it to TypeScript than to convert it to CoffeeScript. That's because "valid JavaScript is NOT valid TypeScript." > CoffeeScript tries to do clever things for you, which often results in inefficient code. I find that CoffeeScript's results are BETTER than the TypeScript code. For example, CoffeeScript automatically does array length caching in it's for loops, resulting in much faster loops. It also correctly converts == to === in comparisons, eliminating many nasty JavaScript bugs. TypeScript does neither. In my analysis, TypeScript generates poorer code than CoffeeScript. > CoffeeScript also can't make up its mind about whether parens are necessary. Use them all the time if you want, CS isn't dogmatic about it. EcmaScript 6 (and TypeScript too) will be moving toward optional parentheses too. It's a nice feature. > TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through. Anders has done a fine job of making TypeScript look like C#. It's one redeeming trait is that it helps the tooling for allowing refactoring and intellisense. I find it cumbersome and you have to put a lot of ceremony into your code just to get it working. It is roughly 35% more lines of code to do the same thing in TypeScript that you could do in CoffeeScript, and you are fighting the compiler more often. I think TypeScript would be an incredible burden for enterprise applications because of the need to include definition files. Think of the joys of upgrading your version of jQuery and having to find the jquery.d.ts file to go with it. I recently presented a talk at a conference on the two languages and after evaluating both languages in depth, CoffeeScript was the clear winner. Both in the code it produces, but also the amount of effort to develop in it.

by judah 13y ago

k3n 13y ago

I guess I should have phrased it better -- that both are basically trying to "improve" upon perceived faults in vanilla JS, as well as adding perceived useful functionality. It's just that "improve" and "useful" is an implementation-specific definition that's defined by the particular project owners. Thanks for the thorough info though, I've only used TS a little and CS none at all, though from what I've seen I'd side with you in that CS tries to be too clever and/or is too foreign for my non-Ruby brain, whereas TS more closely melds with my skillset.

lowboy 13y ago

> For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array. Simple, just return anything else, or nothing at all: myFn = () -> for el of array # loop body return > CoffeeScript also can't make up its mind about whether parens are necessary. Well, in some cases they're optional, but it's predictable and hardly "can't make up its mind". I've never run into a problem with this. Implicit parens wrap to the end of a line or block expression, and it feels pretty natural: f g h obj -> f(g(h(obj))) f g, h, obj -> f(g, h, obj) f().g().h obj -> f().g().h(obj) Every time there's a space, you're introducing a new fn call. Every time there's a comma, it's adding a parameter to the fn call. So yeah, you will have to use parens for any chaining style (a la jQ and many others), and to disambiguate complex nested fn calls, but that's expected. I prefer to think of parens as sometimes optional.

c0achmcguirk 13y ago

I've used both extensively and I'd disagree with you on almost every point. > For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. This myth won't die. False. Typescript will choke on most JavaScript files from the web. Because you will need to include definition files for any external library calls. If you use jQuery, for example, the compiler won't like your $('.class').doStuff() calls because it won't recognize it until you go find the jquery.d.ts file to include at the top of your file. Also, TypeScript will struggle with the dynamic-ness of JavaScript. To prove this to yourself, paste the contents of typeface.js into the play compiler at www.typescriptlang.org/Playground/ and you'll see all the red squigglies that you have to fix. On the other hand, if you can do it in JavaScript, you can do it in CoffeeScript, because CS is NOT statically typed. You can use js2coffee to convert any valid JS on the web to coffeescript. In my testing it takes me 25 times longer to take legacy code and convert it to TypeScript than to convert it to CoffeeScript. That's because "valid JavaScript is NOT valid TypeScript." > CoffeeScript tries to do clever things for you, which often results in inefficient code. I find that CoffeeScript's results are BETTER than the TypeScript code. For example, CoffeeScript automatically does array length caching in it's for loops, resulting in much faster loops. It also correctly converts == to === in comparisons, eliminating many nasty JavaScript bugs. TypeScript does neither. In my analysis, TypeScript generates poorer code than CoffeeScript. > CoffeeScript also can't make up its mind about whether parens are necessary. Use them all the time if you want, CS isn't dogmatic about it. EcmaScript 6 (and TypeScript too) will be moving toward optional parentheses too. It's a nice feature. > TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through. Anders has done a fine job of making TypeScript look like C#. It's one redeeming trait is that it helps the tooling for allowing refactoring and intellisense. I find it cumbersome and you have to put a lot of ceremony into your code just to get it working. It is roughly 35% more lines of code to do the same thing in TypeScript that you could do in CoffeeScript, and you are fighting the compiler more often. I think TypeScript would be an incredible burden for enterprise applications because of the need to include definition files. Think of the joys of upgrading your version of jQuery and having to find the jquery.d.ts file to go with it. I recently presented a talk at a conference on the two languages and after evaluating both languages in depth, CoffeeScript was the clear winner. Both in the code it produces, but also the amount of effort to develop in it.