Announcing TypeScript 1.5

What I think is the best part though, and it helps when bringing new people in, is the crazy-good intellisense you can get in Javascript now.

Basically it makes averages developers much better, and skilled developers a bit better. Master level folks may just find some boilerplate generated code annoying, but for my definition of "Master" there aren't many of them around anyway (at least not where I work).

In my mind though, the main benefit is types as documentation, both for devs & tool support. Via DefinitelyTyped it makes integrating new libraries simpler. It has made refactoring much more straight forward. I started a side project on the weekend where I wanted a chrome extension, and I made that a typescript and have absolutely no regrets. I've been doing lots of regular refactoring, and while the codebase is miniscule, it's a lot more mechanical to make changes (change the type, look for red squigglies) than really needing to think about where the changes are.

But I feel like our code is very much much more navigable than just straight JS. Being able to know the type of a thing and just jump to its definition makes it that much easier to read. I might have been scarred by my previous experiences trying to read large dynamically typed projects, but you can't just jump into most files and be able to figure out what is going on (particularly with classes).

We only have one typescript codebase, which we moved to from coffeescript, and that was a huge win, partly because of coffeescript, but also because the coffeescript codebase was a disaster and needed some rework. When I originally ported it, it was about 4k LoC in a single file, and now it is 11k across 93 files. My team wasn't entirely thrilled with typescript to start, but some of the features in 1.4 (union types, typedefs) made people happier. We have some very different coding styles, from my end where I want to type everything, to the any-soup we get in some parts.

So, I can't call it an unmitigated success, some of what the codebase needed was just some general structure, but 11k isn't exactly a huge project either, and it's structure is really not very complicated (most of it is completely independent modules).

So, after all that rambling, things I like:

- code navigability (particularly because anything you do a method call tends to be typed)

- code completion

- refactoring is simple

- catches straight forward bugs earlier, rather than me finding them when I test

So, despite it having types, the main benefit has not really less bugs, it's made my life interacting with the code simpler, and it has made bugs caught by the compiler easier to track down.

I think there was a real missed opportunity to have browser definitions split up by browser version so that you could more easily specify a target set and have it show you when you use something not supported though.

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! ).

The other aspect is that if you're a C# shop it is so similar as to reduce the learning curve. Especially if you want to write OO front end code.

The module/class/types system tends to push you in certain direction for your overall design, compared to a more amorphous vanillaJS.

Even then, the language features don't replace coding rules and discipline. To pick one feature, protected and private members are little more than polite suggestions in typescript, and can be bypassed easily if that's culturally acceptable in your dev team, losing the benefit of well defined interfaces between chunks of code. If Typescript feels generally useless and even a hindrance to a team, it's very possible that team is working outside of the bounds Typescript is meant for. For example, I can certainly imagine a tight knit bunch of crazed coders writing fantastic JS code that really doesn't fit in a java-like development model. If that's the case, you'd probably want to think about why your team migrated to Typescript in the first place, and what you were hoping to gain from it.

