
Announcing TypeScript 1.4 - numo16
http://blogs.msdn.com/b/typescript/archive/2015/01/16/announcing-typescript-1-4.aspx
======
spion
TypeScript is pretty amazing. In a few weeks, it turned our node project from
an unruly mess (with tests) to a well organized and compact codebase with nice
interfaces that formalize the various data types that flow around.

We just changed the extensions of all of our files to `ts` and added some type
definition files (most from DefinitelyTyped) to our project; then started
gradually adding types to the codebase. The compiler complains about type
errors, but always generates JS from code that is still valid JS, so the
project was fully operational during the migration.

Once that was done, moving code around, renaming things and changing entire
interfaces became really easy.

The structural type system (basically formalized duck types) is a great fit
for JS, and features such as generics ensure that the typesystem is expressive
enough to model common functional code (no higher kinded types though, look
into purescript for that).

Its not perfect (all types nullable by default; function arguments are
bivariant wrt input/output params and some other weirdness here and there) but
its a remarkable improvement over plain JS.

~~~
mushishi
Agreed. We migrated most of the ES6 codebase to Typescript, and it feels
great.

We have an angular.js app that makes REST calls. The Java backend has DTOs
(data transfer objects) that are mapped by Jackson to json, and after
migrating to Typescript, we also run the DTOs through compile-phase that
generates corresponding typescript interfaces.

i.e.

in Java:

    
    
      public class PersonInfo { // the dto for person
         public final String name;
         public final PersonId id; // we have a class for each id type
         public PersonInfo(...) { ... }
      }
    
      @RestController
      public PersonController {
        
        @RequestMapping("/get-person-info")
        public PersonInfo getPersonInfo(@RequestParam int id) {
          // dummy example
          return new PersonInfo("Peter Jackson", id);
        }  
      }
    

In the java->typescript generator we add the controllers for which we need the
rest API definitions to be generated as typescript interfaces:

    
    
       generator.addClassesFromController(PersonController.class);
    

And when the generator is run, a typescript file is generated with following
definitions:

    
    
        export interface PersonInfo {
            name: string
            id: PersonId
        }
    
        interface PersonId {}

~~~
markelliot
What tool do you use to emit the typescript interfaces? I looked around for
one of these a few months ago but didn't find anything at the time.

~~~
mushishi
It's custom made. We are extracting it from our current project, anyway, so
I'll ask the dev responsible if he would release it as open source project.

------
guscost
TypeScript has been great. With plain JavaScript you have to be outstandingly
organized and diligent to maintain any sort of medium to large project. But
this part of the process tends to get neglected, and eventually a point is
reached where you can either a) break stuff at run-time in unpredictable ways,
b) stop refactoring and deal with the consequences, or c) have a _proper_
suite of unit tests. c) requires almost as much discipline as keeping the code
clean in the first place, and a) or b) are not great options.

Luckily TypeScript helps out quite a lot and basically for free. Converting an
existing JavaScript project to "naive" TypeScript takes hardly any effort, and
as the project evolves it is easy to add type annotations and interfaces at
any pace. Once a module is properly typed it (almost) stops breaking at run-
time, yay! It's also very clear what will be executing in the browser. Using a
cross-compiled language that follows the principle of least astonishment is a
real treat.

Obviously it can't prevent compile-time errors, generate unit tests, or build
a good application for you, but you do get quite a lot of help with the
problems it can solve.

