Announcing TypeScript 1.6

http://blogs.msdn.com/b/typescript/archive/2015/09/16/announcing-typescript-1-6.aspx

by pingec • 11 years ago

132 32 11 years ago

blogs.msdn.com

msoad• 11 years ago

So JSX is not enabled by default, right?

WorldMaker5• 11 years ago

You have to use the .TSX filename extension to enable it.

evmar• 11 years 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

jnetterf• 11 years ago

You also need to set {"jsx": "react"} (for valid JS output) or {"jsx": "preserve"} (for JSX output) in your tsconfig.json / cli options.

judah2• 11 years 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

WorldMaker5• 11 years 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

ken472• 11 years ago

I disagree. Abstract classes, generators, and built-in JSX support are definitely "sexy."

judah2• 11 years 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• 11 years ago

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

matchu• 11 years 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• 11 years 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• 11 years ago

I found some of the comments at 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• 11 years ago

There's also sum and product types, again by analogy.

ken472• 11 years 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-i...

See the response about C#.

WorldMaker5• 11 years ago

It is referring to mathematical sets, but at the categorization of types level rather than the "shape" of types.

If you think of Set X consisting of all the objects that could possibly be built as Class X and Set Y as all the objects that could possibly be built as Class Y, then the union of those sets is all of the Class X derived objects and all of the Class Y derived objects, whereas the intersection of those sets are whatever objects manage to implement or derive from both Class X and Class Y.

spion2• 11 years 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/

Seriously, how cool is that? (Even though admittedly there are soundness issues with TypeScript, its still pretty damn amazing)

applecore• 11 years ago

With Flow and React DOM/Native, you already get complete type-checking across mobile, native, and web application.

patrickaljord• 11 years ago

For those wondering, more info here https://babeljs.io/docs/advanced/transformers/other/flow/

yareally• 11 years ago

Flow doesn't work on Windows though. However, Typescript works on Linux, OSX and Windows.

WorldMaker5• 11 years 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).

ludamad• 11 years ago

I have been experimenting with React development with TSX and I must say I finally feel like I can do web development in a way that isn't just trial and error. The soundness issues with TypeScript do crop up, but they happen at certain boundaries that if you're use to them, you'll scrutinize them harder. Mind you, this is the same scrutiny you are used to doing in plain Javascript.

WhitneyLand• 11 years 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.

spion2• 11 years 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• 11 years ago

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• 11 years 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• 11 years 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• 11 years 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• 11 years ago

TypeScript is a superset of EcmaScript, and adds nothing new except for types. Only exactly that.

andreime• 11 years 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.

WorldMaker5• 11 years 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• 11 years ago

Is there an updated extension for Visual Studio yet?

mohamedhegazy• 11 years 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=4859...

and VS 2013 available at: http://www.microsoft.com/en-us/download/details.aspx?id=4873...

Announcing TypeScript 1.6

Related Stories