
Announcing TypeScript 2.0 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/
======
k__
TL;DR

\- Simplified Declaration File (.d.ts) Acquisition (via npm)

\- Non-nullable Types

\- Control Flow Analyzed Types

\- The readonly Modifier

Finally, I was wating for months :)

~~~
FrancoDiaz
_Simplified Declaration File (.d.ts) Acquisition (via npm)_

This is huge from a usability perspective.

~~~
ng12
It doesn't seem to be ready. Random thing are broken that weren't in Typings.

~~~
FrancoDiaz
There's a couple different things we're talking about here. The ability to
install typings via npm, which is good because it gets rid of another tool
(typings) and everything is in package.json. But the other thing is the
ability to consume declaration files in node_module packages themselves, which
I consider a bigger win.

~~~
ng12
Why couldn't you do that before? Definition files are just ts files, wouldn't
tsc be able to find them in node_modules?

------
edroche
I can't wait to use some of the new features in our production apps.
Typescript is/was my bridge into javascript development, because IMHO
javascript was a broken language for a long time, and I am not sure if I could
have ever done as much as I have without its existence.

Non-nullable types, tagged union types, and easy declaration file acquisition
are definitely the biggest wins for me with this release.

~~~
qwertyuiop924
Javascript isn't as broken as you might think.

Non-nullable types, OTOH, might just be the thing that makes me start using
TS, despite my love of dynamic typing.

~~~
niieani
Try adding 1.3 + 1.1 and tell me JavaScript isn't broken. Hint: The result is
isn't 2.4, it's 2.4000000000000004.

Unfortunately that's something TypeScript doesn't tackle, but you can use
external libraries for floats, where you work on floats as... strings.

~~~
keithnz
when you work with floats, never expect anything to exactly equal a value, ie,
it should be banned to use <float> === <constant> . That is universal across
languages, for exact representations often languages provide another type. But
floating point is popular because CPUs can natively work with them.

~~~
Roboprog
For financial work, you want to use a fixed precision or binary coded decimal
library, such as java's BigDecimal.

You knew that, but I'm just spelling it out for others.

~~~
qwertyuiop924
...Or you could use Scheme, where we have precise numbers (fractions)

------
dested
This isn't really the place for it but I really wish that both Webstorm and
Resharper used the actual typescript compiler for its tooling (like vscode) vs
handrolling their own. Now I have to wait until Webstorm 2016.3 to see the
full benefit of 2.0, rather than getting it for free by just updating
typescript. Not to mention the obscene number of typescript edge case
inconsistencies in the warnings, errors, and refactorings.

~~~
CraigJPerry
You've been able to configure your own tsc for a while, at least in IDEA
anyway.

~~~
dested
I more meant in the form of tooling, not compiling. The intellisense that it
provides is often incorrect vs VSCode which asks tsc what the intellisense is,
making it always correct.

~~~
jameslk
This is possible if you look closely at the settings for TypeScript in
IDEA/WebStorm:

> _Select the Use TypeScript Service check box to get native support from the
> TypeScript Language Service according to the up-to-date specifications. In
> this case syntax and error highlighting is performed based on the
> annotations retrieved from the TypeScript Language Service while code
> completion lists contain both suggestions from the TypeScript Language
> Service and suggestions calculated by IntelliJ IDEA itself._

[https://www.jetbrains.com/help/idea/2016.2/typescript-
suppor...](https://www.jetbrains.com/help/idea/2016.2/typescript-
support.html#d827982e95)

~~~
softawre
Wow, you're right. This is new by the way, wasn't like this at least in the
1.0 typesript days.

------
HeyImAlex
Typescript is such a neat project. The js ecosystem is vast and diverse and
the typescript team has the unique job of figuring out how to make common
dynamic patterns type-safe and convenient. Like... that's so cool. Every
little pattern like its own type system puzzle, and there's no _avoiding_ the
issue like a ground-up language can do, because their job is literally to type
the JavaScript we write today.

Also, how much money is MS pumping into TS? A lot of OSS has one or two super-
contributors that carry the project on their backs, but typescript has a small
army of smart people with significant contributions.

~~~
IndianAstronaut
I'm still trying to figure out Microsoft's new end game. Major inroads into
OSS, more linux support, VSCode, etc.

~~~
nojvek
End game is be relevant to developers. There's an entire org called DevDiv
whose primary job is to win developer market share. If developers love your
platform and tools, then they won't hesitate to use Azure and the other money
making beasts.

------
bsimpson
Control-flow analysis? I think that was Flow's differentiating feature.

Obviously, there are still differentiators between the projects (like
TypeScript including a known set of transpilers vs. Flow delegating to Babel),
but I'm curious to know if they are converging on their core feature (e.g. how
to do type-checking/static analysis).

