5 ms·

I have never understood why anyone would bother with coffeescript. Afterall it just transpiles to javascript. If you know javascript what's the point in a new l

by boromi 13y ago

I have never understood why anyone would bother with coffeescript. Afterall it just transpiles to javascript. If you know javascript what's the point in a new language that offers nothing additional to javascript other than syntactic sugar. Not to mention the coffeescript's poor compiler design. To me typescript beats dart and coffeescript by miles. I don't have to use a new syntax or figure out the idiosyncrasies of a new language, it provides the type safety and tools that I need for javascript apps without reinventing the wheel in a very simple and intuitive form. It solves the problems that javascript doesn't, type-safety. In fact I can't recall another language that is dynamic but also statically typed.

virtualwhys 13y ago
Came across TypeScript last month, looks interesting. What are the limitations of the type checker? i.e. does the compiler fully have your back, or are we just talking validating whether or not a method param takes a String vs. an Int? Coffee is a dream [for me], JavaScript, not so much.
- michaelwww 13y ago
  I'm not sure what you mean by the compiler fully having your back, but it is fairly helpful. It does type inference, which means you don't have to explicitly type everything to get type checking help. You can do as little or as much type checking as you would like. Regular unadorned JavaScript code is TypeScript code and will compile. The compiler will tell you when not all code paths return a value, when the wrong type is passed to a function, when a return value is the wrong type, etc... It keeps track of the symbols in the source making refactoring work as you would expect. I really can't think of any downside since it's just JavaScript.
  - virtualwhys 13y ago
    By type inference I mean the compiler has your back ;-) If IDE support is getting to the point where you can hover-view/click-through to type, then that is really quite impressive. Will be awhile before that gets to MonoDevelop, however (Linux workstation here). For me the ideal would be a terse syntax a la coffeescript, but with static type checking. I wonder what compile times are like for large-ish TypeScript projects? Imagine it's fairly quick, but even simple static type checking will bring some overhead.
    - michaelwww 13y ago
      > If IDE support is getting to the point where you can hover-view/click-through to type, then that is really quite impressive. Like this? http://i.imgur.com/RRFq0dl.png http://i.imgur.com/RRFq0dl.png Compile times are easily control by breaking the files up. Similar to C# partial class, they can still go in the same module. I'm using the free Visual Studio Express for Web, so I'm not sure about Mono/Linux support, but I hear there is WebStorm and Sublime Text plugin support and one I also like which is Adobe Brackets.
- boromi 13y ago
  For all the cases I have checked the type checker is extremely impressive. I have even checked whether types flow through promises! and with underscore.js and it has not failed me yet, it is extremely robust. But aside from that, the most useful feature of typescript to me has been the productivity gains, just checkout: http://www.typescriptlang.org/Playground/ http://www.typescriptlang.org/Playground/ You can now have an IDE that provides useful information about clases/objects/etc. (imagine if javascript actually had proper codecompletion and intellisense)
michaelwww 13y ago
TypeScript is awesome. I tried Dart first and found I could bang out code much faster, but when you start to push the Dart team about JavaScript you soon realize they don't care much for JavaScript and really do want to replace it. I'm not ready to abandon JavaScript just yet. TypeScript adds type checking, code completion and easy refactoring to normal JavaScript code. It's all gain and no pain. I can only assume it's not taken off even stronger because it's from Microsoft.
- agilebyte 13y ago
  I would say type checking is one of the "pain". Do not get me wrong I use it so that it is clear to other os developers what the expected interfaces are, but absolutely cannot stand the current state of `d.ts` files for external libraries ending up fixing those and searching for different versions instead of focusing on my code.
  - michaelwww 13y ago
    I've had nothing but good experience with the definitley typed library https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped
    - agilebyte 13y ago
      I am glad you did. My first point of contention is the fact that there is only one version of a definition file for a library. I sometimes do not have the luxury of choosing just the version that they have in the repo.
danvk 13y ago
Any thoughts on Closure Compiler vs. typescript? One thing I like about Closure Compiler is that it lets you explicitly list the symbols you wish to export from your JS, which is a huge boon for code minification.
- michaelwww 13y ago
  Ideally TypeScript will honor the Closure source annotations like this http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html http://blog.bolinfest.com/2013/01/generating-google-closure-...
yojo 13y ago
I've been doing full time Coffeescript front end dev for about a year and a half on a moderately complex one page app. I would be happy to never write vanilla javascript again. The value of coffeescript is that when written well you can get a very high signal to noise ratio in your codebase. When I say "noise", I'm referring to low value syntax and boilerplate, things like: var someFunc, _this; _this = this; someFunc = function(){ return _this.foo; } By comparison, the coffeescript is: someFunc = => @.foo In the coffeescript example, it is immediately obvious what 'someFunc' does. A trained javascript developer will be good at filtering the junk, and extracting the bits that are actually meaningful and important. But any time you are parsing through a bunch of junk to get to the meaningful stuff, you are opening the door to make mistakes, and increasing the time it takes to comprehend/load the code into your brain. Another important benefit of readable & concise code is that you can hold more of it on a screen at a time, which makes it easier to keep a full class in context and/or work on a small screen (e.g. laptop on the go). I would much rather work with a 100 line coffeescript file than a 300 line javascript file. This is the same reason I really love the underscore library (not coincidentally also an Ashkenas product). Everything it does is something any competent JS developer can do. But it does it in one line, and in a way that is very easy to read. Incidentally, using a library like underscore with good iterators also avoids a common class of the "variable capturing" problem, as you don't end up using named variables for iteration (opting instead for map/reduce/find/etc). We otherwise use descriptive names in our project, so the chance of a clash is minimal. In my year and a half on the project, I've yet to run into a "variable capturing" bug. Admittedly that does mean that when it finally happens, I probably won't be looking for it.

