
Announcing TypeScript 2.1 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2016/12/07/announcing-typescript-2-1/
======
timruffles
If you still haven't given TypeScript a go as a Javascripter, now is a great
time to do so.

Whether you end up adopting it or not, it's interesting to get the types out
of your mind and into the code. The first time you feel the speed/confidence
of refactoring with accurate 'Find usages', you'll decide if the undeniable
overhead of types is worth it.

~~~
ryanSrich
Can anyone weigh in on TypeScript vs Elm?

~~~
johnfn
Elm is really cool language that's pushing a lot of boundaries. Use it for
learning or for small projects.

TypeScript is a highly practical and pragmatic language. Use it for anything
serious.

~~~
riffraff
what boundaries do you think Elm is pushing as a language?

It is a cool language and platform, but to me it looks like with time it has
actually become more conservative.

TS on the other hand appears to contain some interesting new things on each
release (possibly too many). Case in point, Lookup and Mapped types in 2.1
seem like a brilliant idea.

------
edblarney
After trying TS, I basically never want to write JS again.

I know that 'OO' and 'typing' is not the solution to everything ... but aside
from all the nice things you can do in TS ... the 'enforced architecture' of
OO-ish paradigms, combined with typing, and essential obfuscation of the
prototype paradigm ... has cut the time to development in half.

I can hardly think of a reason to use JS now that TS exists.

Of course - there are some reasons, in some specific situations, but by and
large, TS is the future.

~~~
twfarland
I've stopped using those OO-ish paradigms in JS (no 'this', 'new',
'prototype'), but even still, have much preferred using TS. You can get a long
way (and have great flexibility) with only interfaces and generic functions.

~~~
boubiyeah
Same, it's so much saner. classes or prototypes bring nothing but troubles to
the table, except when you want to have tons of objects in a memory efficient
way in library code.

TS does a great job without OO thanks to structural typing.

------
zdragnar
It's interesting to me that all of the initial reactions I've seen to this
announcement have been around the introduction of async and object spread,
which are available with babel, but the typescript specific features such as
mapped types are completely ignored.

I don't really have any particular meaning behind that observation, only that
it tickled my funny bone a little bit.

~~~
Longwelwind
Maybe it is me, but I feel like mapped types and keyof are terrible features,
and using them would be a sign of a bad design/architecture.

In general, I don't think using a string that represents a static symbol (such
as the name of a var, an attribute or a class) is a good idea.

I try to keep a simple stack (Typescript + NPM at the moment), and I prefer to
wait for Typescript to have the feature I want, than to install a new
dependency (Babel, for example) to my project.

~~~
klodolph
I think there are two main kinds of developers who use TypeScript. Some
developers come from traditional statically-typed languages, like
C#/Java/C++/etc, and expect the language to conform to their idea of "good
design". For these developers, "mapped types" are "not good design". Other
developers come from JavaScript, Python, Ruby, or other duck-typed languages
and think, "I know that this object is just a dictionary underneath it all,
and I want a type system that lets me write code with that foundation." These
developers want additional safety but they see traditional type systems as
handcuffs.

These are two very different styles of programming, and TypeScript does a
fairly good job of serving both groups--it would have to, in order to be as
successful as it is. There are a ton of useful JavaScript libraries out there
which couldn't easily be rewritten to conform to some Java-style type system,
and there are a ton of skilled Java/C#/C++ engineers out there who don't want
their name on a bunch of cowboy code.

I don't think this cultural division is going to go away any time soon, so
it's in our best interest to believe that people in the "other camp"
(whichever camp that is) are skilled and conscientious developers. I'm sure
you've heard the arguments by dynamic language lovers who talk about how
restrictive/slow/painful it is to write in a static type system, and I'm sure
you're as tired of that argument as I am.

~~~
stcredzero
_I 'm sure you've heard the arguments by dynamic language lovers who talk
about how restrictive/slow/painful it is to write in a static type system, and
I'm sure you're as tired of that argument as I am._

At this point in time, it's a bit of a false dichotomy. It just amounts to a
programming tool based on a form of meta-data. Of course people are going to
have different ideas about the cost-benefit of that tooling. Of course, people
are going to have differing opinions on how much of that tooling is
worthwhile. Most of the problems with online discussions about this kind of
tooling, come from people forgetting that it's just a discussion about
tooling.