~~~
shados
they are. Flow is still quite ahead in term of control flow analysis and
"soundness" features, and the type system in general is much richer, but
TypeScript is catching up. Flow's tooling is getting better (though it still
has ways to go).

It's pretty easy to see where things are going. Advanced type systems (Elm,
Scala, ML, Haskell, whatever) have the features we really need, and tooling
(IDE support, etc) can use that info to provide crazy good tooling, so any
type system developed in 2016 and beyond must have all of these things to be
of mass appeal.

~~~
DanRosenwasser
Hey, I don't see TypeScript as being behind on control flow analysis or
anything like that.

If you're referring to differences in the way TypeScript narrow types based on
control flow analysis, we don't see one as being "better" than the other, but
TypeScript takes a more optimistic approach to avoid putting users in
frustrating scenarios where the analysis is too limited. Most users tend to
prefer this to the slightly more rigid approach used in Flow, so we felt we
made an ideal choice there.

If you have any specific thoughts or ideas, feel free to leave us feedback on
our issue tracker.

~~~
shados
To be fair, it is very, very unlikely that I am better at type systems than
someone working on TypeScript, so anything I'd suggest, you probably heard
about, and is either already on your roadmap, or was a conscious design
decision that we just happen to disagree about :)

I think the javascript type system world is still evolving, and the only
"wrong" thing to do is to say "Ok, its a solved problem, let's run away with
THIS ONE and kill the others".

As long as we still have at least 2 reasonably well known ones, I'm happy.

------
jameslk
One of the things I've been really needing is buried in the wiki:

> _Previously flagged as an invalid flag combination, target: es5 and 'module:
> es6' is now supported. This should facilitate using ES2015-based tree
> shakers like rollup._

So now I can add rollup to my production build pipeline to remove dead code.
Nice!

~~~
jarjoura
Wow TIL, I had no idea this was a thing! It looks amazing!

------
ggregoire
TypeScript is so strange for me. Each time I read something about it, I want
to give it another try... then I read some codes and I just can't go further.
I like JavaScript as it is, without types on every line of code.

Unlike most people on HN, I like JavaScript. I build web app since 2011. I
liked working with jQuery, then Backbone and Grunt, then Angular and Gulp. Now
I'm working with React, Webpack and Babel (ES6/ES7) and writing web apps has
never been so much pleasure. JavaScript in 2016 is really fine for me. And the
common point in my JS experience from 2011 to 2016 is that dynamic typing has
never been a problem. I also worked with strongly typed languages for years
like Java or C# and I still prefer the flexibility of JavaScript.

So it's strange because I admire TypeScript. The work accomplished by its team
is really amazing. And it's so nice to see a single library reconcile
developers with JavaScript. But in the other hand, I prefer keeping my JS
without types because it just works fine for me and the teams with who I
worked.

~~~
hasenj
Have you tried starting a fresh project with just TypeScript?

I have no idea how your brain works, but for me working with a non-trivial
JavaScript codebase is a nightmare.

TypeScript makes web development fun again.

~~~
the_duke
Yeah.

Every making even a small change to a JS codebase you haven't touched in a
while that isn't VERY thoroughly tested? (Doesn't even need to be a big code
base).

Thinks will break. And you will lose hours of time.

Static typing doesn't eliminate all bugs, of course. But it can catch many
common mistakes made in JS.

~~~
pekk
If you don't have tests, why do you think your code works?

~~~
the_duke
I never said write no tests.

But static typing catches a lot of things otherwise only caught by tests.

Also, try Haskell. Haskell code that compiles works correctly sursprisingly
often. ^^

------
qwertyuiop924
Man, I feel like the only one here who doesn't really like static types. I
like dynamic typing just fine (it's crazy, I know: it must be the lisp
influence). And if I want static typing, TS feels a bit intrusive. Flow is
much better in this respect.