------
gisenberg
Some shameless promotion for a PR I worked on: If you're using the AMD
features of TypeScript, support for named AMD modules also made it out in
TypeScript 1.4. An example of the syntax can be found in the following file:
[https://github.com/Microsoft/TypeScript/blob/v1.4/tests/case...](https://github.com/Microsoft/TypeScript/blob/v1.4/tests/cases/compiler/amdModuleName1.ts)

------
dopamean
I think the union type thing is cool. As someone who has never worked with
something like that before I have to say that I'm not sure I like the
conditional inside the function to check the type. I feel like it would be
cool if there was some other construct to match on the argument type and then
send the arguments to more specifically typed functions.

------
McP
I am most excited about template strings, simply because they let you write
multiline strings.

e.g. instead of

"hello\n" +

"world";

use

`hello

world`;

~~~
evv
But who needs typescript for that?

[http://tc39wiki.calculist.org/es6/template-
strings/](http://tc39wiki.calculist.org/es6/template-strings/)

~~~
judah
That is precisely what TypeScript has implemented: ES6 string templates.
Remember, TypeScript is JavaScript + optional types.

One nice thing about the template strings in TypeScript is you can use those
and still compile to ES3/ES5 for today's browsers.

~~~
TheAceOfHearts
You can compile ES6 for today's browsers too. Check out 6to5.

------
zoomerang
Typescript is really starting to look quite compelling. If we could have null-
safety and ADTs I'd be using it in a heartbeat.

~~~
BrianHV
I'm hoping these features find their way in, too. I was just looking into
their status yesterday, in fact, and came across these tracker threads:

* Non-nullable types: [https://github.com/Microsoft/TypeScript/issues/185](https://github.com/Microsoft/TypeScript/issues/185)

* Sum types: [https://github.com/Microsoft/TypeScript/issues/186](https://github.com/Microsoft/TypeScript/issues/186)

The short story is that there's some interest in both features, but there are
challenges that someone needs to propose a solution to.

------
xxyyzz3d

      TypeScript now supports using ‘let’ and ‘const’ in addition
      to ‘var’. These currently require the ES6 output mode, but
      we’re are investigating relaxing this restriction in future
      versions.
    

Would be quite nice to be able to use 'let', and just use variable renaming to
generate ES5 code with unique names in the case where scopes overlap. I guess
it might be coming?

~~~
Arnavion
Variable hygiene is not sufficient in loops - you have to make IIFE's for
that. Then you have to account that the code inside that IIFE might be
referring to the arguments object of the outer function, so you have to
forward the outer arguments object to the IIFE as well. It's not impossible
but the end result is somewhat gnarly.

------
nine_k
Frankly, use of "typeof" to tell between explicitly named types baffled me a
bit. I hope they'll introduce pattern matching on type some time later.

~~~
Arnavion
The discussion on Github for user-defined type guards (spion's comment) is at
[https://github.com/Microsoft/TypeScript/issues/1007](https://github.com/Microsoft/TypeScript/issues/1007)

Advanced pattern matching, monads, etc. might be out of scope for TS, since it
doesn't want to have major syntactical additions from regular JS.

------
hammerandtongs
Anyone have any guidance on navigating es6 output mode vs where firefox and
chromium are these days?

Ie whats in typescript es6 output that will have issues?

~~~
KwanEsq
Assuming this source is up to date[1] (and I'm reading it right), then the
intersection of chrome ES6 features and Typescript ones is an empty set, while
the Typescript ones are a strict subset of Firefox's ES6 features.

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

------
WhitneyLand
What is the relationship between the upcoming TypeScript 2.0 and ES6? Are they
trying to achieve parity or keep evolving as a superset of standard JS?

~~~
aikah
There will never be "types" in javascript,at most something like "guards" or
runtime assertion checking, but they will never implement typescript type
system. It's too late for that.

~~~
WorldMaker
EcmaScript 4 had a type system. Although ES4 never quite made it to browsers,
there certainly was enough interest to standardize a type system in ES4.
Microsoft is a part of "they" at ECMA determining the ES standard and it is
certainly within the realm of possibility that if TypeScript proves people
want it, a TypeScript-like type system could indeed become standard in some
future EcmaScript edition. In some ways, TypeScript is Microsoft's playground
for things that they would like to see eventually become standard.

~~~
BrendanEich
Indeed we had structural types in ES4 toward the end, and almost bluffed MS
into folding (I'm told by a reliable source). But ES4 was trying for too much
too soon.

At this point we really need to see ES6/7 and TypeScript + Flow "gene-culture
co-evolution". As I said at the last TC39 meeting on the topic, big de-facto
standard wins trump rushed de-jure standards any day.

/be

~~~
cognome
I don't understand the Flow "gene culture co-evolution" part. What do yo mean
by that?

~~~
BrendanEich
Google works, first hit for "gene-culture co-evolution" is

[http://en.wikipedia.org/wiki/Dual_inheritance_theory](http://en.wikipedia.org/wiki/Dual_inheritance_theory).

The analogy is

* core JS standard = genes, DNA in full (mitochondrial [asm.js? :-P] and nuclear [dynamically typed JS]);

* Flow, TS, TS* and other research = culture.

Obviously it's a loose analogy, not an identity. There's no "Red Queen" (sex,
sexual selection), but we do definitely see selection over time via developer
adoption, what wins on performance and ergonomics, what feeds back from the
ecosystem into the core standard APIs.

Also even a few new special forms: generators in ES6 (prototyped in ES4) were
inspired by many experiments; mainly they constitute introgression from Python
2.5+.

JS as an evolutionary kernel ([http://www.cc.gatech.edu/~sakhshab/evoarch-
extended.pdf](http://www.cc.gatech.edu/~sakhshab/evoarch-extended.pdf))
consists of almost totally conserved material (always extended, backward
compatibility required for adoption by developers and competing browsers),
only slowly extended, while diverse languages and frameworks evolve above and
below -- Node.js 14 years after I put JS in Netscape 2, e.g.

Feedback goes both ways, especially in the post-ES3 era where Firefox brought
the browser market back to life. See ECMA-262 later editions (the Harmony era)
rolling up de-facto standards such as Array map/reduce/forEach/etc.

The same feedback could and should happen with a standardized type system of
some sort. It won't happen via design by committee, or picking one winner too
soon.

Type system implementors and the JS stewards must communicate well for this to
win. It's looking good so far, on Ecma TC39: JQuery, Facebook, Netflix, PayPal
(Ebay originally, and again), Twitter all represented along with Apple,
Google, Microsoft, and Mozilla. Also academic researchers from various
universities, all of whom love type systems and theory :-).

/be

~~~
WorldMaker
Masterfully applied analogy. Thank you.

------
tonetheman
How do you update to this version if you just use the node version?

~~~
nvivo
Have you tried 'npm update typescript'?

~~~
tonetheman
I have indeed. And when I run tsc -v I get 1.0.3.0

Maybe that is the stable?

~~~
nvivo
The npm page shows 1.4.1 as latest. Maybe your json file is forcing a specific
version.

