
Announcing TypeScript 1.7 - runesoerensen
http://blogs.msdn.com/b/typescript/archive/2015/11/30/announcing-typescript-1-7.aspx
======
carterehsmith
To me, this appears to be the way to go. Javascript + Typescript. Rather than
deciding on weak (dynamic) typing vs strong typing, you pick both -
incremental typing, as allowed by Typescript.

Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is
all valid Typescript. So you get dynamic typing. And if you do not care about
strong typing, you can just stop right there.

But if you, some day, for whatever reason, decide that you feel like strong
typing: good - you do not need to rewrite your app in a different language -
just go back to your code and add some type info, here and there, at your
leisure. As you do that, you get all the benefits of static typing, ie
compiler showing you obvious type-related errors, correct keyword-completion,
exact refactorings, etc etc.

Looks like the best of both worlds.

~~~
haberman
How is this different from using Facebook Flow? I have been using Flow on a
JavaScript project, along with Babel for ES6, and enjoying the experience
quite a lot.

~~~
dietrichepp
Typescript is older (2012 vs 2014), more mature and stable (v1.7 vs v0.x), has
better tooling support (autocompletion in Visual Studio), is easier to install
(you only need NPM), has better documentation, and is easier to Google (try
searching for "flow" online!). There are also plenty of common libraries with
Typescript annotations, so you can just use e.g. Phaser and Typescript
together without any extra work. Other than that Flow and Typescript are
fairly similar. Perhaps someone who has used Flow can explain what makes it
different from Typescript.

~~~
strmpnk
Flow offers some interesting control over things like optional types
(nullable) and intelligent understanding of type tests in conditionals or
calls to libraries like invariant. I've had these sorts of features catch
quite a few bugs in my editor before even running a single test.

Flow is also based on a daemon which continuously monitors your code. As such,
it incrementally checks your modules allowing it to be extremely fast once
started.

I ended up using flow since it fit with the language feature set I was using
with Babel (JSX in react code being one example). Since then, I've grown to
enjoy the flow based typing and the rather good support for optional and non-
optional types.

Looking at the code lately seems to show some interesting stuff in the
pipeline too. Taint tracking seems like a very useful one that I'd love to
implement and seems like a natural extension of the code-flow based type
system.

Flow could definitely use more documentation and more example code but I found
the community on IRC extremely helpful and polite so perhaps it's not a bad
time to start if you're willing to do a little reading on the site first:
[http://flowtype.org/docs/getting-
started.html](http://flowtype.org/docs/getting-started.html)

~~~
spion
TypeScript has type guards, which covers #1. Also has custom type guards,
which lets you write your own checks that constrain union types.

TypeScript also has a language services server which runs as a daemon, lets
you submit incremental edits to it and supports services such as autocomplete,
rename refactoring and pretty much anything you see in visual studio or visual
studio code.

But yes, the type system has a couple of unfortunate flaws that are relics
from its beginnings (cant express non-nullable types).

------
Nitramp
We're super happy with TypeScript in Angular, it's working great for us, and
having the option (!) to easily use it will be great for Angular users.

A note on all the praise for type inference: local type inference is super
cool as it saves on a lot of boiler plate (`Foo foo = new Foo(); // foo`
anyone?).

But global type inference, i.e. across function and module boundaries, has its
drawbacks. Apart from performance cost, the most important is IMHO
understandability. If you don't have explicit types across module boundaries,
it can easily become hard to decide just what a type is supposed to be, e.g.
if your code doesn't compile, but the compiler cannot tell you which part of
it is wrong, because all the types are inferred. That can easily lead to "wall
of text" C++ compiler style error messages. Same if some new library version
changes type inference patterns, your code might suddenly break in surprising
and hard to understand ways.

I think TypeScript's (& Go's) choice of local type inference is a good mix of
less boilerplate and good understandability, together with gradual typing via
`any`.

