11 ms·

Announcing TypeScript 1.6

132 points by pingec 11y ago

msoad 11y ago
So JSX is not enabled by default, right?
- WorldMaker 11y ago
  You have to use the .TSX filename extension to enable it.
  - evmar 11y ago
    I was just playing with this today. I didn't realize it was so new! I filed a bug about the extension with the related emacs mode and it's already fixed: https://github.com/fxbois/web-mode/issues/585 https://github.com/fxbois/web-mode/issues/585
  - jnetterf 11y ago
    You also need to set {"jsx": "react"} (for valid JS output) or {"jsx": "preserve"} (for JSX output) in your tsconfig.json / cli options.
judah 11y ago
Nothing hugely sexy in this release, but a few small nice things like custom type guards. Really looking forward to async/await support[0]. This will simplify vast swaths of async code trapped in callback hell or promise purgatory. It appears async support has been pushed out until TypeScript 2.0. [0]: https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664
- WorldMaker 11y ago
  The Roadmap [0] has long seen async/await as the defining feature for the TypeScript 2.0 milestone, from what I recall. From what I've read in the blog posts the team wants to prioritize ES6 (ES2015) features first, particularly as async/await is potentially on the standards agenda as early as ES2016 or ES2017... The surprise in TypeScript 1.6 is that experimental support for async/await is actually included, with the caveats that you have to explicitly opt in to the experimental feature with a compiler flag and that it only works when outputting ES6 code (it fails for ES3 and ES5). Some details are at the bottom of the issue 1664. Also, I think the new typing capabilities are hugely sexy if you've ever had to write .d.ts files for wild JS. Generic type aliases and intersection types will solve a lot of things that were much harder to do in definition files previously. Also, the support for expressions in class extends clauses makes it a lot easier to use the nicer class syntax when operating with JS libraries that use a custom object factory. (Given the long history of JS OO, there are a lot of weird custom object factories out there in wild JS code.) This is also good catchup with ES6 class syntax; it's always sexy when TS works to keep its "pure superset" goals. [0]: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap
- ken47 11y ago
  I disagree. Abstract classes, generators, and built-in JSX support are definitely "sexy."
  - judah 11y ago
    Generators are not in TS 1.6. JSX support is a big feature, albeit controversial and not for everyone. Notice Rob Eisenberg's first comment on the blog: "I do have one concern with this release. Back in the day, Anders was extremely adamant about not including XML in C#. At the time, XML was extremely popular, but today it is much less so. It was a wise decision. Today, I see a release that ties TypeScript to JSX, which seems to fly in the face of the previous language design principle. But furthermore, it is a long held principle that one should not embed JavaScript in HTML. So, why are we so quick to embed HTML in JavaScript? JSX has always seemed like a phenomenally bad idea and one that is certain to be short lived. Can you elaborate on the nature of the JSX integration? I'd like to know that it's not going to affect TS in the long-term. I'd also like to know what type of compiler output it produces. Does it produce React code? or does it produce some sort of string concatenation expression in the end? Did the TS compiler just get tied to the React library's implementation details?"
mwsherman 11y ago
Type guards offer just a bit of magic, similar to type switches in Go: https://golang.org/doc/effective_go.html#type_switch https://golang.org/doc/effective_go.html#type_switch
matchu 11y ago
I don't know much about type theory, so I suspect that my intuition is wrong, but the phrase "intersection type" violates my intuition. If I have Printable and Drawable interfaces, which each describe a set of behaviors, then I would expect the "intersection" of Printable and Drawable to be the intersection of those sets of behaviors — which, here, is likely the empty set. Is there another way of understanding types that makes the word "intersection" make more sense here? Or is it just to say that "where union types say OR, intersection types say AND"? --- ...ya know what? By typing it out, I think I get it now. The set that we're talking about isn't the set of Printable's behaviors; it's the set of things that implement Printable. `Printable & Drawable` is the intersection of the set of types that implement Printable with the set of types that implement Drawable. Got it. Thanks for rubber-ducking for me, HN!
- spicyj 11y ago
  Objects whose type is a subtype of "Printable | Drawable" (union) are those that implement either interface. For "Printable & Drawable" (intersection), you have objects that implement both interfaces. Meaning, those objects that have both .print() and .draw() (or similar). You're not taking the intersection of the interfaces, but of the sets of objects that implement them.
- CurtHagenlocher 11y ago
  I found some of the comments at http://stackoverflow.com/questions/5653678/union-types-and-intersection-types http://stackoverflow.com/questions/5653678/union-types-and-i... helpful. If TAPL refers to "intersection types" then it's definitely a well-defined concept.
  - zeckalpha 11y ago
    There's also sum and product types, again by analogy.
