12 ms·

Are TypeSscript and CoffeeScript really that much different? From what I understood, they both basically solve the same problems, one just does it in a Ruby-es

by k3n 13y ago

Are TypeSscript and CoffeeScript really that much different? From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.

clone1018 13y ago
While it's not my opinion, I did read this quote somewhere: "CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"
- icedog 13y ago
  If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.
  - kybernetikos 13y ago
    If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative. I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice. As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer. Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
    - awj 13y ago
      I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.
      - kybernetikos 13y ago
        I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous. The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections. Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
    - lowboy 13y ago
      Transparent and instantaneous is my experience using grunt to watch and compile CS. It will only compile the changed file, not the entire codebase. It seems to happen instantaneously for me on file save, or at least within the time it takes for me to switch from my editor to my browser.
agilebyte 13y ago
CS is aimed at making you more productive, TS is aimed at making you more correct, checking errors early. Just my observation.
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.
ahoge 13y ago
>[TS and CS] both basically solve the same problems TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation. TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.
- lowboy 13y ago
  CS also saves keystrokes and makes code more readable by offering things such as: Reducing boilerplate for loop code: CS: for el, index in arr el.doThing(index) JS: for(var index=0; index < arr.length; index++) { var el = arr[index]; el.doThing(index); } Better iteration over objects: CS: for own k, v of obj console.log "#{k} is #{v}" JS: for(k in obj) { if(!obj.hasOwnProperty(k)) continue; console.log(k + " is " + obj[k]); } Default function params: CS: foobar = (foo = "default", bar = "shmefault") -> # Go on... JS: function foobar(foo,bar) { if(foo === null) foo = "default" if(bar === null) bar = "shmefault"; // Go on... } String interpolation: CS: str = "There are #{num} #{item}s available for $#{price} each" JS: str = "There are " + num + " " + item + "s available for $" + price + " each"; Existential checks, soaking nulls: CS: if obj?.prop?.exists? console.log "obj.prop.exists" JS: if(typeof obj !== "undefined" && obj != null && obj.prop != null && obj.prop.exists != null) console.log("obj.prop.exists")
  - ahoge 13y ago
    Yes, but that's just some syntactic sugar. That stuff doesn't help with tooling/scaling. By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.
    - luikore 13y ago
      Language is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool. CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling. In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely. If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.

by k3n 13y ago

clone1018 13y ago

While it's not my opinion, I did read this quote somewhere: "CoffeeScript is only syntactic sugar. It brings very little new to the table, but perhaps worse of all, it doesn't really fix all of JavaScript's WTF-issues while adding a few of its own. While it's an improvement over JavaScript, its advantages are sometimes outweighed by the extra hassle to compile and deploy it"

icedog 13y ago
If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.
- kybernetikos 13y ago
  If you have to introduce a build sequence to move to coffeescript then moving to coffeescript is definitely a net negative. I work on a >300k line JS codebase, and our tooling means you can make a change and hit f5 and you always get the latest version of the code. No file watching latency, no run-an-external-tool latency. We /could/ do the auto-reload thing, except that I think that for large applications with lots of state, that's probably the wrong choice. As far as I'm concerned visible 'builds' are the enemy to development. They take you out of your mental context, and in the worst case make even the tiniest changes painful. I've got nothing against pipelines of tasks, so long as the whole thing runs in milliseconds and is transparent to the developer. Obviously, you can do more on an occasional basis, perhaps before check in, and certainly in CI, but we need to reduce friction, and unnecessary build steps in environments that don't need them is a whole heap of friction.
  - awj 13y ago
    I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.
    - kybernetikos 13y ago
      I'm not sure what you mean by 'all at once', since rather obviously not all of those lines of code are running at once. The 'S' in SLOC does not stand for simultaneous. The application has been continuously developed for nearly 10 years now, and small parts of the current codebase are 5 years old. A little while ago, I was very pleased to find and remove some code that was weird in order to work in IE4, but these days I'm enjoying removing IE6 and IE7 specific code. IE8 is the last non es5 browser we have to support and it's painful. The whole application runs in the browser, and connects to services it needs via streaming connections. Once you take into account the fact that it's not just a couple of pretty forms for a back end application, plus the fact that in the browser you have to write things that come as standard in many other environments, plus the fact that you used to have to write extra code to work on different browsers, plus the fact that the javascript ecosystem was not up to the task back then so lots of things that would be generic now had to be written in house, plus the fact that it's extremely well tested both with unit tests, acceptance tests and integration tests, then a large codebase is really not all that surprising.
  - lowboy 13y ago
    Transparent and instantaneous is my experience using grunt to watch and compile CS. It will only compile the changed file, not the entire codebase. It seems to happen instantaneously for me on file save, or at least within the time it takes for me to switch from my editor to my browser.

agilebyte 13y ago

CS is aimed at making you more productive, TS is aimed at making you more correct, checking errors early. Just my observation.

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.

ahoge 13y ago

>[TS and CS] both basically solve the same problems TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation. TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.

lowboy 13y ago
CS also saves keystrokes and makes code more readable by offering things such as: Reducing boilerplate for loop code: CS: for el, index in arr el.doThing(index) JS: for(var index=0; index < arr.length; index++) { var el = arr[index]; el.doThing(index); } Better iteration over objects: CS: for own k, v of obj console.log "#{k} is #{v}" JS: for(k in obj) { if(!obj.hasOwnProperty(k)) continue; console.log(k + " is " + obj[k]); } Default function params: CS: foobar = (foo = "default", bar = "shmefault") -> # Go on... JS: function foobar(foo,bar) { if(foo === null) foo = "default" if(bar === null) bar = "shmefault"; // Go on... } String interpolation: CS: str = "There are #{num} #{item}s available for $#{price} each" JS: str = "There are " + num + " " + item + "s available for $" + price + " each"; Existential checks, soaking nulls: CS: if obj?.prop?.exists? console.log "obj.prop.exists" JS: if(typeof obj !== "undefined" && obj != null && obj.prop != null && obj.prop.exists != null) console.log("obj.prop.exists")
- ahoge 13y ago
  Yes, but that's just some syntactic sugar. That stuff doesn't help with tooling/scaling. By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.
  - luikore 13y ago
    Language is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool. CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling. In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely. If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.