
Announcing TypeScript 1.5 - pingec
http://blogs.msdn.com/b/typescript/archive/2015/07/20/announcing-typescript-1-5.aspx
======
unklefolk
I would be interested to hear other folks experience with TypeScript. We have
move virtually all of the project I work on over to TypeScript but I am not
seeing metrics improve (less bugs, quicker to fix etc). Gripes include lots of
boilerplate TypeScript being generated and another learning curve for new
starters (nearly everyone knows JS).

What are other folks experiences? Has it helped or hindered?

~~~
drinchev
I started 2 months ago a big project using TypeScript on NodeJS ( I'm
freelancer and I'm building an API Service for a company ).

CONS:

1\. Contribute a couple of times to DefinitelyType repo, because I needed
definitions that doesn't exist or modify existing ones with their updated
versions ( this is really pain in the ass at this point, because you will most
certainly end up using definitions that either doesn't match your version
number or are poorly written ).

2\. Report a couple of bugs to WebStorm 10 team ( I'm eagerly waiting for WS
11, which they say will improve the typescript support ).

3\. Explain to my clients why I am using a beta version of a software for
their precious product ( this is not a problem since today :) )

4\. Sometimes the flexibility of typescript can slow you down a lot if you
want to go deep with the proper typings and interface declarations. I actually
spend a lot of time thinking how to organize my classes and interfaces now,
instead of writing code.

PROS:

1\. Code looks solid and professional ( CoffeeScript on the other - I was so
much faster, but in the end I see not that easy readable code. )

2\. Creating documentation is way easier ( using typedoc ). I never understood
JSDocs as a pro and usually I spend lots of time on properly annotating, which
is unneeded in TS.

3\. There is no need to write `function(options) { if ( !options ) { throw new
Error("Options required"); } }`. this becomes `function(options : Object) {}`.
This removes a lot of boilerplate and really cleans many of those typesafety
checks from your code.

4\. I'm catching far more errors in the compilation phase than ever before (
see 3 ). I'm also not writing any typesafety tests for my modules ( I was so
happy, when I realised that! ).

~~~
AdamTReineke
One thing to note about your third pro (removing boilerplate type safety) is
that if other code outside your TypeScript ecosystem starts calling your code,
the lack of checks could hurt them.

------
moonchrome
I think the critical point for TypeScript will be 1.6 with async/await - at
this point it goes from "nice I have types now" to "OK this solves most of my
problems with JS".

Looking forward to Angular 2 and TS 1.6

~~~
mixonic
Is this (async/await) not just a feature of ES7?

Personally I would love to see the decoupling of TypeScript's type checker
from its transpiler. The ability to use TS with Babel, or Flow with MS's
transpiler, would be liberating and spur further innovation.

~~~
kylepdavis
You can decouple now. Set the TypeScript output target to ES6 and then pass it
all through BabelJS.

It works really well for me and the TypeScript tooling is really good (VS Code
or Atom).

~~~
davidjnelson
How do you integrate this into a webpack build? Run the typescript plugin
first, then the babel plugin? Is there issues using es7 babel stage 0 features
like async/await and decorators if you do this? Thanks :-)

------
pluma
Considering Babel solves most ES2015/2016 needs and has support for flow, what
does TS still bring to the table for people who aren't using Visual Studio?

Serious question. I last looked at TS when it had plenty of warts (e.g.
verbose metadata to make imports work, no real JS API) and since switched to
Babel via JSX+harmony. Flow integrates nicely and seems to be better at
understanding implicitly typed (legacy) code, too. TS's main selling points
seem to be VS integration and Angular's blessings.

~~~
yareally
> what does TS still bring to the table for people who aren't using Visual
> Studio?what does TS still bring to the table for people who aren't using
> Visual Studio?

It doesn't require Visual Studio. Most major IDEs and some text editors have
support either from Microsoft or the developers of the IDE/editor[1].

Also, strict typing (which I consider a huge plus for any long term large
project to help make it sane).