- ken47 11y ago
  It's not the same sort of intersection as you might understand it from mathematical sets: http://stackoverflow.com/questions/5653678/union-types-and-intersection-types http://stackoverflow.com/questions/5653678/union-types-and-i... See the response about C#.
spion 11y ago
So, with TSX support in TypeScript, node and react-native, its now possible to write end-to-end type checked web and mobile applications (from database to templates). With full language service support (refactoring, intelligent navigation etc) that is also exposed via a standalone language service distributed with the compiler relatively easy to integrate with any editor. All that while seamlessly leveraging the entire node (and JS) ecosystem (just add a few definition files). And there even is a free, cross-platform editor that packages it all into one neat package: https://code.visualstudio.com/ https://code.visualstudio.com/ Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)
- applecore 11y ago
  With Flow and React DOM/Native, you already get complete type-checking across mobile, native, and web application.
  - patrickaljord 11y ago
    For those wondering, more info here https://babeljs.io/docs/advanced/transformers/other/flow/ https://babeljs.io/docs/advanced/transformers/other/flow/
  - yareally 11y ago
    Flow doesn't work on Windows though. However, Typescript works on Linux, OSX and Windows.
  - WorldMaker 11y ago
    A key benefit to TypeScript over Flow is the very deep amount of IntelliSense and IDE support you get from it up front in your development process. It's very nice to have things like auto-completion and API documentation at your fingertips as you work. Also, TypeScript has a fairly strong transpilation engine and can be a one-stop shop for most of your transpilation needs (contrasting to also needing something Babel or Traceur in your build and/or runtime stack, for instance, because you can just transpile ES6-like TypeScript directly to ES5).
- 11y ago
WhitneyLand 11y ago
Does TS really require type files for every JS library you use? I tried to use it the other day with node.js but couldn't find a type file for the popular simple-oauth2 package.
- spion 11y ago
  You can say that the library is of "any" type and the compiler will accept all method calls on it. However it should be fairly easy to write a .d.ts file for it. You don't even have to cover the entire library - its enough to specify the types of the parts you use.
