
Announcing TypeScript 2.0 Beta - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta
======
spriggan3

        let lowerCased = strs!.map(s => s.toLowerCase());
    

I'm not a big fan of this, it's really starting to change JS semantics. It's
not just type annotations anymore + ES6 . It's starting to look like its own
language. Some might like that, I do not.

They should be a bit more cautious before introducing these features. What if
Ecmascript in the future uses ! as an operator for a totally unrelated purpose
? It's like decorators, they are not in the spec, there is no plan yet to
officially had them to the spec, yet, Angular2 which is written in Typescript
abuse them. What if in 2 years they are introduced in ES2019 with different
semantics ? How Typescript is going to handle that too ?

~~~
ihsw
Do you have the same complaints about optional parameters too?

    
    
        let x = (id: number, name?: string) => { return; };
    

Is it abuse to use interfaces as well? They are not present in vanilla JS.

How about React's move away from React.createClass({}) to ES6 classes
extending React.Component? Do they abuse classes?

Async/await is coming too and it will turn JS on its head, does eschewing
callbacks for async functions also count as abuse?

I won't even get into generics as that's a whole different can of worms.

Microsoft and the TS team have issued a mandate that TypeScript will always be
a superset of EcmaScript and if ES2019 includes decorators that are
incompatible with TypeScript's then it will be addressed at that time.

TypeScript was never meant to be just type annotations+ES6, there is Flow[1]
for that.