The generated boilerplate complaint surprises me a bit. Typescript produces very little extra code, and has almost zero runtime overhead. There's an 5 liner __extends helper function, but that's about it. Most of the time, a line of TS maps to an essentially identical line of JS. I understand that's becoming less true with the fancier syntactic sugar of recent releases, but we're still in the same general ballpark. (and of course, the extra code melts away if you're able to target higher ES versions.)

The learning curve bit really depends on your team's background. Folks coming from many non-JS language will have been exposed to modules/namespaces, classes and types. They will be able to write reasonable code with typescript for a while before even realizing JS has this strange and intriguing prototype mechanism, although it can be a bit of a shock when the day comes, and an ancient JavaScript bearded one sits them down and gives them The Talk about what lurks in the basement.

The main con is that sometimes things are not very clear and you might end up spending time on something that typescript can't handle (eg a function that can return several types of objects, I had to put the return type of the function to any to have it compiled).

The pros:

- being able to refactor stuff easily with the compiler telling you

- catch typos easily (I remember watching Dan Abramov video at react europe and some of the errors he showed would be a compilation error in TS)

- if you maintain all your classes/object definitions in one file (except maybe stuff like state of a React component which doesn't need to be shared), you have all your types at one place and anyone can come in and have a clear view of the project: I had someone come help me on a previous project and it took him basically no time to get a grip on the project structure/models

- DefinitelyTyped so you can also type your calls to third party libraries and what they return

Make sure to only use ES6 imports (no internal modules) and it's pretty close to babel but with types.

The good parts :

* The type system serves as a great safety net and prevents a whole class of bugs.

* Intellisense is far smarter than you would get from JavaScript (no more silly IDEs with both jQuery's .append() and DOM's .appendChild() in the same intellisense suggestion). This enables refactorings and intelligent assistance such as Find All References, which is much more brittle in plain JS.

* Classes are much more convenient and readable than old-school inheritance solutions. Those old solutions were also a huge problem for JS intellisense.

* AMD Modules paired with Require.js are much more centralized than "add these fifty script tags to the HTML document, in the right order". That's more due to AMD, but TypeScript adds some nice syntax sugar on top of that.

* Arrow functions. No more `var that = this` to keep callbacks working.

* Generics, function overloads, etc. - depends on the things you use in your code. If most of your viewmodel properties are Knockout Observables, generics are a life saver. If you're chaining Promises, again, generics can cover their return/param types. Function overloads come in handy if you have factories building objects based on string parameters (example: document.createElement() returns different classes based on the name passed in). And so on.

The bad parts :

* New language to learn. And it keeps evolving.

* Requires an additional build step. There's a large amount of small projects without any build process out there - integrating TS into such a project can be difficult and open a new can of worms related more to the build process than TS (e.g. "do you commit the generated JS and sourcemaps, or provision a build server to package them?"). Of course, if you're already using Grunt/Ant/Phing/whatever else, this is not a big problem. (You should be using a build process at least to aggregate your JS into one blob, if nothing else.)

* Definitions for third-party libraries. DefinitelyTyped helps a lot here, but there are still things that it doesn't cover, and it can be time-consuming to keep a definition file in sync with a library as the library updates.

* IDE support. After using PHPStorm/IntelliJ and Visual Studio Express/Community, Visual Studio wins hands down. IntelliJ's support was quite disappointing and glitchy, especially its lack of intellisense. Visual Studio Code, Community and Express are all free, but the latter two are quite bulky and running them alongside a different IDE can be slow.

* Debugging can be a bit challenging due to sourcemaps, depending on the target browser. I prefer to disable sourcemaps and debug the generated JS directly, but that requires some mental juggling and is not everyone's cup of tea.

To me, simply being able to break up methods into discrete testable modules, then composing those methods into either workflows or structured utilities, you don't need the cognitive overhead of strict typing nearly as much. Unfortunately, going that route takes discipline.

What typescript and es6 tends to bring is cleaner class syntax, which imho is a detriment to the use of JS in most cases. People tend to put things into classes that really don't need to be. You data structures can be plain objects instantiated as needed (generally via JSON passing), and most of your workflow logic can again be a module that is an object which returns a composite of discrete, or at least bound/wrapped functions that themselves are independent and testable.

One thing you should probably strive for in a green project where there is a lot of JS, and multiple developers is 100% test coverage for JS. If you are having serious issues with being able to test your code, odds are your structure needs to be cleaned up. With utilities like sinon and proxyquire you should be able to shim for testing anything a method needs to be exercised.

It's also worth noting that test coverage doesn't guarantee good code, it only ensures that you've looked at every piece of code a couple of times. It's that forced review/refactor for testing that gets you thinking in terms of usability. Filling out an existing software with unit tests without refactoring as you go, only gives you some protection against regressions.

I have totally lost track of where I was going... I guess it just comes down to that, for me, TS brings the limitations in terms of testing that exist in Java and .Net and force them on JS. JS is inherently more easily testable than many other languages.

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.

Is that the official plan? I ask since async/await will presumably be going into the actual JS spec, so I'd expect engines to hold off adding support except behind some kind of warning flag.

TypeScript's benefits include all the generic benefits of type checking.

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...

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

[1] https://github.com/facebook/flow/issues/6

Typescript covers pretty much all the ES6 features that I use while flow is still missing let/const apparently. I only miss async/await and that should be in TS 1.6 so it's not a big deal for me and I believe you should be able to do a TS -> Babel -> ES5 workflow if you wanted by having ES6 as target for TS. For JSX, I prefer using React.DOM anyway but support will be in 1.6 and is already in master.

TS main selling point is DefinitelyTyped which means typing for pretty much all the third party code and the fact that it's been out for a couple of years now. A tool to convert .d.ts to flow definition has been on flow short-term todo list since november and without it, flow is not viable for me.

TS definitely shines when starting new projects though, it can be a bit annoying on a legacy codebase.

(I use Pycharm, not VS and it integrates well in it, minus lagging a bit behind versions)

I've used both Typescript and Flow. In my experience, Typescript is far superior to Flow.

In terms of the sorts of errors they catch, they're about the same. In practice, Flow caught essentially no real errors that Typescript did not, and vice versa. (This is based on my workflow, YMMV obviously.)

However, Typescript is installable through NPM and runs as a basic Node module that reads files and parses text when you call it. Flow is written in OCaml, which means it's not available through NPM. This means either installing a separate binary (if one exists for your system) or installing an OCaml compiler so you can compile it from source. Afterwards, Flow uses a client-server setup, which makes it really annoying to run in a headless and automated environment. It's also surprisingly slow; it took a full ten seconds to typecheck a small project the first time. Supposedly the server makes it faster to do repeated checks, but honestly, the Typescript compiler is fast enough that this seems like a solution in search of a problem.

Also, Flow would keep getting confused and insisted on typechecking my node_modules. This was a problem because one of my imports had a third-level dependency with syntax error in an unused test, which meant that my entire Flow typecheck would fail. I couldn't add it to the [ignore] section of my ~/.flowconfig, because then Flow would literally pretend the file didn't exist, and then the project wouldn't compile due to missing imports!

All in all, I'm sure there's some way to set up flow without running into any of the above issues, but it definitely was way more work to set up (compared to a simple 'npm install'), and for seemingly no benefit whatsoever.

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.

https://www.npmjs.com/package/r-dom

- 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 :-)

If yes, then TypeScript is quite similar to plain JavaScript and introduces this feature you want.

If no, then JavaScript should be sufficient.

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.

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