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

51–60 of 93 posts

Re: TypeScript and the Road to 1.0

#51

Post by kybernetikos »

icedog wrote: post #24
clone1018 wrote: post #16

Earlier quoted context omitted.

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"

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

Re: TypeScript and the Road to 1.0

#52

Post by xtrumanx »

chrisoakman wrote: post #14
xtrumanx wrote: post #7

Earlier quoted context omitted.

> ...also we added the class keyword so you don't feel lost I believe EcmaScript 6 plans on adding the class keyword and TypeScript's implementation reflects the current draft of how classes in ES6 will work. > ...statically typed languages make it easier to think about your program... Out of curiosity, do you normally program using statically typed languages? If not, I can see why you would be underwhelmed. Then aga…

Not a huge fan of the class keyword in ES6 either... I do not use statically typed languages and I have nothing against MSFT; I was solely commenting on TypeScript as a language.

Sorry about my Microsoft remark. It was kind of inflammatory. I didn't originally have it in my comment but was inspired to add it in for some reason. I try to keep my inflammatory rhetoric out of HN.

TypeScript's best feature (imo) is its (optional) static-typing so if you don't like static-typing to begin with, then yeah, it doesn't have much else to offer you.

To each his own.

Re: TypeScript and the Road to 1.0

#53

Post by lowboy »

ahoge wrote: post #45
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.

> [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", 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")

Re: TypeScript and the Road to 1.0

#54

Post by xtrumanx »

Touche wrote: post #21
sanxiyn wrote: post #15

Earlier quoted context omitted.

Well, value proposition is error messages and code completion, not "make it easier to think about your program". You may argue types don't help people much, but types do help tooling. (Not in the sense being untyped causes some tooling impossible, but in the sense being typed substantially reduces tooling implementation effort.)

This. TypeScript is a tool to sell Visual Studio, nothing more. If people are leaving VS because it can't do the magic things to JavaScript that it can to C# that's a big thread to Microsoft. TypeScript is about protecting the thing that makes them money.

> TypeScript is a tool to sell Visual Studio, nothing more.

I'll have you know I paid for my WebStorm license because of its TypeScript support =)

Re: TypeScript and the Road to 1.0

#55

Post by ahoge »

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…

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.

Re: TypeScript and the Road to 1.0

#56

Post by mgkimsal »

Touche wrote: post #48
randomhunt wrote: post #47

Earlier quoted context omitted.

Nope, and incidentally its not the same thing you originally said at all productively You missed the most important word. As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Product…

You're wrong, it can be done productively, the evidence is the thousands (tens of thousands?) of such apps that exist on the web, most of which were written in regular JavaScript.

You don't know how productive those developers were on those projects, nor do you know if TS would have made those developers more productive. Granted, the original claim wasn't comparative, but that's the point I'll make anyway.

Re: TypeScript and the Road to 1.0

#57

Post by laureny »

jeswin wrote: post #10

Does optional typing really work? I've always felt (or presumed) that once you start putting types in, it kinda starts spreading everywhere and eventually will look like full static typing. I'd rather have tests than types. It is good to see people try different things though, so congrats on release.

> I'd rather have tests than types.

False dichotomy.

You want both and you need both.

Re: TypeScript and the Road to 1.0

#58

Post by [deleted] »

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…

[deleted]

Re: TypeScript and the Road to 1.0

#59

Post by awj »

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…

I'd be really interested to see what you're doing that uses >300k lines of javascript all at once.

Re: TypeScript and the Road to 1.0

#60

Post by Touche »

mgkimsal wrote: post #56
Touche wrote: post #48

Earlier quoted context omitted.

You're wrong, it can be done productively, the evidence is the thousands (tens of thousands?) of such apps that exist on the web, most of which were written in regular JavaScript.

You don't know how productive those developers were on those projects, nor do you know if TS would have made those developers more productive. Granted, the original claim wasn't comparative, but that's the point I'll make anyway.

Interesting theory, let's see how it plays out in the marketplace. If typed languages are indeed more productive we should see them start to win out in, say NPM, right? Today the overwhelming majority of NPM modules are JavaScript, but if the same modules can be written more productively in TypeScript or Dart or another typed alternative, you should start to see those modules win out. Fewer bugs, more able to concentrate on features.
Post reply on HN