[1] [https://flowtype.org/](https://flowtype.org/)

~~~
spriggan3
> let x = (id: number, name?: string) => { return; };

hmm, it would make more sense if it was written like that

> let x = (id: number, name: string?) => { return; };

But I guess it's more or less ok. But I definitely feel inconfortable with the
! .

> How about React's move away from React.createClass({}) to ES6 classes
> extending React.Component? Do they abuse classes?

I don't use React.

> Async/await is coming too and it will turn JS on its head, does eschewing
> callbacks for async functions also count as abuse?

The probability is higher for ES to implement async/await than the ! operator.
The former is a safe bet, the latter isn't, by a long shot.

> Microsoft and the TS team have issued a mandate that TypeScript will always
> be a superset of EcmaScript and if ES2019 includes decorators that are
> incompatible with TypeScript's then it will be addressed at that time.

It means that language will break. Not very good if you write large TS
codebases today.

> TypeScript was never meant to be just type annotations+ES6, there is Flow[1]
> for that.

That's your opinion. I'm not interested in Flow.

Ultimately TS is successful because it more or less looks like Action Script
3/ES4/JScript.net and javascript itself. Make it too Alien and the people who
refused to use Coffee script because of its semantics will not want to use TS.
And FYI I use TS today. I may reconsider that.

~~~
spicyj
> I'm not interested in Flow.

Curious: Why not?

~~~
jsheard
I'm not him, but the Flow compiler not supporting Windows is a dealbreaker for
some.

~~~
spicyj
Thanks. The Flow team is planning to announce official Windows support,
hopefully in the next few weeks.

------
ken47
Another interesting addition is discriminated union types:
[https://github.com/Microsoft/TypeScript/pull/9163](https://github.com/Microsoft/TypeScript/pull/9163)

This will greatly facilitate a more functional style of programming.

~~~
MichaelGG
Union types without destructuring/pattern matching seems really strange,
doesn't it? Special casing a certain property name and converting types based
on a string comparison?

~~~
iamdanfox
It's definitely not as elegant as Scala or Haskell, but I think their
justification is very reasonable. The current implementation is maximally
compatible with existing usages of tagged unions (e.g. Redux actions), because
it allows you to choose whatever discriminant you like ('type', 'kind',
whatever). Keeping very close to JS seems to be a core tenet of TypeScript and
is quite valuable in my opinion. It means they can adopt new ECMAScript syntax
without clashes and also ensures that newbies have a smaller learning curve.
Also, they can always add in some syntactic sugar later if they want to!

~~~
lomnakkus
Yeah, the key here is JS-compatibility. Unfortunately, that _does_ mean that
TypeScript is sort of a dead end in terms of how far you can go wrt. the
fabulousness of your code. (Of course, once everything is statically typed
you'll have a much easier time just converting everything to
$OTHER_STATICALLY_TYPED_FRONTEND_LANGUAGE, perhaps Scala.js, perhaps
PureScript, perhaps js_of_ocaml, perhaps even GHCJS if you're adventurous.

(Aside: I'm moderately disappointed the 'fabulousness' was not in my
Chromium's spell checker dictionary. It is now.)

~~~
invaliduser
If by «fabulousness» you mean in terms of static typing, the language may not
meet your expectations, but it seems to me it's a bit harsh to say it's a
dead-end, considering it's on par with many other languages, and still
improving.

Also, sorry if you meant something else, «fabulousness» is a very subjective
term, not unlike «elegant» (as in «elegant code»), and because it does not
have a specific and commonly shared meaning (what is fabulous to you may not
by fabulous to others), it's not something I'm very comfortable discussing,
although I think I have understood what you meant by it, but with a low level
of certainty.

------
knocte
> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just
> means string and number means number.

This is great. However, it would be nice to know if this feature will become
opt-out in the future instead of opt-in. In theory, if you're a TS user (as
opposed to JS) it's because you want these nice features _by default_.

~~~
Analemma_
It's a tough call, and I can see arguments for both sides. On the other side,
one of the big selling points of TypeScript is that you can take your existing
huge JavaScript codebase, and with little effort turn it into TypeScript with
all the types being "any", then gradually add strong types as time permits.
This wouldn't work if --strictNullChecks was the default and would add one
more step to the migration process.

~~~
legulere
`null` and `undefined` are subtypes of `any`, so you can still gradually
convert to typescript.

(according to
[https://github.com/Microsoft/TypeScript/pull/7140](https://github.com/Microsoft/TypeScript/pull/7140))

------
bsimpson
> In 2.0, we’ve started using control flow analysis to better understand what
> a type has to be at a given location.

Sounds like Flow. Curious to see how they converge/diverge over time.

I know there are people who hate the tooling spaghetti that modern JS
development involves, but I appreciate that I can plug Flow into a
babel/webpack stack and have it just do the error checking. I also have high
hopes for things like tree shaking and its ilk that control flow analyzers
(Flow, and now TypeScript) will bring to JS going forward.

I'm sure you could have Babel just do the experimental transforms and pipe the
result into TypeScript, but having two separate sugar/transformation systems
seems not-great.

~~~
whatever_dude
> I also have high hopes for things like tree shaking

They're really starting to put their efforts behind control flow analysis.
They already did a little bit of that before (with type guards), but it seems
they're really serious about it now. 2.0 also adds verification for unused
declarations with `--noUnusedLocals` and `--noUnusedParameters`, so I want to
believe they're moving towards tree shaking.

------
spankalee
There are a _lot_ more features than non-nullable types:
[https://github.com/Microsoft/TypeScript/wiki/What%27s-new-
in...](https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-
TypeScript)

------
sepeth
"Non-nullable Types"

This is the first filter I check when I am deciding to learn a programming
language these days. Almost all real world code I saw have had random null
checks everywhere.

~~~
tracker1
It's one thing I don't like as much in JS, are those times where a number is a
valid input, or a string that is a number, but not null, undefined or other
types of values.

------
jensvdh
This is fantastic. Kind of gutted they delayed Async/Await until Typescript
2.1 releases.

That's the one killer feature I'm missing.

Typescript has been nothing short but amazing though!

~~~
jsheard
In the meantime you can use async with TypeScripts ES6 emitter, which
transforms async into generators, then run the output through Babel to
transform the generators into plain old ES3/ES5. It's messy but it works.

~~~
moosingin3space
How hard is it to automate this and what impact on build times does it have?

~~~
Derander
It's not hard to automate with raw gulp or webpack, but it does add a
significant amount of time to compilation. It roughly doubled our incremental
compile times. My team decided it wasn't worth it, but it's possible that a
cleverer person could decrease the overhead.

~~~
moosingin3space
I ask because I'm debating between trialing TypeScript or Elm for a personal
project (I primarily work in Rust and Go on the backend/infrastructure), and
iteration times are important when trying to get a frontend UI "just right".

~~~
jsheard
You could just use TypeScripts ES6 output directly during development, using a
browser that supports ES6 natively, then add Babel to the build chain for
public builds that need to work on older browsers.

~~~
moosingin3space
Do I generally need to use prerelease browsers for ES6 support? Sorry, it's
been a long time since I've been on the frontend.

~~~
jsheard
The stable versions of Chrome, Firefox and Edge all support ES6 generators.
Safari stable doesn't support them yet but the tech preview does.

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

------
statictype
The control-flow analysis of types is very clever.

I've been slowly switching away from Coffeescript to Typescript and have been
mostly happy with it.

Only thing I still struggle with is grappling the namespace/modules mess in
Javascript that's been inherited by Typescript.

~~~
nathancahill
Is it inherited from JS though? I was under the impression that Typescript was
doing their own thing (like /// <reference)

~~~
DougBTX
TypeScript picked up a few features that were ultimately removed from JS at
the draft spec stage, AFAIK the xml style references were never in a JS spec,
but the convention has been around a while. TS also supports import etc.

~~~
nathancahill
The thing that bugs me the most is the inconsistent implementation of default
imports with ES6. Makes it hard to work with a lot of libraries.

------
jameslk
> This release includes plenty of new features, such as our new workflow for
> getting .d.ts files[0]

Does this mean that using Typings is no longer necessary, or is there some
additional benefits that Typings still offers?

0\.
[https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-f...](https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-
future-of-declaration-files/)

~~~
renke1
Also, for me it's still unclear how versioning is handled. It always seems
like you have to use the latest version of the .d.ts and hope it works with
your actual package version.

~~~
DanRosenwasser
`.d.ts` packages should align on major.minor version numbers, so you'll be
able to snap to a version and update appropriately.

------
neals
So how are you guys building TS for web apps? I've been using VS Code, putting
classes into namespaces and it builds with commonJS, which I concatenate into
a single file that I load into a website.

That last part is in need of change because you're not supposed to concatenate
commonJS. So how have you been delivering your code to the browser?

~~~
stupidcar
We're experimenting with using TypeScript 2.0 for compilation, and webpack 2
for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax
to ES5, but to leave the module statements (e.g. import and exports) as ES6.

Webpack can then analyse your ES6 module tree and perform "tree shaking", a
form of dead code elimination where unused modules are excluded from the
compiled bundle. This will become increasingly useful as more libraries are
authored in ES6 / TypeScript, as it will allow you to import the whole of a
framework like Angular or React, but only ship the parts of it that you
actually use in your application.

~~~
stupidcar
And I wanted to add that, while webpack can appear a little intimidating at
first, it's actually very easy to setup, and in many ways much simpler than
the kind of jerry-rigged concatenation and minification workflows we used to
build with Gulp and Grunt.

------
z3t4
Never make _clever_ use of undefined in JavaScript, as it will always result
in a bug when someone decided to be a good citizen and gives the variable a
value at the same time it's declared.

Always be explicit, like var foo=-1; if(foo!=-1) instead of only var foo;
if(foo). It will also help the optimizer

------
nachtigall
> null and undefined are two of the most common sources of bugs in JavaScript.
> Before TypeScript 2.0, null and undefined were in the domain of every type.

So true. Happy to see this. Makes me think of how Rust works.

------
hjalle
Id love too see partial classes.. It would be so helpful combined with
generated classes. Do anyone know any alternative to partial classes with the
same functionality as partials in C#?

~~~
purplerabbit
Check out this:

[http://justinfagnani.com/2015/12/21/real-mixins-with-
javascr...](http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-
classes/)

Might provide you with some functionality you're looking for. Since TypeScript
is an es6 superset, I'm assuming this will work in that context.

------
out_of_protocol
Explain please, why anybody would want both null AND undefined?

~~~
Crespyl
Similar to why you would want to have both false and 0; it is possible to have
a situation in which you wish to define something as explicitly being null.

I do think it's a little weird, but it's useful to be able to say that "this
key exists and its value is null" as opposed to "there is no such key".

~~~
Matthias247
I thought about that too, but this breaks down once you realize that setting
obj.key = undefined; will mutate an object into something which is neither
"the key exists and its value is null" nor "there is no such key". The
difference can e.g. bite you in things that iterate over the keys of an object
or function that do that internally (like deepEquals implementations).

I guess in TS2 there would now also be a difference between a field defined as
key: string | null | undefined and a field defined as key?: string | null |
undefined, because the first one requires setting the key to one of the values
on initialization and the other one not.

