12 ms·

TypeScript and the Road to 1.0

112 points by smokel 13y ago

clone1018 13y ago
I really love TypeScript because one of the projects goals is to become redundant one day. They're building what they hope JavaScript will get to evolve into.
- haxorize 13y ago
  That's not entirely true. While TypeScript is closely aligning itself with the proposed ES6 syntax for classes and modules, there is no expectation that ECMAScript will add optional static type checking. If you want statically typed JavaScript you are always going to need something like TypeScript. With that said, as ES6 evolves and becomes more widely supported there will be aspects of the TypeScript compiler that will no longer be needed (e.g. classes, modules, fat arrow functions, etc.).
  - k3n 13y ago
    > If you want statically typed JavaScript you are always going to need something like TypeScript. I think that is a valid statement only within the context of the next ECMA release. In other words, that's not to say that whichever successive version after ES6 can't include it, or any version thereafter.
    - jeswin 13y ago
      You could make that argument about any missing feature. I haven't seen any serious support for optional typing in JS; so at this point it would be fair to say that GP is correct.
      - k3n 13y ago
        That is a good point that it could apply to any missing feature; my point is that to say that any particular feature is "never" going to make it into the language is short-sighted at best. Just a handful of years ago, you could say that "if you want some form of Function.prototype.bind then you're always going to have to polyfill it yourself", which of course would be a 100% inaccurate statement.
      - itsnotlupus 13y ago
        Well, there once was a forlorn EcmaScript version, aka ES4, which included rather similar concepts ( http://www.ecmascript.org/es4/spec/overview.pdf http://www.ecmascript.org/es4/spec/overview.pdf ) : > Structural function types describe functions and methods. The type > function (int, string): boolean > describes a Function object that takes two arguments, one int and the other string, and which returns a boolean Given that a great many other concepts from ES4 are finding their ways into ES6, it is not implausible that this one may also reappear into a more consensual specification someday.
    - haxorize 13y ago
      Fair enough. I just haven't heard of the ECMAScript standards committee seriously considering adding static type checking to the language. The closest things I've seen are the proposed guards [1] and trademarks [2] features for ES7. [1]: http://wiki.ecmascript.org/doku.php?id=strawman:guards http://wiki.ecmascript.org/doku.php?id=strawman:guards [2]: http://wiki.ecmascript.org/doku.php?id=strawman:trademarks http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
- egeozcan 13y ago
  Well, maybe you are mixing it with Google's Traceur-compiler? https://github.com/google/traceur-compiler https://github.com/google/traceur-compiler
nawitus 13y ago
I hope they'll integrate a JavaScript debugger to TypeScript and Visual Studio, possibly with source mapping. (I would specifically need Node.js debugging). I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.
- clone1018 13y ago
  I think that's the point, there is no difference between TypeScript and Node.js Modules.
  - nawitus 13y ago
    So how should I use a TypeScript module like typescript-collections with Node.js? If I don't add /// <reference path>, intellisense doesn't seem to work, but if I add /// <reference path> and import, I had some errors too. 1. https://github.com/basarat/typescript-collections https://github.com/basarat/typescript-collections
- outside1234 13y ago
  Visual Studio allows you to debug TypeScript directly with source maps if you install the free plugin: http://www.microsoft.com/en-us/download/details.aspx?id=34790 http://www.microsoft.com/en-us/download/details.aspx?id=3479...
  - nawitus 13y ago
    What debugger is that using? Note that I'm not looking for debugging browser-side TypeScript/JavaScript code.
chrisoakman 13y ago
I couldn't be more underwhelmed by what TypeScript has to offer vs vanilla JavaScript or CoffeeScript. Reading through the marketing material from MS it seems like the entire value proposition is "statically typed languages make it easier to think about your program, also we added the class keyword so you don't feel lost" I suppose if you believe those claims or are really interested in using MS development tools, TypeScript is for you. IMO, ClojureScript is much more interesting and has a far greater value proposition for complex front-end development.
- xtrumanx 13y ago
  > ...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 again, I shouldn't be surprised by your reaction. This is Hacker News and TypeScript is by Microsoft.
  - deleted 13y ago
    [deleted]
  - chrisoakman 13y ago
    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.
    - xtrumanx 13y ago
      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.
jeswin 13y ago
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.
- sanxiyn 13y ago
  Optional typing works. Why wouldn't it?
- gregwebs 13y ago
  If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside. You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).
  - awj 13y ago
    > If it spreads everywhere then that is because it is valuable everywhere. Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty. My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
    - gregwebs 13y ago
      > ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ... That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error. And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.