------
dfabulich
I missed it when I first read the blog post, so I figure it's worth
emphasizing: the new async/await support is _only_ available on JavaScript
engines that already support "function*" generator functions: Node 4, Firefox,
and Chrome, but not Safari or IE/Edge.

Supporting async/await in ES5/ES3 is on the roadmap for TypeScript v2.0.
[https://github.com/Microsoft/TypeScript/wiki/roadmap](https://github.com/Microsoft/TypeScript/wiki/roadmap)

~~~
ahoge
Edge 13 does support generators.

[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat-
table/es6/)

------
trevordev
Typescript has became my favorite language. The option of having types when
you need them is great and the addition of async/await make working with
promises a lot nicer. Ever since I've been able to use experimental features
and get es6 support with typescript I've never looked back. The only thing
lacking now is the tooling. The atom-typescript plugin is the best I've found
but I would love to see better integration with other editors. Can't wait to
see what comes to typescript next!

~~~
aozgaa
I can't speak to atom, but have you considered Visual Studio Code? That and
VS2015 are tightly integrated with the TypeScript compiler and language
service (provides autocomplete, type hinting, go-to definition, etc.).

For sublime, there is a plugin actively developed by Microsoft [1].

For vim, the plugin YouCompleteMe provide autocomplete [2].

Also, I haven't tried it, but there's an Emacs-mode, apparently [3].

There are also numerous other alternatives I'm unfamiliar with.

Hope this helps!

[1] [https://github.com/Microsoft/TypeScript-Sublime-
Plugin](https://github.com/Microsoft/TypeScript-Sublime-Plugin)

[2]
[http://valloric.github.io/YouCompleteMe/#intro](http://valloric.github.io/YouCompleteMe/#intro)

[3] [https://github.com/aki2o/emacs-tss](https://github.com/aki2o/emacs-tss)

~~~
MasterScrat
WebStorm (IntelliJ) support is really good as well.

~~~
drinchev
I'm not sure how this support will be added though. So far the last WebStorm (
which arrived a month ago ) supports 1.6, but definitely not as good as let's
say visual code.

Example for that is lack of per module definition files .d.ts and package.json
typing a property.

I'm fairly In a mood to switch to visual code or Atom, since I write
exclusively typescript nowadays.

------
Bahamut
Awesome work by the TypeScript team - they have been moving very fast to
improve TypeScript over the course of this year, and I am impressed by the
amount of effort Microsoft has poured into this. Using TS now is pretty nice,
and has already paid dividends at work in catching some subtle bugs

------
pluma
TypeScript isn't competing with Flow, it's also competing with Babel. I still
don't understand why MS keeps wasting energy on implementing ES.next features
in their transpiler when there's already an established modular open source
solution available. I understand why it started that way but even FB stopped
using their own transpiler (JSX) once Babel gained traction.

~~~
Keats
You can use TypeScript just for the types and hand the es6 files to Babel
after.

Also TypeScript existed before Babel and there are some features not supported
by Babel (modules, public/private). See this issue for more details
[https://github.com/Microsoft/TypeScript/issues/1641](https://github.com/Microsoft/TypeScript/issues/1641)

~~~
pluma
That issue is back from when Babel was still called 6to5.

Babel didn't support JSX, decorators or type annotations. Now it does. Babel 6
is even more modular, lending itself even more to extension than Babel 5 did
before.

There's nothing stopping MS from adding TS extensions to Babel.

~~~
Keats
I'm guessing Microsoft is not keen on starting from scratch for no visible
benefits for them. You could try opening another issue to see if they changed
their minds though

------
stewbrew
I'd like to see a thorough comparison of typescript, haxe, scala.js, and also
gopherjs. Which (statically typed) language/compiler provides the best
experience for developers who want to develop "native" programs (I include
here jvm and node) and javascript for the web with one language using the same
libraries?

~~~
astrafoo
[http://www.scala-js.org/](http://www.scala-js.org/) has a nice comparison
between JavaScript, ECMAScript 6, TypeScript and Scala.

I'm not sure there is much substance to develop "native" programs in
TypeScript/Haxe/... they don't have an ecosystem outside the web, while Scala
has tons of mature libraries, access to all the Java stuff ever written, and
runs on the best, mature, well-supported, high-performance runtime you can
get.

~~~
stewbrew
ts has the node ecosystem, and haxe provides easy access to
node/pyton/c++/java libs. gopherjs is able to compile a significant amount of
the go standard lib -- I don't know if this is true for arbitrary go libs too.

Thanks for the reference.

------
netcraft
Can you compile TS from inside of JS or TS? something like
`babel.transformFile`, that gives you back the compiled code?

~~~
freditup
Yes, you can: [https://github.com/Microsoft/TypeScript/wiki/Using-the-
Langu...](https://github.com/Microsoft/TypeScript/wiki/Using-the-Language-
Service-API)

~~~
DCoder
There are some subtle behavioural differences between the Language Service and
the regular compiler, for example:
[https://github.com/Microsoft/TypeScript/issues/5243](https://github.com/Microsoft/TypeScript/issues/5243)

~~~
freditup
Good clarification. Perhaps the compiler API is the better choice here? I'm
not fully aware of the differences / divisions between the two.
[https://github.com/Microsoft/TypeScript/wiki/Using-the-
Compi...](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API)

~~~
DCoder
Interesting, I honestly don't know if that makes a difference.

------
tlarkworthy
Polymorphic this is really useful for the 'cannot reference a type twice in
the type list' issue you get when doing generics. Since learning it I have
used it many times. It's solves many issues like typing a clone method.
Awesome addition!

------
lukasm
Polymorphic this Typing seems like a major change with many possible corner
cases. I think Dart .. operator is a better solution

    
    
        newModel.setupBase().setupAdvanced();
    

becomes

    
    
        newModel..setupBase()..setupAdvanced();

~~~
Arnavion
That assumes setupBase(), etc are either void-returning or return the this-
instance (newModel). It won't work if each method returns a new instance, such
as methods of immutable collections.

Edit: Since this is hard to google for, this is called the "cascade operator".
The given example is equivalent to:

    
    
        newModel.setupBase(); newModel.setupAdvanced();
    

That is, it ignores the result of the method and runs the remaining part of
the statement with the LHS of the operator.

~~~
mythz
> That assumes setupBase(), etc are either void-returning or return the this-
> instance (newModel).

This is Incorrect, it doesn't assume anything. Dart's method cascades just
returns the receiver, it doesn't matter what the method returns, it's value is
ignored and receiver is returned instead.

[http://news.dartlang.org/2012/02/method-cascades-in-dart-
pos...](http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-
gilad.html)

Since the return value is ignored, it's only useful for methods with side-
effects.

~~~
Arnavion
>This is Incorrect, it doesn't assume anything. Dart's method cascades just
returns the receiver, it doesn't matter what the method returns, it's value is
ignored and receiver is returned instead.

... which would only be useful if the method was void-returning or returned
the this-instance, i.e., it didn't return a _new_ instance and left the LHS
unmodified.

~~~
mythz
> which would only be useful if the method was void-returning or returned the
> this-instance

Simply untrue, there are plenty of times methods have side-effects that return
something other than void or itself, e.g:

    
    
      - Incrementing a value and returning the current value
      - Inserting or Updating rows and returning the number of rows affected
      - Setting an entry and returning whether there was an existing entry or not

~~~
Arnavion
The example I was responding to was about "setupBase" and "setupAdvanced"...

------
hokkos
That's great but is there any ES6 minification tool that handle ES6 ? Because
last time I checked uglify didn't handle generators (and I assume by async to
ES6 target they transform it to generators).

~~~
flyingmutant
There is [http://rollupjs.org/](http://rollupjs.org/), which is quite young
though.

~~~
hokkos
It uses babel, so it uses regenerator (
[https://github.com/facebook/regenerator](https://github.com/facebook/regenerator)
) and then uglify probably.

It will be great when typescript can do it natively because it knows at lot
more before the being translated to javascript :
[https://github.com/Microsoft/TypeScript/issues/8](https://github.com/Microsoft/TypeScript/issues/8)

------
TazeTSchnitzel
> This type can be used in classes and interfaces to represent some type that
> is a subtype of the containing type (rather than the containing type itself)

Could that not be achieved by having covariant return types instead?

~~~
Arnavion
Sure, but that would require every subtype to override every method of the
base type with a narrower return type, and do nothing except delegate to the
base type in the body. It would be tedious boilerplate.

Since the base type's implementation already returns `this`, it makes sense to
be able to annotate the method as returning `this` and get the benefit
automatically.

~~~
TazeTSchnitzel
Ah, yes, that's a problem. In PHP, there's been some debate as to whether or
not to support `static` (similar in function to TypeScript's `this`) as a
return type, and that's one of the arguments in favour.

------
MasterScrat
Tangential question: which IDE are you using for TypeScript?

I'm quite happy with WebStorm on OSX but I am wondering if a switch to Visual
Studio may be worth it.

------
ebbv
I remember when MicroSoft tried to make it's own superscript of JS and people
said "Hey this is a bad idea. Standards are a thing for a reason and we should
all stick to them." That argument was correct then and it's correct now, IMHO.

Where is the objection in 2015? Is it just people are so desensitized by other
companies attempts to make JS replacements (that for now compile to JS) that
another one just doesn't bug anyone?

I realize the temptation for big companies like Microsoft with thousands of
devs to roll their own, but when every big company abandons standards to focus
on their own little alcove we all suffer.

And yeah, I realize you can frame it as they haven't abandoned the standard
because TypeScript compiles to JS and yada, yada. But I disagree. If instead
of focusing on TypeScript which you can only take advantage of by working in
TypeScript, they focused on libraries for JS that we could all use, I think
we'd all be better off. And that goes for all large corporations that decide
to roll their own solutions instead of sticking to standards.

Which is not to say JS can never be replaced, I'd say it's long overdue for
replacement. But that's never going to happen by every big company rolling
their own thing. Everybody has to come together.

~~~
dangoor
There are quite a few differences from the old "JScript" days.

First of all: TypeScript is liberally licensed open source. JScript was
totally proprietary.

Another aspect is that TypeScript is seeking to be a strict superset of
JavaScript that evolves as JavaScript does (something that wasn't really
happening in the JScript days) and is focused on specifically providing static
types and tooling for types in JS. It's not a general "embrace, extend,
extinguish" kind of thing at all, but rather a very targeted tool.

TypeScript is really one of the most JavaScript-y languages that compile to
JS. Most of the compile-to-JS languages are more radical divergences from JS.

JS is not going to be replaced (though WebAssembly[1] will likely become an
additional compile target), but compile-to-JS is going to continue to grow in
popularity. Already, many people are compiling future-JS to present-day-JS.

The browser vendors have found that the standards evolve best when people can
actually write code against the standards _before_ the standards are hardened.
Compile-to-JS tools help with that. If optional static types and type
inference become very popular via TypeScript and Flow, JS itself may evolve to
support those features and then we'll have that standard.

Microsoft is a better player on the web today than they have ever been before.

[1]:
[https://github.com/WebAssembly/design](https://github.com/WebAssembly/design)

~~~
spion
> TypeScript is really one of the most JavaScript-y languages that compile to
> JS. Most of the compile-to-JS languages are more radical divergences from
> JS.

This is what I've been trying to get across for a while, thanks for the
wording. Even CoffeeScript is a much bigger divergence than TypeScript (not
only in syntax but in semantics, e.g. scope)