- tlarkworthy 11y ago
  https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped and TSD to copy into your directory from DT (it's like a package manager for definitions). Not ideal but that's the practice. Doesn't cover your simple-oauth2 example though, but its not that bad adding the individual methods you need on demand (easier if you have the definatelyTyped examples to follow).
- Nitramp 11y ago
  Yes, but that's a good thing. .d.ts files are reasonably straightforward to write (the external vs internal module thing is the exception), and easy to share on DefinitelyTyped. But that only happened because TypeScript requires .d.ts files - the requirement pushes the community forward, with benefits for all.
aikah 11y ago
I like Typescript, however it leads to that "Enterprise Javascript" coding style I really hate, pushing OOP Java style over simple functional programming. But I admit that being able to read type signatures in the source code makes understanding a code base way easier, it's just that people tend to be more verbose going full OOP , even when it is not necessary. But kudos for Microsoft, if only they would have accepted ES4 8 years ago, TS would not have been needed. And by the way Microsoft, why not make Jscript.net cool again ?
- dangoor 11y ago
  I don't see how TypeScript leads to "Enterprise JavaScript" any more than ES2015 does, given the new class syntax. If I was writing TypeScript, I'd be using functions and simple objects.
  - threatofrain 11y ago
    TypeScript is a superset of EcmaScript, and adds nothing new except for types. Only exactly that.
  - andreime 11y ago
    It helps people who don't know JS code for JS. And it helps people like c# / java devs just writing code without learning more that typescript. This is very powerful but it also can lead to Enterprise-like code writing.
- WorldMaker 11y ago
  The great thing about multi-paradigm languages is that you and I can write very functional code one day and lend a hand in a heavily OOP codebase the next. Even "Enterprise JavaScript" is a step up from the hodge podge "no paradigm" JS that has classically littered the web. It's nice seeing actual architecture and planning in JS codebases these days, with and without the big rigid frameworks. Sure, a lot of it is more verbose than it needs to be and over-architecture is an easy over correction to make, but typically I'll take over-architecture over no-architecture any day of the week. (Even if most of the joy I get from over-architecture is taking sledge hammers to it and reducing it down to a tighter core. Net negative lines of code refactors are a wonderful thing.)
chinhodado 11y ago
Is there an updated extension for Visual Studio yet?
- mohamedhegazy 11y ago
  If you are using VS 2015, TypeScript is accessible through the Extensions & updates window. For downloading plugin for VS 2015 available at:http://www.microsoft.com/en-us/download/details.aspx?id=48593&WT.mc_id=DX_MVP4025064 http://www.microsoft.com/en-us/download/details.aspx?id=4859... and VS 2013 available at: http://www.microsoft.com/en-us/download/details.aspx?id=48739&WT.mc_id=DX_MVP4025064 http://www.microsoft.com/en-us/download/details.aspx?id=4873...

132 points by pingec 11y ago

msoad 11y ago

So JSX is not enabled by default, right?

WorldMaker 11y ago
You have to use the .TSX filename extension to enable it.
- evmar 11y ago
  I was just playing with this today. I didn't realize it was so new! I filed a bug about the extension with the related emacs mode and it's already fixed: https://github.com/fxbois/web-mode/issues/585 https://github.com/fxbois/web-mode/issues/585
- jnetterf 11y ago
  You also need to set {"jsx": "react"} (for valid JS output) or {"jsx": "preserve"} (for JSX output) in your tsconfig.json / cli options.

judah 11y ago

Nothing hugely sexy in this release, but a few small nice things like custom type guards. Really looking forward to async/await support[0]. This will simplify vast swaths of async code trapped in callback hell or promise purgatory. It appears async support has been pushed out until TypeScript 2.0. [0]: https://github.com/Microsoft/TypeScript/issues/1664 https://github.com/Microsoft/TypeScript/issues/1664

WorldMaker 11y ago
The Roadmap [0] has long seen async/await as the defining feature for the TypeScript 2.0 milestone, from what I recall. From what I've read in the blog posts the team wants to prioritize ES6 (ES2015) features first, particularly as async/await is potentially on the standards agenda as early as ES2016 or ES2017... The surprise in TypeScript 1.6 is that experimental support for async/await is actually included, with the caveats that you have to explicitly opt in to the experimental feature with a compiler flag and that it only works when outputting ES6 code (it fails for ES3 and ES5). Some details are at the bottom of the issue 1664. Also, I think the new typing capabilities are hugely sexy if you've ever had to write .d.ts files for wild JS. Generic type aliases and intersection types will solve a lot of things that were much harder to do in definition files previously. Also, the support for expressions in class extends clauses makes it a lot easier to use the nicer class syntax when operating with JS libraries that use a custom object factory. (Given the long history of JS OO, there are a lot of weird custom object factories out there in wild JS code.) This is also good catchup with ES6 class syntax; it's always sexy when TS works to keep its "pure superset" goals. [0]: https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap
ken47 11y ago
I disagree. Abstract classes, generators, and built-in JSX support are definitely "sexy."
- judah 11y ago
  Generators are not in TS 1.6. JSX support is a big feature, albeit controversial and not for everyone. Notice Rob Eisenberg's first comment on the blog: "I do have one concern with this release. Back in the day, Anders was extremely adamant about not including XML in C#. At the time, XML was extremely popular, but today it is much less so. It was a wise decision. Today, I see a release that ties TypeScript to JSX, which seems to fly in the face of the previous language design principle. But furthermore, it is a long held principle that one should not embed JavaScript in HTML. So, why are we so quick to embed HTML in JavaScript? JSX has always seemed like a phenomenally bad idea and one that is certain to be short lived. Can you elaborate on the nature of the JSX integration? I'd like to know that it's not going to affect TS in the long-term. I'd also like to know what type of compiler output it produces. Does it produce React code? or does it produce some sort of string concatenation expression in the end? Did the TS compiler just get tied to the React library's implementation details?"

mwsherman 11y ago

Type guards offer just a bit of magic, similar to type switches in Go: https://golang.org/doc/effective_go.html#type_switch https://golang.org/doc/effective_go.html#type_switch

matchu 11y ago

I don't know much about type theory, so I suspect that my intuition is wrong, but the phrase "intersection type" violates my intuition. If I have Printable and Drawable interfaces, which each describe a set of behaviors, then I would expect the "intersection" of Printable and Drawable to be the intersection of those sets of behaviors — which, here, is likely the empty set. Is there another way of understanding types that makes the word "intersection" make more sense here? Or is it just to say that "where union types say OR, intersection types say AND"? --- ...ya know what? By typing it out, I think I get it now. The set that we're talking about isn't the set of Printable's behaviors; it's the set of things that implement Printable. `Printable & Drawable` is the intersection of the set of types that implement Printable with the set of types that implement Drawable. Got it. Thanks for rubber-ducking for me, HN!

spicyj 11y ago
Objects whose type is a subtype of "Printable | Drawable" (union) are those that implement either interface. For "Printable & Drawable" (intersection), you have objects that implement both interfaces. Meaning, those objects that have both .print() and .draw() (or similar). You're not taking the intersection of the interfaces, but of the sets of objects that implement them.
CurtHagenlocher 11y ago
I found some of the comments at http://stackoverflow.com/questions/5653678/union-types-and-intersection-types http://stackoverflow.com/questions/5653678/union-types-and-i... helpful. If TAPL refers to "intersection types" then it's definitely a well-defined concept.
- zeckalpha 11y ago
  There's also sum and product types, again by analogy.
ken47 11y ago
It's not the same sort of intersection as you might understand it from mathematical sets: http://stackoverflow.com/questions/5653678/union-types-and-intersection-types http://stackoverflow.com/questions/5653678/union-types-and-i... See the response about C#.

spion 11y ago

So, with TSX support in TypeScript, node and react-native, its now possible to write end-to-end type checked web and mobile applications (from database to templates). With full language service support (refactoring, intelligent navigation etc) that is also exposed via a standalone language service distributed with the compiler relatively easy to integrate with any editor. All that while seamlessly leveraging the entire node (and JS) ecosystem (just add a few definition files). And there even is a free, cross-platform editor that packages it all into one neat package: https://code.visualstudio.com/ https://code.visualstudio.com/ Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)

applecore 11y ago
With Flow and React DOM/Native, you already get complete type-checking across mobile, native, and web application.
- patrickaljord 11y ago
  For those wondering, more info here https://babeljs.io/docs/advanced/transformers/other/flow/ https://babeljs.io/docs/advanced/transformers/other/flow/
- yareally 11y ago
  Flow doesn't work on Windows though. However, Typescript works on Linux, OSX and Windows.
- WorldMaker 11y ago
  A key benefit to TypeScript over Flow is the very deep amount of IntelliSense and IDE support you get from it up front in your development process. It's very nice to have things like auto-completion and API documentation at your fingertips as you work. Also, TypeScript has a fairly strong transpilation engine and can be a one-stop shop for most of your transpilation needs (contrasting to also needing something Babel or Traceur in your build and/or runtime stack, for instance, because you can just transpile ES6-like TypeScript directly to ES5).
11y ago

WhitneyLand 11y ago

Does TS really require type files for every JS library you use? I tried to use it the other day with node.js but couldn't find a type file for the popular simple-oauth2 package.

spion 11y ago
You can say that the library is of "any" type and the compiler will accept all method calls on it. However it should be fairly easy to write a .d.ts file for it. You don't even have to cover the entire library - its enough to specify the types of the parts you use.
tlarkworthy 11y ago
https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped and TSD to copy into your directory from DT (it's like a package manager for definitions). Not ideal but that's the practice. Doesn't cover your simple-oauth2 example though, but its not that bad adding the individual methods you need on demand (easier if you have the definatelyTyped examples to follow).
Nitramp 11y ago
Yes, but that's a good thing. .d.ts files are reasonably straightforward to write (the external vs internal module thing is the exception), and easy to share on DefinitelyTyped. But that only happened because TypeScript requires .d.ts files - the requirement pushes the community forward, with benefits for all.

aikah 11y ago

I like Typescript, however it leads to that "Enterprise Javascript" coding style I really hate, pushing OOP Java style over simple functional programming. But I admit that being able to read type signatures in the source code makes understanding a code base way easier, it's just that people tend to be more verbose going full OOP , even when it is not necessary. But kudos for Microsoft, if only they would have accepted ES4 8 years ago, TS would not have been needed. And by the way Microsoft, why not make Jscript.net cool again ?

dangoor 11y ago
I don't see how TypeScript leads to "Enterprise JavaScript" any more than ES2015 does, given the new class syntax. If I was writing TypeScript, I'd be using functions and simple objects.
- threatofrain 11y ago
  TypeScript is a superset of EcmaScript, and adds nothing new except for types. Only exactly that.
- andreime 11y ago
  It helps people who don't know JS code for JS. And it helps people like c# / java devs just writing code without learning more that typescript. This is very powerful but it also can lead to Enterprise-like code writing.
WorldMaker 11y ago
The great thing about multi-paradigm languages is that you and I can write very functional code one day and lend a hand in a heavily OOP codebase the next. Even "Enterprise JavaScript" is a step up from the hodge podge "no paradigm" JS that has classically littered the web. It's nice seeing actual architecture and planning in JS codebases these days, with and without the big rigid frameworks. Sure, a lot of it is more verbose than it needs to be and over-architecture is an easy over correction to make, but typically I'll take over-architecture over no-architecture any day of the week. (Even if most of the joy I get from over-architecture is taking sledge hammers to it and reducing it down to a tighter core. Net negative lines of code refactors are a wonderful thing.)

chinhodado 11y ago

Is there an updated extension for Visual Studio yet?

mohamedhegazy 11y ago
If you are using VS 2015, TypeScript is accessible through the Extensions & updates window. For downloading plugin for VS 2015 available at:http://www.microsoft.com/en-us/download/details.aspx?id=48593&WT.mc_id=DX_MVP4025064 http://www.microsoft.com/en-us/download/details.aspx?id=4859... and VS 2013 available at: http://www.microsoft.com/en-us/download/details.aspx?id=48739&WT.mc_id=DX_MVP4025064 http://www.microsoft.com/en-us/download/details.aspx?id=4873...