kibwen 13y ago
I actually want to commend Microsoft here for releasing an open-source (and permissively-licensed!) compiler that doesn't run exclusively on its own proprietary platform. The language itself seems like a winner as well. Its conservative design makes it the perennial dark horse of the compiled-to-JS language family, but that's also what makes it most attractive to me. It's a thin-enough skin over the underlying language that you get the familiar Javascript syntax (as per Dart) while also retaining the ability to understand the generated code (as per Coffeescript). It's also got well-defined corporate backing, which in a professional environment gives me more peace of mind than recommending Coffeescript (does jashkenas get paid to do this?), Clojurescript, or Elm (I'm somewhat concerned about Dart here as well, at least until Google starts using it in production). These properties mean that I'd happily recommend TypeScript for client-side enterprise software development (but only once the compiler hits 1.0, of course).
- groovy2shoes 13y ago
  I can't speak for CoffeeScript or ClojureScript, but Evan Czaplicky does get paid to work on Elm: http://elm-lang.org/blog/announce/Elm-and-Prezi.elm http://elm-lang.org/blog/announce/Elm-and-Prezi.elm
kailuowang 13y ago
To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side). I really hope I can do something like for ( ra <- asycn_opA(), rb <- async_opB(ra), _ <- asycn_opC(ra, rb) ).run()
- judah 13y ago
  FWIW, there is talk of adding async/await like features (C#, Python) to TypeScript in a post 1.0 release.
- apaprocki 13y ago
  So if you used Q or a similar library: Q.async(function*() { var ra = yield opA(); var rb = yield opB(ra); yield opC(ra, rb); })().done(); Are you wishing for the other syntax or something that you can't achieve with generators/promises today?
  - v13inc 13y ago
    Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6) Here's your example rewritten in the 'monads' library (I probably need a better name): monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });
    - dangoor 13y ago
      Is that open source? I'd be interested in taking a look.
- masklinn 13y ago
  > it's the lack of language syntax support for asynchronous programming spawn(function*() { var ra = yield async_opA(); var rb = yield async_opB(ra); yield async_opC(ra, rb); }); This works right now in Gecko: http://taskjs.org/ http://taskjs.org/. Something very close ought work in ES6/Harmony.