~~~
klodolph
I don't think this is a false dichotomy. There's definitely a spectrum between
static and dynamic type systems, and plenty of people who identify with either
camp. Calling it "tooling" changes the name of the problem, there are still
people who will complain when they think the tooling is going in the wrong
direction, and those complaints have merits because so many of us will be
forced to write code in a style we don't like.

~~~
stcredzero
_There 's definitely a spectrum between static and dynamic type systems_

The key word is spectrum.

 _and plenty of people who identify with either camp._

What does it mean when people take something that's actually a spectrum, then
divide that into two opposing camps? Does this sort of activity generally get
public discourse closer to the truth, or farther away from it? It usually does
the latter, in my experience. Hopefully, someone has set that knob to a
position that works pretty well, and things work out.

 _those complaints have merits because so many of us will be forced to write
code in a style we don 't like._

Just who gets to write code in exactly the style that they like? From what
I've seen, people generally make compromises, or they found the "perfect" job,
or they are the one running the project, or they are going rogue and doing
their own thing and introducing inconsistencies into a project's codebase.

~~~
klodolph
Honestly, I feel like I am on the receiving end of some moralizing here—when
someone tells me that my language "brings public discourse farther away from
the truth" I wonder how I could have offended them so deeply.

The difference between a dichotomy and a spectrum is itself a false dichotomy.
Ask any biologist what a species is, and they might stammer out some kind of
weaselly definition full of hedges, and that same biologist might turn around
and publish a dichotomous key which tells you how to identify a particular
species according to an easy set of rules. The same goes for politics, human
sexuality, and yes, type systems.

So I'm not going to hedge myself when I say that people "identify with either
camp". They do. Neither is it a contradiction when I say that there's a
spectrum. And when I say that there are two main kinds of people—I hope that
my reader understands that I'm not a robot, and that I don't actually think
that type systems are some kind of strict dichotomy.

> Just who gets to write code in exactly the style that they like?

I could point out that, again, like/dislike is a spectrum and not only a
dichotomy. See above discussion.

~~~
stcredzero
_Honestly, I feel like I am on the receiving end of some moralizing here—when
someone tells me that my language "brings public discourse farther away from
the truth" I wonder how I could have offended them so deeply._

Please re-read. I never said your programming language "brings public
discourse farther away from the truth." Otherwise, please provide a quote.
What I said is that some discussion about language "brings public discourse
farther away from the truth."

I just re-read, and perhaps you are talking about human language. Also, no,
I'm not offended. I'm just making an observation about how talking about
things in a certain way can shape thought in non-beneficial ways.

 _Ask any biologist what a species is, and they might stammer out some kind of
weaselly definition full of hedges, and that same biologist might turn around
and publish a dichotomous key which tells you how to identify a particular
species according to an easy set of rules. The same goes for politics, human
sexuality, and yes, type systems._

When I encounter political discussions online, I sometimes have a person
pattern-match something I've said, then declare all of my political beliefs
for me. In those situations, false dichotomy -- or rather unawareness of the
spectrum -- has distorted someone's thinking away from the truth.

I suspect this happens to Golang a lot. Basically, the Go language designers
seem to be heavily into the Pareto Principle. So they are very willing to have
a quite barebones level of tooling, and leave a lot of features out. This is
especially true for their type system. They seem (to me) to have succeeded in
getting most of the benefits of a type system while minimizing the
disadvantages, while having much of the "feel" of a dynamic language, while
also avoiding most of the downsides. It's a kind of pragmatic minimalism I've
only encountered before in dynamic languages like Clojure, Lua, and Smalltalk.

------
jensvdh
Typescript is a game changer for any serious project. Never going back to
plain JS.

~~~
edblarney
Concur.

I am basically 'anti religious' when it comes to software.

So many people argue back and forth about this or that, and 80% of arguments
are academic and effete (this is what I mean be 'religious').

But I'm a big supporter of TS because I believe 'it makes sense' on almost
every level.

I'm not a 'big supporter' of many things at all, if any.