by boromi 13y ago

virtualwhys 13y ago

Came across TypeScript last month, looks interesting. What are the limitations of the type checker? i.e. does the compiler fully have your back, or are we just talking validating whether or not a method param takes a String vs. an Int? Coffee is a dream [for me], JavaScript, not so much.

michaelwww 13y ago
I'm not sure what you mean by the compiler fully having your back, but it is fairly helpful. It does type inference, which means you don't have to explicitly type everything to get type checking help. You can do as little or as much type checking as you would like. Regular unadorned JavaScript code is TypeScript code and will compile. The compiler will tell you when not all code paths return a value, when the wrong type is passed to a function, when a return value is the wrong type, etc... It keeps track of the symbols in the source making refactoring work as you would expect. I really can't think of any downside since it's just JavaScript.
- virtualwhys 13y ago
  By type inference I mean the compiler has your back ;-) If IDE support is getting to the point where you can hover-view/click-through to type, then that is really quite impressive. Will be awhile before that gets to MonoDevelop, however (Linux workstation here). For me the ideal would be a terse syntax a la coffeescript, but with static type checking. I wonder what compile times are like for large-ish TypeScript projects? Imagine it's fairly quick, but even simple static type checking will bring some overhead.
  - michaelwww 13y ago
    > If IDE support is getting to the point where you can hover-view/click-through to type, then that is really quite impressive. Like this? http://i.imgur.com/RRFq0dl.png http://i.imgur.com/RRFq0dl.png Compile times are easily control by breaking the files up. Similar to C# partial class, they can still go in the same module. I'm using the free Visual Studio Express for Web, so I'm not sure about Mono/Linux support, but I hear there is WebStorm and Sublime Text plugin support and one I also like which is Adobe Brackets.
boromi 13y ago
For all the cases I have checked the type checker is extremely impressive. I have even checked whether types flow through promises! and with underscore.js and it has not failed me yet, it is extremely robust. But aside from that, the most useful feature of typescript to me has been the productivity gains, just checkout: http://www.typescriptlang.org/Playground/ http://www.typescriptlang.org/Playground/ You can now have an IDE that provides useful information about clases/objects/etc. (imagine if javascript actually had proper codecompletion and intellisense)

michaelwww 13y ago

TypeScript is awesome. I tried Dart first and found I could bang out code much faster, but when you start to push the Dart team about JavaScript you soon realize they don't care much for JavaScript and really do want to replace it. I'm not ready to abandon JavaScript just yet. TypeScript adds type checking, code completion and easy refactoring to normal JavaScript code. It's all gain and no pain. I can only assume it's not taken off even stronger because it's from Microsoft.

agilebyte 13y ago
I would say type checking is one of the "pain". Do not get me wrong I use it so that it is clear to other os developers what the expected interfaces are, but absolutely cannot stand the current state of `d.ts` files for external libraries ending up fixing those and searching for different versions instead of focusing on my code.
- michaelwww 13y ago
  I've had nothing but good experience with the definitley typed library https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped
  - agilebyte 13y ago
    I am glad you did. My first point of contention is the fact that there is only one version of a definition file for a library. I sometimes do not have the luxury of choosing just the version that they have in the repo.

danvk 13y ago

Any thoughts on Closure Compiler vs. typescript? One thing I like about Closure Compiler is that it lets you explicitly list the symbols you wish to export from your JS, which is a huge boon for code minification.

michaelwww 13y ago
Ideally TypeScript will honor the Closure source annotations like this http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html http://blog.bolinfest.com/2013/01/generating-google-closure-...

yojo 13y ago

I've been doing full time Coffeescript front end dev for about a year and a half on a moderately complex one page app. I would be happy to never write vanilla javascript again. The value of coffeescript is that when written well you can get a very high signal to noise ratio in your codebase. When I say "noise", I'm referring to low value syntax and boilerplate, things like: var someFunc, _this; _this = this; someFunc = function(){ return _this.foo; } By comparison, the coffeescript is: someFunc = => @.foo In the coffeescript example, it is immediately obvious what 'someFunc' does. A trained javascript developer will be good at filtering the junk, and extracting the bits that are actually meaningful and important. But any time you are parsing through a bunch of junk to get to the meaningful stuff, you are opening the door to make mistakes, and increasing the time it takes to comprehend/load the code into your brain. Another important benefit of readable & concise code is that you can hold more of it on a screen at a time, which makes it easier to keep a full class in context and/or work on a small screen (e.g. laptop on the go). I would much rather work with a 100 line coffeescript file than a 300 line javascript file. This is the same reason I really love the underscore library (not coincidentally also an Ashkenas product). Everything it does is something any competent JS developer can do. But it does it in one line, and in a way that is very easy to read. Incidentally, using a library like underscore with good iterators also avoids a common class of the "variable capturing" problem, as you don't end up using named variables for iteration (opting instead for map/reduce/find/etc). We otherwise use descriptive names in our project, so the chance of a clash is minimal. In my year and a half on the project, I've yet to run into a "variable capturing" bug. Admittedly that does mean that when it finally happens, I probably won't be looking for it.