Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript and the Road to 1.0

blogs.msdn.com

Post reply on HN
Print view View original

61–70 of 93 posts

Re: TypeScript and the Road to 1.0

#61

Post by luikore »

ahoge wrote: post #55
lowboy wrote: post #53

Earlier quoted context omitted.

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 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", b…

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.

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.

Re: TypeScript and the Road to 1.0

#62

Post by lowboy »

ahoge wrote: post #55
lowboy wrote: post #53

Earlier quoted context omitted.

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 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", b…

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.

It's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes.

That's awesome that Dart includes those features, and I wish that I had lexical scoping in CS. But closures are a pretty easy workaround.

> TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.

That sounds like an IDE/editor feature, not a language feature. Setting up macros/snippets/etc in an IDE/editor will save keystrokes for most any language.

Re: TypeScript and the Road to 1.0

#63

Post by ahoge »

lowboy wrote: post #62
ahoge wrote: post #55

Earlier quoted context omitted.

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.

It's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes. That's awesome that Dart includes those features, and I wish that I had lexical sco…

> That sounds like an IDE/editor feature, not a language feature.

Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.

Re: TypeScript and the Road to 1.0

#64

Post by ahoge »

luikore wrote: post #61
ahoge wrote: post #55

Earlier quoted context omitted.

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.

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…

> [JS generated from CS] runs faster [than JS generated from Dart]

There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good.

> it runs faster thus has its strength in scaling

"Scaling" as in: more developers, more files, more lines of code. Bigger projects.

CS doesn't help with that one bit. It's just as difficult to handle as JS. This is why Google came up with stuff like the Closure Compiler, GWT, and now Dart.

> Syntax is the only thing we can compare.

There are also semantics and the whole environment. Syntax is a small fairly unimportant detail.

Re: TypeScript and the Road to 1.0

#65

Post by c0achmcguirk »

judah wrote: post #36
k3n wrote: post #11

Earlier quoted context omitted.

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.

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…

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.

Re: TypeScript and the Road to 1.0

#66

Post by lowboy »

ahoge wrote: post #63
lowboy wrote: post #62

Earlier quoted context omitted.

It's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes. That's awesome that Dart includes those features, and I wish that I had lexical sco…

> That sounds like an IDE/editor feature, not a language feature. Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.

By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate).

CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I like JS, and I like that it doesn't try to shoehorn in concepts foreign to JS.

It's possible to build scalable systems in JS/CS without what TS/Dart offers. You might not be able to do so from your experience, but that doesn't mean it's not possible.

Re: TypeScript and the Road to 1.0

#67

Post by lowboy »

ahoge wrote: post #64
luikore wrote: post #61

Earlier quoted context omitted.

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…

> [JS generated from CS] runs faster [than JS generated from Dart] There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good. > it runs faster thus has its strength in scaling "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. Thi…

> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS.

Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or other features from TS/Dart.

Re: TypeScript and the Road to 1.0

#68

Post by L8D »

I think the one think that TypeScript needs to get it going is modularity. If another project like [harp](https://github.com/sintaxi/harp) could use TypeScript as a library and could compile the code without having to result to system commands would be a great thing.

However, I think if someone came up with a system to add optional typing through the use of string literals it would be awesome. That way we can have perfectly valid JavaScript with the benefits of certain JavaScript engines and type checkers. The string literal would be before a function declaration like:

    "add(Number, Number) -> Number";
    var add = function(x, y) { return x + y; };
That would basically specify that the function takes two numbers, and returns a number. This system would not replace a language like TypeScript, as TypeScript provides much more functionality. But it would allow for really simple optional typing and for TypeScript to take advantage of this(in the case that a JavaScript engine eventually implements and optimizes for these type declarations).

Re: TypeScript and the Road to 1.0

#69

Post by munificent »

lowboy wrote: post #53
ahoge wrote: post #45

Earlier quoted context omitted.

> [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.

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 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", b…

For kicks, here's Dart versions of those:

Reducing boilerplate for loop code:

    var index = 0;
    for (var el in arr) {
      el.doThing(index++);
    }
Dart hasn't really optimizing for iterating over a collection with indices since we don't find that very common in real-world code.

Better iteration over objects:

    obj.forEach((k, v) => print("$k is $v"));
Here, obj is a map data structure, not a random object since Dart distinguishes objects and data structures.

Default function params:

    foobar([foo = "default", bar = "shmefault") {
      // Go on...
    }
String interpolation:

    str = "There are $num ${item}s available for \$$price each"

Re: TypeScript and the Road to 1.0

#70

Post by lowboy »

kybernetikos wrote: post #51
icedog wrote: post #24

Earlier quoted context omitted.

If someone has trouble compiling coffeescript in a build sequence, then they have bigger troubles afoot. CS is well worth the switch.

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…

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.
Post reply on HN