I understand the limitations, and that it enforces some things for which we
may want more flexibility ... but overall, I have to say I can't think of any
reason ever to use JS again.

My hope is that V8 etc. build engines to run TS directly as opposed to having
to transpile.

------
Noseshine
Question:

Is it possible to have a setup with TypeScript where it is guaranteed that no
code changes occur other than removal of the type information?

I started using Flow, found what it can and can't do and would like to try
TypeScript. But only if I can have "types-only", I don't want my code
"translated" in any way. I'm writing for the latest node.js version and not
for x different browsers, I want to use exactly what that version supports and
have no code-changing steps.

With Flow I use _flow-remove-types_ ([https://github.com/leebyron/flow-remove-
types](https://github.com/leebyron/flow-remove-types)) to remove the types. It
leaves spaces where there was type-related code and doesn't touch the code
itself.

~~~
TAForObvReasons
With flow you can do one better: type comments!
[https://flowtype.org/blog/2015/02/20/Flow-
Comments.html](https://flowtype.org/blog/2015/02/20/Flow-Comments.html)

You actually wrap the type annotations in comments and flow will recognize
them. You can use the source with the type comments in your browser!

As an example, the flow checker will read the annotations from `function f(n/
_:number_ /, s/ _:string_ /) { ... }` but since they are commented in the
source code your JS engine ignores them.

This is amazing for typing existing code, since at every step you are merely
inserting comments into your code. And your existing minification step will
strip them out :)

~~~
thejameskyle
Comments is definitely the easiest way to get doing. But also if you're
already using Babel and ESLint, you can add Flow in very few steps:

1\. Setting up with Babel: (note that if you are already using the "react"
preset you don't have to do anything)

    
    
        $ npm install --save-dev babel-plugin-transform-flow-strip-types
    

Then update your `.babelrc`:

    
    
        { plugins: ["transform-flow-strip-types"] }
    

2\. Setting up with ESLint

    
    
        $ npm install --save-dev eslint-plugin-flowtype-errors
    

Then update your `.eslintrc`:

    
    
        { plugins: ["flowtype-errors"] }
    
    

Then just install `flow-bin` and create an empty `.flowconfig` file in the
root of your repo and you're done. Now you have Babel compiling your code the
same as always and you can use the Flow type syntax, and with ESLint you
probably _already_ have your editor all setup to show you warnings.

We're trying to integrate more with tools like this so you don't have to go
changing your entire workflow. It shouldn't be so hard to add types to your
existing JavaScript code.

~~~
Noseshine
For eslint I'm using plugin "flowtype", and under "extends" I have
"plugin:flowtype/recommended". Do you happen to know what's different compared
to the eslint-flow package you mention? I took the first one I could find,
didn't want to spend hours with the eslint part of using Flow since I was busy
with all the errors reported by Flow during the conversion process.

 _EDIT:_

Ah I think I get it, it's for editors that don't interface with Flow but only
with eslint. Well, since WebStorm has Flow support - even though it's new and
there are a few tickets open - I guess I should stick with the plugin that I
already chose.

------
msoad
We are using async await with 2.1 rc and it works flawlessly. I also love the
keyof, with that we can remove tons of "any" types from our code base.

Amazing work TypeScript team! This release has been a lot of work!

------
tjbarbour
" We _spread_ ourselves thin, but this is the moment you’ve been _await_ ing –
TypeScript 2.1 is here! "

~~~
nojvek
I read that first and I was like "o_O". After reading the rest I was "O_O".
Nice pun.

------
ggregoire
> Object Rest & Spread

Great news! That will finally fix the syntax errors in VSCode. :)

[https://github.com/Microsoft/vscode/issues/1974](https://github.com/Microsoft/vscode/issues/1974)

[https://github.com/Microsoft/vscode/issues/3804](https://github.com/Microsoft/vscode/issues/3804)

------
n0us
I have been waiting for object rest and spread for ages. Thank you to the
maintainers for working hard on this feature.

~~~
k__
Same here. I already used it exessively in JavaScript to prevent mutations and
missed it a bit in TypeScript.

------
ohstopitu
I recently started using TS instead of JS and I've been loving it. I find
errors much earlier and while the tooling could be a bit better, I honestly
find it less exhausting than keeping up with Babel.

------
ng12
Hurrah for object spreads! Time to go grepping for calls to _.default and
_.extend.

~~~
WorldMaker
Also, Object.assign

~~~
Sankozi
Unfortunately

    
    
      newThing = {...thing, propertyName: value}
    

Will always compile, even if propertyName is invalid. The only advantage over
Object.assign I see is IDE support (at least in Intellij IDEA). I will still
use:

    
    
      newThing = Object.assign({}, thing);
      newThing.propertyName = value;
    

This will not compile if propertyName is invalid and is IDE friendly.

~~~
WorldMaker
You should be able to add a type requirement and get the error you are
expecting. Instead of this:

    
    
        let newThing = { ...thing, propertyName: value } // type of newThing would be deduced: TypeOfThing & { propertyName: TypeOfValue }
    

If you add the type requirement the compiler should balk on the propertyName:

    
    
        let newThing: TypeOfThing = { ...thing, propertyName: value }
    

ETA: You'd have the same lack of compiler error if you were instead using:

    
    
        let newThing = Object.assign({}, thing, { propertyName: value })
    

Because Object.assign will also build intersection types by default.

------
garysieling
TypeScript is great. I built
[https://www.findlectures.com](https://www.findlectures.com) over a year,
starting in plain Javascript. Once the codebase was large enough that got
stuck I added TypeScript, and it's been great for isolating defects.

It's nice paired with React (vs PropTypes) because the checking happens a lot
earlier and is much richer.

~~~
mads
Nice site. I know what I will be doing tonight, when I arrive home. Thanks :)

~~~
garysieling
Awesome. Feel free to contact me if you have questions/ideas or if you find
anything you really like :)

------
lacampbell
How does the development cycle work? With plain JS I load up my html page in
browser (chrome) and head to the console to check for errors in the JS. Then I
do user testing.

Can type-script be debugged by a browser on a source code level - ie not on a
transpiled level? If not, I am not sure if it's worth it. And I say that as
someone who is a huge fan of explicit optional typing.

~~~
WorldMaker
There is typically a quick transpile process in the IDE/toolchain of your
choice. Most browser dev tools now support sourcemaps quite well which means
that debugging shows the TS source and breakpoints are set directly there and
typically show error stacktraces with your TS files.

Another option is to load Typescript in your browser and let it transpile
directly in the browser. Sourcemaps in this case are a bit more iffy in their
browser support, but it can be an option for a quick debug cycle if you wanted
to try something like that. Not particularly the fastest idea for a production
app, though.

------
jasonallen
Feels like Typescript is building (or has built up?) more momentum than Flow.

~~~
jiaweihli
Very early on, Typescript cleverly built up an ecosystem around community-
supported type definitions for popular js libraries. This makes type-checking
and integration for those libraries dead simple.

2 years later, Flow is _still_ lagging behind in this area. [1] I'm not
certain, but I think this may be due to Typescript allowing for a external
header-like file while Flow requires inline types.

For this reason I believe, as many other commenters have noted, Typescript has
nearly always been ahead of Flow in popularity.

[1]
[https://github.com/facebook/flow/issues/7](https://github.com/facebook/flow/issues/7)

~~~
Noseshine
I don't understand what you mean by

    
    
      this may be due to Typescript allowing for a external
      header-like file while Flow requires inline types.
    

Flow supports external declaration files. I use them all the time for 3rd
party modules.

~~~
jiaweihli
You're right, this has been added recently and there's also now a community
effort around 3rd party modules. [1]

Though it looks like it didn't become active until after at least 03/2016 [2].

I mention this only because TypeScript has been active in this area since
10/2012 [3], which is in-line with the original intent of my comment - that
Flow is over 2 years (closer to 3.5 years) behind in building this out.

[1] [https://github.com/flowtype/flow-typed](https://github.com/flowtype/flow-
typed)

[2] [https://github.com/flowtype/flow-
typed/graphs/contributors](https://github.com/flowtype/flow-
typed/graphs/contributors)

[3]
[https://github.com/DefinitelyTyped/DefinitelyTyped/graphs/co...](https://github.com/DefinitelyTyped/DefinitelyTyped/graphs/contributors)

------
euroclydon
One thing I never understood with Babel is which features are shimmed in the
output JS and which features are re-implemented?

What I means is: I didn't know how to tell Babel which browsers I was
targeting, and I'm pretty sure that some of their feature implementations do
not feature test the platform before activating, since they were so compiled
in. Is that the case?

Also, do you have to tell TypeScript your target runtime for it to it to use
it's ES3 async/await logic vs. it's ES2015 (which uses generators), or does it
automatically figure it out?

~~~
mhink
They're getting better at describing which features are shimmed, but the
easiest way to check is by running a single plugin on a bit of code and seeing
for yourself.

For instance, I decided just now to check if `transform-object-rest-spread`
included an Object.assign polyfill (because spread syntax transpiles to
Object.assign behind the scenes.)

With the following input:

    
    
      var foo = { x: 1, y: 2 };
      var bar = { a: 3, b: 4, ...foo };
      var baz = new Promise(function(resolve, reject) {
        resolve("quux");
      });
    

I get the following output

    
    
      var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };
      var foo = { x: 1, y: 2 };
      var bar = _extends({ a: 10, b: 11 }, foo);
      var baz = new Promise(function(resolve, reject) {
        resolve("quux");
      });
    

The problem here, (to borrow phrasing from the docs) is that "Babel uses very
small helpers for common functions such as _extend. By default this will be
added to every file that requires it. This duplication is sometimes
unnecessary, especially when your application is spread out over multiple
files."

To solve this problem, many people use the `transform-runtime` plugin [1] as
well. To put it shortly, it replaces inline helper functions (like _extends in
the example above) with imports from an adapter module called 'babel-runtime',
which itself exposes the relevant polyfills (regenerator[2] and core-js[3]).

With `transform-runtime`, I get the following:

    
    
      import _Promise from "babel-runtime/core-js/promise";
      import _extends from "babel-runtime/helpers/extends";
      var foo = { x: 1, y: 2 };
      var bar = _extends({ a: 10, b: 11 }, foo);
    
      var baz = new _Promise(function (resolve, reject) {
        resolve("foo");
      });
    

Notice that the Promise implementation was polyfilled as well.

> I didn't know how to tell Babel which browsers I was targeting...

You might *really like babel-preset-env[4], a new project they just launched.
Basically, you give it a set of browser targets (much like autoprefixer) and
it works out exactly which plugins you need to support the latest (currently
es2015, I think) version of javascript.

Hope that helps! Sorry for going on a Babel-related spiel in a Typescript
thread, couldn't help myself. ;)

1: [http://babeljs.io/docs/plugins/transform-
runtime/#technical-...](http://babeljs.io/docs/plugins/transform-
runtime/#technical-details) 2:
[https://facebook.github.io/regenerator/](https://facebook.github.io/regenerator/)
3: [https://github.com/zloirock/core-js](https://github.com/zloirock/core-js)
4: [https://github.com/babel/babel-preset-env](https://github.com/babel/babel-
preset-env)

~~~
frankwallis
Deduplication of helper methods is now available in typescript too, using the
'importHelpers' compiler option. It will automatically add import statements
to include the helpers from the 'tslib' package, see
[https://github.com/Microsoft/tslib](https://github.com/Microsoft/tslib)

~~~
WorldMaker
Thanks for the link, this was something I was specifically waiting for release
but haven't seen come across in the release notes.

------
ken47
I've been using Typescript for over a year, and the amount of improvement in
that relatively short time span has been incredible. With 2.1, Typescript
shows no signs of slowing down.

------
jtmarmon
Can someone comment on the difference in reliability between using typescript
and a natively statically typed language like haskell or scala? Is there any?
Or is the type safety really as good when you use ts

~~~
sixbrx
One thing you might miss in TS is the ability to just try to check or cast an
object at run-time to check that it's really of some nominal type, or
structurally compatible with some type/interface. TS can't do that because it
doesn't have runtime type information for its types - the types are a compile-
time only thing. TS does allow creating functions that return type predicates,
but that requires your own manual checking as implementation, the type system
can't help you write those as far as I know.

I was missing this mostly for incoming requests. A good solution for me has
been to generate json-schema from typescript interface definitions, using the
typescript-json-schema npm package. Then incoming data can be checked vs the
generated json schemas. Works fine and I get json schemas for api endpoints
from it as well, so no complaints.

~~~
jtmarmon
ahh interesting, that seems like a pretty significant difference. just to
clarify, this means that you wouldn't be able to do things like:

if (my_var instance_of MyCustomType)

in TS, but you could in normal statically typed languages, correct?

~~~
WorldMaker
It's a bit more complicated than that because of JS's prototype-oriented
object system. If MyCustomType is a proper prototype (say you built it with
the class keyword) you can certainly instanceof it. (That said there are
strange edge cases where statically typed class-based object intuition falls
down against prototype-oriented reality.)

The issues tend to start cropping up as you get further into TS-specific types
like generic types. In a statically typed language you can inquire about the
specifics of an implementation of a generic directly, and often even dispatch
directly on that type. JS has no concept of your generic wrapper type and you
need some other flag or logic to determine the runtime type of your generic
code.

------
ihsw
Async/await support for most browsers and node-0.12+ is definitely a welcome
feature, callback hell and tripping over promise chains is definitely one of
the most painful experience in TS development IMO.

------
smrtinsert
Incredible release. Was definitely waiting for the spread/rest improvements as
well as being curious about the async stuff.

TypeScript continues to be for me the clear winner of the alt.js languages.

------
boubiyeah
Congratulation to the TS team. We are happily using it at work, it's such a
tremendous upgrade over javascript, while keeping the entire ecosystem at
hand.

------
seattle_spring
Seems like all of the new features have been available in Flow for quite a
while now.

~~~
manojlds
Flow is not a language

~~~
tomatsu
[https://flowtype.org/](https://flowtype.org/)

    
    
      function bar(x): string {
    

That's not JavaScript.

~~~
thejameskyle
If that's too much you can also do:

    
    
        function bar(x) /* : string */ {
    

No compiling necessary

------
koolba
So can I finally banish babel from my build steps?

~~~
saosebastiao
I did while 2.1 was an RC. It has worked flawlessly and I haven't looked back.

Build and minification is still a pain though...

~~~
jiaweihli
Try webpack, it's fast and the configuration is nearly declarative.

You can also create a separate build task to run a smoke test by directly
calling the ts compiler to compile your code (skipping pre- and post- build
steps). This was a lot faster than I expected.

------
edblarney
Dear TS authors:

Thank you (!) for your amazing contributions. TS is the best new thing in
tech.

That said:

Your linguistic genius is way ahead of the tooling.

I feel as though some of these 'new and cool' 2.1 things are a little bit
intellectual, maybe useful in some cases ...

But getting TS to work in the real world, the various build configurations,
tool-chains etc. - it's still clumsy.

It was difficult to grasp the difference between AMD and other paradigms. I
still have problems with circular dependencies, or rather, things happening
before modules are loaded.

Here's one pain point:

Creating a static attribute on a class and initializing it right there, as in:

class A { static b:B = new B(); }

Means that 'new B()' will get executed right when that module is loaded,
possibly before the module containing B is loaded.

It's ugly, mechanical - but it's not a 'fine point'. I think these are the
kinds of issues which are more likely to hold people back, as opposed to the
lack of some rather fancy new paradigms such as 'Mapped Types'.

Anyhow, keep up the good work. Lovin't it.

~~~
WorldMaker
Your pain point sounds like a runtime problem with your module loader. You may
want to investigate your module loader's issue tracker. (I recommend SystemJS
[and jspm] over AMD these days, for what that is worth. It handles module
loading quite well including all the complexity of circular dependencies that
ES2015 specced and TS supports.)

«I feel as though some of these 'new and cool' 2.1 things are a little bit
intellectual, maybe useful in some cases ...»

async/await and object spread should be useful in quite a lot of places. The
other "intellectual" additions are immediately useful indirectly because they
were built to support object spread (so that object spread types make sense),
even if you don't wind up using the directly (because you aren't writing
complicated type definition files for instance). Even then, you might find a
bunch of uses for the types Partial<T> (partial objects) and Readonly<T>
(shallowly frozen objects).

~~~
edblarney
Yeah, agree with async/await and spread.

------
voltagex_
What's the future of TypeScript in Visual Studio (not Code)?

I've got a project that just silently fails to build in VS - no errors, no
warnings, build successful - but no output.

It seems like the Typescript tools inside VS2015 (even with the latest update)
just aren't ready.

------
hashhar
Really happy with the development pace. I started using it by contributing to
VSCode and was very pleased with the great tooling and sane language and
syntactic sugar.

------
euroclydon
The proposal for async/await is education, to say the least. The specs for
modern and older browser/js-engines are in there.

Turns out they implement two case statements, and handle every possible
control structure.

[https://github.com/Microsoft/TypeScript/issues/1664](https://github.com/Microsoft/TypeScript/issues/1664)

------
mwcampbell
Any plans to add C#-like extension methods to TypeScript? Or is there a way to
achieve the same thing already? I know that a previous suggestion to add
extension methods was closed as out of scope. But maybe it's time to revisit
that, since TypeScript is now doing significant code transformations for
downlevel await support.

~~~
patates
JavaScript already allows you to do something very similar to extension
methods by extending prototypes.

OTOH, a function accepting an object which implements a specific interface as
a parameter will make your code much more easier to extend, instead of
modifying the prototype of a concrete class.

------
nojvek
Would be so cool if the js engines ignored types like python3.

Then I could just write Typescript and run it on node/browser

~~~
tomatsu
That would work except for enums. That's the one simple thing the engine
actually has to do.

~~~
nojvek
JS should just really support enums. Its such a great feature of a core
language.

I wonder if there is any ES proposal for enums.

------
k__
Are there any plans to catch something like this:

    
    
        function f(x: any): T {
          return x
        }

~~~
pimterry
That would defeat the point of 'any', right? It's for variables that you want
to allow to do anything (including be a T) without the compiler complaining.

If you don't want that behaviour, don't given x 'any' type. In that case there
I'd probably use '{}' instead, and then use type guards
([https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-
types.html#type-guards-and-differentiating-types) to convince TypeScript that
it's a T (whatever that means).

~~~
k__
tslint has a rule to prohibit the use of any. maybe this is worth an option
for tsc

~~~
pimterry
Maybe, but I think there's _a lot_ of cases where you want to be able to use
'any' explicitly. Tsc does already have noImplicitAny, so you have to have
opted in to this behaviour.

------
aj0strow
The easier imports solves my biggest issue with migrating an existing project
over. I'd say TypeScript is "ready" now.

The last feature I'd want is an easy way to map nested json into _classes_
rather than interfaces. Anyone know how?

~~~
ubertaco
An approach I've seen is to have each class extend from some abstract base
class (I know, OO blech) that looks like this:

    
    
        abstract class AbstractClassObject {
            constructor(json?: any){
                if (json){
                    this.updateFromJSON(json)
                }
            }
            public updateFromJSON = (json: any): this => {
                Object.assign(this, json);
                return this;
            }
        }
    

That gives you the "magic" just by extending the base, while also allowing
custom behavior for a given class (by overriding updateFromJSON).

~~~
aj0strow
Yeah but assigning doesn't really work for nested classes.

    
    
        class Post {
           id: string;
           user: User;  // <- should be typeof User
        }
    

I was hoping for something like Golang json.Unmarshal.

------
crudbug
Coming from Java land, TS is a life saver for front-end development.

Any plans for .NET Core / CLR backend ?

I think, this will be the silver bullet. TS types should be able to generate
statically compiled bytecode => native binary ?

~~~
dsp1234
You can create TypeScript models from C# already. TypeLITE[0] will generate TS
models using T4 templates. TypeWriter[1] is a visual studio extension that
regenerates TS models whenever you save a file.

[0] - [http://type.litesolutions.net/](http://type.litesolutions.net/)

[1] -
[https://frhagn.github.io/Typewriter/](https://frhagn.github.io/Typewriter/)

------
libria
I like the functionality of

    
    
        let merged = { ...foo, ...bar, ...baz };
    

But I've come to understand ... as variadic parameters in C++, Java and Go.
Wish they'd used another token.

~~~
tomatsu
_Spread_ (for arrays) was added with ES6. This just adds that kind of thing
for objects (ES2017).

    
    
      let a = [1, 2, 3];
      Math.max(...a); // 3
    

If you use that operator in parameters, it's _rest_ (i.e. variadic stuff).

    
    
      function sum(...numbers) {
        return numbers.reduce((a, b) => a + b, 0);
      }
      sum(1, 2, 3, 4, 5); // 15

------
thewhitetulip
I recently started learning JS, and now I am confused between TS and babel.
Can anyone give me a reason why I should use either of the two and when I
should use either of the two?

~~~
pitaj
TS adds a complete static type-checking system, and also will compile down
your bleeding-edge JS language features into supported syntax.

Babel will do the second part.

~~~
thewhitetulip
Thank you!

------
yulaow
Anyone knows any good resources to learn typescript? The tutorials on the
official site are really... bad. Like I would not even call them tutorials.

~~~
stupidcar
I really like the video courses on egghead.io:
[https://egghead.io/technologies/typescript](https://egghead.io/technologies/typescript)

You do have to pay for some of them, but there's some free ones as well.

------
netcraft
another anecdote - ive been using TS2.1 for the last month on three
interconnected projects - a rest api, an express app and also for client side
code in that express app - it has been a great experience. async/await is a
godsend and @types/ makes what used to be a terrible process much more
streamlined and easy. If you have to write JS, typescript is the best way ive
ever found.

------
polskibus
Still no VS 2013 support? We're stuck on 1.8 for a while. It would be great if
they supported VS 2013 at least until they release 2017.

~~~
eropple
So this is totally a hack, but have you tried changing the manifest in the
VSIX (it's just a zip file) and seeing if it installs?

~~~
polskibus
The official installer seems to be an exe, not a vsix, moreover VS2015
requires update 3 so there's probably more to it than just a manifest hack.

~~~
eropple
Ah, bummer. Just a thought. =(

------
haapanen
Awesome! Been waiting for this for a long time! It's pretty interesting how
much code gets generated for just async function() {} :)

------
time4tea
The noImplicitAny flag just doesn't make sense. You changed the new default
behaviour to be the thing you don't recommend?

~~~
mohamedhegazy
`--noImplicitAny` is the recommended flag. It is not set by default to ease
the use on JS code bases.

The new changes makes `--noImplicitAny` require less type annotations; where
the compiler can figure out the type of a variable through following the
control flow.

------
avitzurel
I'm getting a 404 on this. Anyone else?

~~~
avitzurel
nvm. After a couple of tries it's working again

------
daxfohl
Seems like a great foundation to build something like F# type providers on top
of.

------
co_dh
I feel that the lookup types and mapped types are dependent types, am I right?

------
tkubacki
Dart 1.21 is out today too - with generic methods support news.dartlang.org

------
ausjke
Been a Linux developer for ages C# was never my taste, I'm still a bit
Microsoft-hatred as of now(Visual Studio Code is the only item I adopted for
JS development, the rest languages I still use vi/Geany). How tightly TS is
related to C#? That has been the main reason I had not tried TS seriously so
far. Don't want to have anything to do with C#. I know...

~~~
mpawelski
Once sometimes asked me "Isn't Typescript a language for C# developers that
don't know JavaScript" It's unfortunate that people think that TS is similar
to C# just because it came from Microsoft. Flow language is like 80% similar
to TS, but no one says it's similar to C#.

TS is just JS + new features from future JS specification + optional type
system. And optional type system is fundamentally different than the one in
C#, and it was designed to fit well with JS patterns and idioms (structural vs
nominal type system)

If you look at TS code that looks like C#, it's because JS looks like that
(classes syntax, classical inheritance, lambda syntax - it's all ES7 (or
ES2016/ES2017, or whatever it's called now)

~~~
ausjke
Thanks. That makes me feel better and I will give TS a shot this holiday.

~~~
Fifer82
You won't look back! Will look down at others even!