I think it matters (though maybe not for everyone) that Anders Hejlsberg (of
Delphi and C# creation fame) is behind the architecture of the language.

> no real JS API

Not sure what you mean by that, please clarify. JS notation works fine in it
(since typescript is just a super set of JS and typing is optional). If you
want to add types to a JS library, you just build an interface for it. Lots of
examples of how to do that out there[2].

[1] [https://github.com/Microsoft/TypeScript/wiki/TypeScript-
Edit...](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-
Support)

[2]
[https://github.com/borisyankov/DefinitelyTyped](https://github.com/borisyankov/DefinitelyTyped)

~~~
pluma
> JS API

I mean a JS interface to the transpiler. At the time there was only the CLI,
nothing that worked on strings or streams within node code.

> IDE support ... strict typing ...

Ditto for flow, though.

~~~
AntiRush
The compiler api has gotten a lot better:
[https://github.com/Microsoft/TypeScript/wiki/Using-the-
Compi...](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API)

If you just want string->string compilation, there's typestring, which wraps
the api:
[https://www.npmjs.com/package/typestring](https://www.npmjs.com/package/typestring)

------
michaelwww
When I was coming up as a programmer I had a manager who took a "belts and
suspenders" approach to software development. Adding types to JavaScript is
not necessary, but I sleep better at night knowing my code is that much closer
to being correct.

~~~
jeremiep
I used to feel safe with types as well, until I realized every bug found in
production did pass the type checker and the full test suite.

To me, explicitly managing state and keeping parts of the system decoupled and
simple to understand is now what I require in order to sleep peacefully at
night.

A type system can help with this, but not that much.

~~~
jackweirdy
That's just Selection Bias - the bugs that fail the type checker don't get
into production!

------
euroclydon
I just started a new project. We were using TypeScript for some important
client side communication libraries which had no UI. This new project has a
lot of UI. I chose Babel since it has built-in support for JSX -- that seemed
like a bigger win than type safety.

~~~
tinganho
TypeScript also have JSX support. It's in master right now.

~~~
euroclydon
Thanks...

I found the closed issue:

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

And some docs from the contributor's branch:

[https://github.com/RyanCavanaugh/jsx-
intro](https://github.com/RyanCavanaugh/jsx-intro)

Nothing yet mentioned in the master's markdown. Do you know when the next
TypeScript release is planned for which will include this?

~~~
jbrantly
TypeScript 1.6 will have this. Unknown release date but there is this:
[https://twitter.com/jntrnr/status/620607598903996417](https://twitter.com/jntrnr/status/620607598903996417)

------
tkubacki
Anyone has Dart vs TS comparison ? I'm heavy Dart user - interested hearing
someone having experience in both.

~~~
KajMagnus
I was testing Dart in late 2013, for the admin pages of a hobby project of
mine. But switched to TS because:

\- As of now, TS and JS result in faster pages for me, because with TS and JS
I can use React.js instead of Angular or Angular-Dart, and render the pages
server side. And TS + React is for me easier to make it run fast, also after
page load.

\- Dart makes the fastest browser faster (except on initial page load, see
above), but other browsers slow down, because they need to download the Dart
runtime. This tradeoff feels like a not-a-good-idea, at least not for the
homepage and other pages that should load in an instant for new users. So I
wouldn't be able to use Dart everywhere? And then I'd have to use both Dart
and TS/JS = too complicated.

Minor things:

\- I think I felt a bit annoyed that Dart only made warnings of things that I
would have wanted to be compilation time errors.

\- I like TS better, it looks a bit more like Scala with the `: Type`
annotations.

\- Dart didn't work well in Firefox for me, it felt like boring to try to
investigate what was wrong. (This was in November 2013 perhaps.)

The things I don't like about TS, is that it takes long to compile. And that
it takes a while to learn how to use it — I still don't know much about it
actually. And I haven't found any good free TS editor on Linux. (I'm about to
try Atom I think.)

If it's okay, I'd be interested in having a look at your Dart project? After
all I spent fairly much time with Dart; it would be interesting to see what
other people build with it :-)

~~~
tkubacki
Thanks for sharing!

My Dart thingy is commercial NDA bla bla bla - so the only thing I can say
it's more than 20K LOC. I was always afraid that such a big app couldn't be
mantained in lang without proper IDE on non-windows (for Dart I'm using Dart's
team Eclipse plugin and/or Webstorm plugin).

In my case I'm just too lazy to code in lang without lexical this and as I
understand JS is TS subset, so you still can shot yourself in the foot really
easy, also from what I hear JS/TS is better suited for small projects whereas
Dart shines when project gets bigger (tree shaking, proper SDK) and perf
really matters. On the con side: I would love Dart had as good IDE/plugin as
TS has on Windows (Visual Studio).

~~~
KajMagnus
Do you use Dart for your whole website? How about page load times for the
homepage? Or do you use Dart for pages / things that won't appear until the
user knows what everything is about and is interested already, and won't mind
... 200 extra ms to download the Dart runtime?

Or is it an internal in-company application?

Do you happen to know how many kb JS code gets downloaded to a browser that
doesn't support Dart natively?

(Unless this is too classified :-) )

Yes weird things happens sometimes with JS... a little bit more often with JS
than with TS I think because TS is more restrictive.

~~~
tkubacki
It's Single Page Application used mostly from customer's intranet - currently
around 1.6MB uncompressed (js version) - only initial page load is painful and
takes around 2.3 sec from internet (on my decent DSL). But since it's just
work tool they don't care about page loads that much as they do about feature
completness. I'm using Polymer-Dart on frontned + Dropwizard on backend (these
days I would use Dart on the server side too, but when I was starting it
wasn't mature enough). Overall I'm pretty happy with this tech except I hoped
for faster Web Components adoption (better Polymer support for non-Chrome)

~~~
KajMagnus
Thanks for sharing. Hmm, 1.6 MB minified and gzipped that might mean something
like 300-400kb, which sounds fine to me. _Edit_ Aha you wrote uncompressed — I
suppose the JS was minified already then, and then the bundle will be larger,
okay.

Full stack Dart seems like a good alternative. I wonder how popular it'll
become now when there's Rust, Go and Scala.js too :-)

------
jbigelow76
I consider myself at best a mediocre JS developer, that wants to get better.
I'm interested in TypeScript but worry it would hinder my ability to improve
my knowledge of the core language. I want to know how ES6 improves the
language, not how TypeScript's syntax of ES6 improves the language. I know I
could use regular JS files with TS but if I don't want to do any transpilation
that seems redundant.

Has anybody else felt that way and did you go forward with TS or stick with
vanilla JS?

~~~
kylepdavis
I felt the same until I finally broke down and did it.

Basically, if you want to use ES6 (or ES7) features and are targeting an
environment that might not have native support (browsers) or inconsistent
support (browsers, io.js, node.js) then you will inevitebly need or want a
build step at some point. You could probably get by with some on-the-fly
transpiling for a little bit but I would avoid that as a long-term solution
except for maybe in tests.

I highly recommend setting up a build step in any project for BabelJS to ES5,
TypeScript to ES5, or my favorite, TypeScript to ES6 to BabelJS to ES5.

Not only will you get awesome language features, you will also get some really
great tooling in VS Code or Atom.

Also, it's worth noting that all of these language features are pretty much
all optional so you can ease into them.

------
kolev
I really hate this part:

    
    
        ///<reference>
    

I hope JSX is native in 1.6, too.

~~~
josebalius
+1 I hate the reference tags....

~~~
nippur72
the new version handles tsconfig.json, so no more need for ///<reference>

~~~
kolev
Yeah, that's why I liked the new release although Microsoft recommends the
comment ugliness still for better IDE support, which is nonsensical.

~~~
nippur72
I think VS 2015 (released today) should handle tsconfig in the IDE.

------
cfontes
For those looking for a place to learn it

[https://www.edx.org/course/introduction-typescript-
microsoft...](https://www.edx.org/course/introduction-typescript-microsoft-
dev201x-0)

I am not realted to this site in anyway, I am just using it.

------
verusfossa
What I would love to see is JSdoc annotations being output from the Ts->Js
step. I already add types to everything, my api documentation should be simple
to generate per function. Would be DRY and another feather in Typescript's cap
IMHO.
[https://github.com/Microsoft/TypeScript/issues/10](https://github.com/Microsoft/TypeScript/issues/10)

~~~
nkassis
It would be great if it did.

I heard somewhere that the TypeScript team were also looking at outputting
closure annotation to help the closure compiler optimize TS output.

~~~
Arnavion
Closure supports nullability (and non-nullability) annotations which TS does
not. Otherwise it's fairly straightforward to do this already, with the
current compiler API.

------
aliem
I hope we don't go back to alerts to handle exceptions:
[http://i.imgur.com/ZzvGrsO.png](http://i.imgur.com/ZzvGrsO.png)

I'm sorry, I couldn't resist.

On a more serious note I'll have to see ho it works out phasing it into an
existing, old, hacky (in many sad places) project

------
akst
When I first tried typescript I was disappointed with the lack of support for
ES6 features like destructuring assignment, template strings, and other things
I had in coffeescript.

It's nice to see that this will soon change! I'll be interested to see how
some of my projects in ES6 will translate to typescript.