I also don't think JS is the root of all evil, and I use Emacs rather than an
IDE (although we do have _really_ good integration with regular JS, in the
form of the famous js2-mode, and flycheck's linter integration). I, mean, do
you _really_ need your IDE checking your types as you type? It's not _that_
slow, and us Emacs users have M-x compile, so we can run our code, and than
jump back to the problematic line when an error occurs, and I know IDEs have
similar functionality.

Don't get me wrong: static typing can be good at times, and option static
typing and compile-time type analysis are useful tools, and I'm glad TS, Flow,
and the like exist. But I always see a flock of comments saying that they
couldn't possible live without static types, and thanking TS for taking them
out of the hell of dynamism, and wishing there was something similar in
Ruby/Python/whatever.

I don't really get that.

~~~
pixie_
On the other hand I don't understand how anyone can work with a code base that
is dynamically typed. I'm looking at a function parameter in a random file.
How do I even begin to work with it?

Unless you wrote the code yourself you pretty much have to run the program
first and then REPL to see what the type actually is and the properties it
exposes Slow, arduous, unnecessary.

Also especially in the early stages of any development project I am
refactoring like crazy as things come together. Static typing enables
refactoring operations that are lightning fast with almost zero chance of
error. Refactoring in any dynamic language is super error prone and leaves
open the possibility for bugs that often show up unexpectedly at runtime.

Do people who prefer dynamic languages actually use the benefits of dynamic
typing in the first place? Changing variables from one type to another mid-
stream. Dynamically adding properties to objects, using == instead of ===
etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability
right from the get go.

Static typing doesn't feel intrusive, it feels like a flashlight. I don't like
coding in the dark, feeling around for what everything is or is not.

~~~
stcredzero
_Unless you wrote the code yourself you pretty much have to run the program
first and then REPL to see what the type actually is and the properties it
exposes Slow, arduous, unnecessary._

If the code is well written, then no, to seeing what the type actually is. In
a good environment like you have in many Smalltalks, you should be able to
compose some implementors searches, then quickly know what you're dealing
with. Then you _quickly and easily_ debug the system just to be rigorous. In
environments set up by smart people, these actions can be surprisingly quick
and easy. (In the same way that git allows for using certain information much
more quickly, quantity can become a different quality.)

 _Do people who prefer dynamic languages actually use the benefits of dynamic
typing in the first place? Changing variables from one type to another mid-
stream. Dynamically adding properties to objects, using == instead of ===
etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability
right from the get go._

None of those things are the benefits of a dynamic language, except maybe as
super debugging tricks. No one who really knows how to write in a dynamic
language puts stuff like that in typical code! That you say this makes me
think you don't know what you're talking about, or your main exposure to
dynamic langs has been through the code of yahoos.

~~~
FrancoDiaz
_If the code is well written_...

 _In a good environment like you have in many Smalltalks_...

 _No one who really knows how to write in a dynamic language puts stuff like
that in typical code_

That's the problem. You're talking about some hypothetical, Smalltalk
environment, where some expert dynamic language programmers always do "the
right thing".

~~~
qwertyuiop924
Okay then, but if you're not documenting your functions, which is the most
important thing, you shouldn't be working on a large project with other people
in any case.

~~~
mercurial
Documentation will not save you the day you decide to rename a function or
change its signature. Static typing will.

~~~
qwertyuiop924
...No, it won't. It might make the refactoring a little easier, but with
various tools, you can check all the call sites and see if you fixed it. Sure,
your compiler won't tell you what's wrong, but your REPL and your tests will.

~~~
FrancoDiaz
Yes, given enough time for enough manual work, and enough tests, and enough
code review....

The whole point is not to have to do this stuff manually, which is very error
prone. Ad-hoc REPL work, and tests are very likely to have missed something.

~~~
mercurial
Precisely.

------
easong
I really wish that MS would release typescript as a collection of plugins for
babel that would handle only one thing at a time (eg, the type system). Having
my production build, es6 transpiler, type system, JSX compiler and so on
(including a bunch of features I would rather didn't exist at all) all in one
package feels like a failure of separation of concerns.

I understand that people find Babel's plugin ecosystem confusing and
intimidating (it is), but I don't think a separate monolithic typescript that
reimplements popular babel functionality is the answer.

~~~
hasenj
I'm actually glad they release TypeScript as a completely integrated and
standalone solution.

~~~
easong
It definitely has advantages. But I don't think using babel precludes shipping
a binary with a standard pre-built config.

------
sdegutis
> _In TypeScript 2.0, null and undefined have their own types which allows
> developers to explicitly express when null /undefined values are acceptable.
> Now, when something can be either a number or null, you can describe it with
> the union type number | null (which reads as “number or null”)._

Great news, but I suspect it's going to be pretty difficult to migrate large
codebases to account for this properly, even with the help of
`--strictNullChecks`. Sounds like days worth of tedious work analyzing every
function.

~~~
klodolph
Yes, although the same can be said for the "no implicit any" flag when
migrating from code bases EcmaScript. They seem to be doing a pretty good job
of supporting both legacy and greenfield projects.

~~~
k__
Yes, I tried "no implicit any" and got nothing working. Problem were mainly
3rd party libs with out-dated, bad or no type definitions.

Is it even possible to use these flags with production code?

~~~
RyanCavanaugh
We've removed nearly all the implicit anys from DefinitelyTyped, so if you're
getting definitions from there, you shouldn't see any.

We don't have good data on this but my perception from talking to people on
GitHub is that the vast majority of people using TypeScript run with 'no
implicit any' on once they get their codebases converted.

(I'm on the TypeScript team)

~~~
johnny_reilly
And even if noImplicitAny in 3rd party libraries is not honoured you now have:
skipLibCheck which will limit checks to your own code. Details here:
[https://www.typescriptlang.org/docs/handbook/compiler-
option...](https://www.typescriptlang.org/docs/handbook/compiler-options.html)

I believe it's actually a perf gain to run with this set (but I'm not
certain).

------
oblio
Highlights:

* npm replaces typings/tsd

* non-nullable types (has to be switched on)

* better control flow analysis (à la Facebook Flow)

* read-only properties

------
smithkl42
Huge TypeScript fan here - been using it since its 0.8x days. And I'm very
interested in the new --strictNullChecks compiler flag. But I'm trying to
implement that on our current codebase, and I'm coming to the conclusion that
it's still a bit premature. There are a lot of very common and harmless JS
(and TS) patterns which this breaks, and for which it's been difficult (for me
at least) to find a workaround.

Turning on --strictNullChecks flagged about 600+ compiler errors in our 10Kloc
codebase. I've addressed about half of those so far, and I can't say that any
of them have actually been a real bug that I'm glad got caught. On the
contrary, because of the weird hoops it makes you jump through (e.g.,
encodeAsUriComponent(url || '')), I'd say that our codebase feels even less
clean.

~~~
evmar
One counterintuitive observation about introducing stricter type checking into
an existing codebase is that it rarely finds bugs. Why? Because the existing
codebase typically "already works", in that issues that the type checker might
have found were already discovered through automated (or manual!) testing.

The real value of more strict type checking is when writing new code -- you
won't need to spend as much time discovering bugs in development or writing
tests for issues the compiler is catching.

~~~
smithkl42
Good point. And I can see that I would have made different (and probably
cleaner) design decisions in certain places if strict null checking had been a
part of our code from the beginning.

------
Arnavion
Hmm...

    
    
        $ npm view typescript 'dist-tags'
    
        { latest: '2.0.3',
          next: '2.1.0-dev.20160922',
          beta: '2.0.0',
          rc: '2.0.2' }
    

Yet
[https://www.npmjs.com/package/typescript](https://www.npmjs.com/package/typescript)
says

>typescript published 5 months ago >1.8.10 is the latest of 447 releases

~~~
FrancoDiaz
I guess that page just hasn't been updated yet. npm i -g typescript@2.0 will
give you 2.0.3

------
leeoniya

        class Person {
            readonly name: string;
    

couldn't they have just reused `const`?

~~~
RyanCavanaugh
`const` applies to a binding; `readonly` applies to a property. The difference
is important because you can alias a mutable property through a readonly
reference (thus observing two different values from the same reference if
someone with a mutable handle on the object changes it), whereas a const will
_always_ have the same value because it's an immutable reference to a
particular value/object.

~~~
leeoniya
ah i guess immutable aliasing is useful. then it's more powerful than const
and can replace it wholesale, bindings included.

------
netcraft
I've got to find the time to play and get typescript set up figured out. I've
had several false starts, always running into duplicate type definition issues
and similar problems - looking forward to see if the new @types from npm help
things.

------
Roboprog
Does Typescript have a facility to support partial function application?

Say I have a function of arity 4, and want to bind / partially apply (some
might say "inject") 2 arguments to it to create a function of arity 2, can TS
infer the types of the remaining arguments, or, that the result is a function
at all???

I use partial function application MUCH more than classes in the JS code that
I write. There just seems to be less to need all that "taxonomy" related
refactoring.

"Stop Writing Classes", "Executioner" in "The Kingdom of Nouns" (not!), and
all that sort of thing :-)

~~~
Roboprog
For those of you unfamiliar with partial function application, it's a good way
to replace many classes that consist of nothing other than a single "do the
work" method and a constructor or setters for the configuration/dependencies
with a single function.

You put the configuration / dependency parameter(s) first, and the more
"volatile" parameter(s) last. Rather than having a constructor call, you
partially apply the things you want pre-bound (config, deps) to create a new
shorter function that acts as the "do it!" method.

E.g. - write a function to send emails. Put the "reply to" parameters first.
Partially apply that data. Use the resulting function to send emails to
specific people. Bind on the distribution list name argument. Use _that_
function to send alerts to those recipients. Bind on the content of an alert.
Use _that_ to send an alert when needed, without having to come up with any of
the input, just the 0-argument function. Overloading, alternate constructors,
subclasses??? Screw that. As long as the parameter order is reasonable (least
to most volatile), there is seldom anything to be "refactored"

"Currying" just means that you apply a single argument at a time, until you
get down to an "arity 1" function, after which the final argument runs the
original function with the last remaining argument, rather than returning an
"arity 0" function. Here is an example library that does _A LOT_ of currying:
[http://ramdajs.com/docs/](http://ramdajs.com/docs/)

If I apply/bind a function to my higher order function, is that dependency
injection, or subclassing? Who cares.

I like arity 0 functions. They make nice event handlers.

I have been gradually converting to Javascript for the last 8 years. My
paradigm has definitely shifted. I know how miserable static OOP is, and _won
't_ be going to my grave not knowing :-) (here's the quote:
[https://www.facebook.com/groups/nodejsis/permalink/142940052...](https://www.facebook.com/groups/nodejsis/permalink/1429400523804671/))

~~~
Roboprog
I suppose this is orthogonal to compile time types, but I had to write my own
utility to support PFA "decoration" of functions. It of course knows nothing
about the number or type of arguments in the original function. (I usually
write JSDoc comments about resulting intermediate functions if they leave the
nest)

For TS to do this, the compiler would need to supply the "apply"/"bind"
feature and track that a function goes in, and the list of argument types, so
it can check what is applied and track the types of any remaining arguments.
Doable, but if it's not built into the compiler, I have to start running a
transpile process that buys very little for much of my code.

------
equasar
Awesome release! Yet, I'm still waiting for 2.1 to bring finally async/await
generators.

~~~
kimsk112
Have you tried transpiling to ES6 and then use Babel?

~~~
egeozcan
It's "yet another 'transpilation(?!)' step". I currently use this combination
but I would be way happier with just Typescript as in the current config the
lag becomes noticeable.

~~~
kimsk112
If you use webpack, you could just add ts-loader as a first loader and babel-
loader as a second one. Source-map works great too.

~~~
johnny_reilly
Yup - though you need to make use of lib if you want to write es2016
TypeScript and have Babel transpile it. Not too hard to get set up though:

[http://blog.johnnyreilly.com/2016/09/typescript-20-es2016-an...](http://blog.johnnyreilly.com/2016/09/typescript-20-es2016-and-
babel.html?m=1)

------
mhd
Seems the spread operator (a roadblock for a lot of JS interop) will have to
wait until 2.1.

~~~
ihsw
I'm currently using the spread operator liberally. Why do you think it's
unavailable?

~~~
tomduncalf
It's available in JSX but not outside that scope, e.g. const { name, ...rest }
= person; won't work

------
macspoofing
Why choose "readonly" as the modifier for immutable properties? A little long,
no?

~~~
RotsiserMho
Probably consistency with C#.

------
zem
typescript is a nicely conservative set of extensions to javascript, but if
you're willing to venture a bit further afield, redhat's ceylon
[[https://ceylon-lang.org/](https://ceylon-lang.org/)] is well worth a look.
it has an excellent type system, and seems to be under active development,
particularly in terms of improving the runtime and code generation.

i played with it for a bit before deciding that for my personal stuff i prefer
more strongly ML-based languages, but if i ever have to develop and maintain a
large team project i'll definitely give ceylon a very serious look.

------
ihsw
Still no async/await for ES5 build targets, but other than that a plethora of
excellent new features.

~~~
mohamedhegazy
async-await transpilation for ES5/ES3 target is already available in the
nightly drops of TS (`typescript@next`).

------
grimmdude
I gave TypeScript a try but honestly thought it was more trouble than it's
worth in most javascript applications/libraries. Maybe that's just the lazy
person inside me, or maybe my projects aren't big enough to make use of it's
features.

~~~
jawarner
I'm curious specifically what friction you ran into.

~~~
the_duke
The biggest obstacle for Typescript by far is using libraries which have no or
outdated declaration files on DefinitelyTyped.

You can get good at writing the declarations yourself, but it's hugely
annoying.

~~~
oldmanhorton
Well, you don't have to write any declarations -- everything will just be
typed as `any`, which isn't preferable but is exactly what you'd get if you
weren't using typescript.

------
velmu
Aweyissssss!