L8D 13y ago
I think the one think that TypeScript needs to get it going is modularity. If another project like [harp](https://github.com/sintaxi/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).
- dangoor 13y ago
  The TypeScript compiler can be used as a library, I believe. The Closure Compiler has a whole type system that lives in doc comments: https://developers.google.com/closure/compiler/docs/js-for-compiler#types https://developers.google.com/closure/compiler/docs/js-for-c... and I believe there's a command line option for doing type checking. Alas, Closure Compiler is written in Java rather than JavaScript so you can't use it quite as seamlessly as TypeScript's compiler.
james-manning 13y ago
Sorry if this comes across as somewhat tangential, but I'm still wondering if/when we'll have JavaScript runtimes (V8, Chakra, SpiderMonkey, whatever) that can export runtime type information, even if only enabled in a 'debug' mode? I love the idea of optional typing being supported (whether in the base language or TypeScript/Closure/etc) but it's maddening to think of trying to have to add the type information manually to existing code, especially code with lots of good test coverage, knowing that the JavaScript runtime seems to have to figure it out anyway (at least based on talks about V8 from the past). This kind of functionality seems even more important for projects like DefinitelyTyped, where people are trying to track the public API's for projects that sometimes have a lot of churn. Having runtimes export their runtime type information (which seems to have sufficient mapping to source based on existing debugger experiences in Chrome, IE10+, etc) and allowing the creation of tooling that can populate/check/etc the type information in source seems like a big potential win. Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript adoption among existing projects seems reasonable, but TypeScript type information seems to still be 'add it yourself' for now? Am I just missing something that makes this far more complex/difficult/intractable than I realize?

112 points by smokel 13y ago

I really love TypeScript because one of the projects goals is to become redundant one day. They're building what they hope JavaScript will get to evolve into.

haxorize 13y ago
That's not entirely true. While TypeScript is closely aligning itself with the proposed ES6 syntax for classes and modules, there is no expectation that ECMAScript will add optional static type checking. If you want statically typed JavaScript you are always going to need something like TypeScript. With that said, as ES6 evolves and becomes more widely supported there will be aspects of the TypeScript compiler that will no longer be needed (e.g. classes, modules, fat arrow functions, etc.).
- k3n 13y ago
  > If you want statically typed JavaScript you are always going to need something like TypeScript. I think that is a valid statement only within the context of the next ECMA release. In other words, that's not to say that whichever successive version after ES6 can't include it, or any version thereafter.
  - jeswin 13y ago
    You could make that argument about any missing feature. I haven't seen any serious support for optional typing in JS; so at this point it would be fair to say that GP is correct.
    - k3n 13y ago
      That is a good point that it could apply to any missing feature; my point is that to say that any particular feature is "never" going to make it into the language is short-sighted at best. Just a handful of years ago, you could say that "if you want some form of Function.prototype.bind then you're always going to have to polyfill it yourself", which of course would be a 100% inaccurate statement.
    - itsnotlupus 13y ago
      Well, there once was a forlorn EcmaScript version, aka ES4, which included rather similar concepts ( http://www.ecmascript.org/es4/spec/overview.pdf http://www.ecmascript.org/es4/spec/overview.pdf ) : > Structural function types describe functions and methods. The type > function (int, string): boolean > describes a Function object that takes two arguments, one int and the other string, and which returns a boolean Given that a great many other concepts from ES4 are finding their ways into ES6, it is not implausible that this one may also reappear into a more consensual specification someday.
  - haxorize 13y ago
    Fair enough. I just haven't heard of the ECMAScript standards committee seriously considering adding static type checking to the language. The closest things I've seen are the proposed guards [1] and trademarks [2] features for ES7. [1]: http://wiki.ecmascript.org/doku.php?id=strawman:guards http://wiki.ecmascript.org/doku.php?id=strawman:guards [2]: http://wiki.ecmascript.org/doku.php?id=strawman:trademarks http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
egeozcan 13y ago
Well, maybe you are mixing it with Google's Traceur-compiler? https://github.com/google/traceur-compiler https://github.com/google/traceur-compiler

nawitus 13y ago

I hope they'll integrate a JavaScript debugger to TypeScript and Visual Studio, possibly with source mapping. (I would specifically need Node.js debugging). I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.

clone1018 13y ago
I think that's the point, there is no difference between TypeScript and Node.js Modules.
- nawitus 13y ago
  So how should I use a TypeScript module like typescript-collections with Node.js? If I don't add /// <reference path>, intellisense doesn't seem to work, but if I add /// <reference path> and import, I had some errors too. 1. https://github.com/basarat/typescript-collections https://github.com/basarat/typescript-collections
outside1234 13y ago
Visual Studio allows you to debug TypeScript directly with source maps if you install the free plugin: http://www.microsoft.com/en-us/download/details.aspx?id=34790 http://www.microsoft.com/en-us/download/details.aspx?id=3479...
- nawitus 13y ago
  What debugger is that using? Note that I'm not looking for debugging browser-side TypeScript/JavaScript code.

chrisoakman 13y ago

I couldn't be more underwhelmed by what TypeScript has to offer vs vanilla JavaScript or CoffeeScript. Reading through the marketing material from MS it seems like the entire value proposition is "statically typed languages make it easier to think about your program, also we added the class keyword so you don't feel lost" I suppose if you believe those claims or are really interested in using MS development tools, TypeScript is for you. IMO, ClojureScript is much more interesting and has a far greater value proposition for complex front-end development.

xtrumanx 13y ago
> ...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 again, I shouldn't be surprised by your reaction. This is Hacker News and TypeScript is by Microsoft.
- deleted 13y ago
  [deleted]
- chrisoakman 13y ago
  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.
  - xtrumanx 13y ago
    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.

jeswin 13y ago

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.

sanxiyn 13y ago
Optional typing works. Why wouldn't it?
gregwebs 13y ago
If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside. You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).
- awj 13y ago
  > If it spreads everywhere then that is because it is valuable everywhere. Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty. My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
  - gregwebs 13y ago
    > ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ... That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error. And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.

kibwen 13y ago

I actually want to commend Microsoft here for releasing an open-source (and permissively-licensed!) compiler that doesn't run exclusively on its own proprietary platform. The language itself seems like a winner as well. Its conservative design makes it the perennial dark horse of the compiled-to-JS language family, but that's also what makes it most attractive to me. It's a thin-enough skin over the underlying language that you get the familiar Javascript syntax (as per Dart) while also retaining the ability to understand the generated code (as per Coffeescript). It's also got well-defined corporate backing, which in a professional environment gives me more peace of mind than recommending Coffeescript (does jashkenas get paid to do this?), Clojurescript, or Elm (I'm somewhat concerned about Dart here as well, at least until Google starts using it in production). These properties mean that I'd happily recommend TypeScript for client-side enterprise software development (but only once the compiler hits 1.0, of course).

groovy2shoes 13y ago
I can't speak for CoffeeScript or ClojureScript, but Evan Czaplicky does get paid to work on Elm: http://elm-lang.org/blog/announce/Elm-and-Prezi.elm http://elm-lang.org/blog/announce/Elm-and-Prezi.elm

kailuowang 13y ago

To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side). I really hope I can do something like for ( ra <- asycn_opA(), rb <- async_opB(ra), _ <- asycn_opC(ra, rb) ).run()

judah 13y ago
FWIW, there is talk of adding async/await like features (C#, Python) to TypeScript in a post 1.0 release.
apaprocki 13y ago
So if you used Q or a similar library: Q.async(function*() { var ra = yield opA(); var rb = yield opB(ra); yield opC(ra, rb); })().done(); Are you wishing for the other syntax or something that you can't achieve with generators/promises today?
- v13inc 13y ago
  Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6) Here's your example rewritten in the 'monads' library (I probably need a better name): monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });
  - dangoor 13y ago
    Is that open source? I'd be interested in taking a look.
masklinn 13y ago
> it's the lack of language syntax support for asynchronous programming spawn(function*() { var ra = yield async_opA(); var rb = yield async_opB(ra); yield async_opC(ra, rb); }); This works right now in Gecko: http://taskjs.org/ http://taskjs.org/. Something very close ought work in ES6/Harmony.

L8D 13y ago

I think the one think that TypeScript needs to get it going is modularity. If another project like [harp](https://github.com/sintaxi/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).

dangoor 13y ago
The TypeScript compiler can be used as a library, I believe. The Closure Compiler has a whole type system that lives in doc comments: https://developers.google.com/closure/compiler/docs/js-for-compiler#types https://developers.google.com/closure/compiler/docs/js-for-c... and I believe there's a command line option for doing type checking. Alas, Closure Compiler is written in Java rather than JavaScript so you can't use it quite as seamlessly as TypeScript's compiler.

james-manning 13y ago

Sorry if this comes across as somewhat tangential, but I'm still wondering if/when we'll have JavaScript runtimes (V8, Chakra, SpiderMonkey, whatever) that can export runtime type information, even if only enabled in a 'debug' mode? I love the idea of optional typing being supported (whether in the base language or TypeScript/Closure/etc) but it's maddening to think of trying to have to add the type information manually to existing code, especially code with lots of good test coverage, knowing that the JavaScript runtime seems to have to figure it out anyway (at least based on talks about V8 from the past). This kind of functionality seems even more important for projects like DefinitelyTyped, where people are trying to track the public API's for projects that sometimes have a lot of churn. Having runtimes export their runtime type information (which seems to have sufficient mapping to source based on existing debugger experiences in Chrome, IE10+, etc) and allowing the creation of tooling that can populate/check/etc the type information in source seems like a big potential win. Anders asking the Chakra team for this to (massively, AFAICT) help TypeScript adoption among existing projects seems reasonable, but TypeScript type information seems to still be 'add it yourself' for now? Am I just missing something that makes this far more complex/difficult/intractable than I realize?