I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it.
I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.
As a language, though, it still leaves a lot to be desired. Things like type guards and null annotations are like the methadone to the vastly more addictive pattern matching and options that I can no longer live without, and promises/callbacks are vastly inferior to futures. I would rather use Scala.js or Elm, but the ecosystems pale in comparison and trying to work in what is effectively an abstraction layer (and leaky at that) makes life really difficult. So I stick with Typescript.
With the latest Node releases and modern browsers supporting generators today, you can target ES6 and use async/await today if you can target those environments.
https://blogs.msdn.microsoft.com/typescript/2015/11/03/what-...
The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclude entire directories. So if I want to simply compile everything in the "src" directory, my best option is to exclude every other directory.
JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awesome.Date`. And there's no way to explicitly reference the global scope, so within those namespaces the new type completely and irrevocably shadows the original JavaScript type.
Also in JavaScript, unless I overwrite the original `Date` type, I can always explicitly scope it by saying `window.Date`. But TypeScript doesn't define `Date` within the `window` type, so I can't use that out either.
Because Date is a data type, not every browser may attach `Date` to the global `window` object. I can't think of one that does not, but it's one of those cases where JS has always been ambiguous.
That said, Typescript is more than happy to let you `(<any>window).Date` assert your way to that global. Or if you feel particularly strongly about this, you could in increasing order of strength of opinion: 1) add .d.ts file somewhere augment window yourself with Date, 2) fork the lib.d.ts and use your own instead of the default, 3) send a PR to Typescript adding it to the default lib.d.ts and see if they have a stronger reason for it not being there beyond it just being ambiguous in the JS language/spec/library.
Yes, and in the transpiled output I will see `Date` turned into `my.awesome.Date` for files within the namespace scope. As I said, JavaScript is always explicitly scoped, so unless you shadow it with a local variable or overwrite the original, you can always access it. So I could easily write `my.awesome.Date` in JavaScript without shadowing the native `Date`, but I cannot do that in TypeScript because of the namespace scoping rules it adds. Which, pains of using TypeScript being the original prompt, seemed quite relevant.
The above sounds negative but TS is still the best bet right now imo. Some people will prefer Elm or Purescript for better type systems but I like staying close to JS.
With regards to types: TypeScript has only recently added support for any kind of Algebraic Data Types whereas Flow was built upon Unions and Intersections from day one. That to me speaks to their priorities.
https://blogs.msdn.microsoft.com/typescript/2015/01/16/annou...
https://blogs.msdn.microsoft.com/typescript/2015/09/16/annou...
They seem to be moving at a decent, agile pace to improving/expanding upon the algebraic sides of the type system.
Thank you for correcting me.
(It will be opt-in as Typescript follows a rule of increasing strictness via compile options to support the spectrum of JS needs, but also as it will not be entirely backward compatible with existing type definition files and will need some effort among typings authors.)
I prefer the idea of Flow as well but tooling and community is not there yet
The fact that last time I checked, it wasn't able to consume TSD signatures from third-party libraries (or offer an equivalent system with a significant amount of libraries) is a much bigger issue IMHO.
When I bring up the latest and greatest (eg. Flow) it doesn't actually work on Windows because Windows is as I see it an after-thought for a lot of the Open Source world.
But I've brought up this exact problem (the lag in tooling) to .Net/Windows devs before and they've told me I'm wrong and that they've got all the latest and greatest dev tooling like everyone else.
1. partial application (bind is typed as 'any')
2. sum type destructuring
3. issues with recursive type definitions
But the Typescript team add new features very quickly so I wouldn't be surprised if these issues are solved in the future.
I was using Visual Studio Community so I had all the benefits of intellisense (which is a big benefit), and I was able to manage a fairly complicated bespoke canvas thingo that suffered a few major refactorings - which I was able to perform with confidence due to the type checker.
The massive list of bundled typings and 3rd party typings makes it much quicker to pick up a new API or remind yourself of one you haven't used for a while.
I now write C# day to day and I find I don't spend the majority of my day alt-tabbing to and from documentation web pages as a result.
So... any bad things to say? None at all off the top of my head. I'm a huge convert, and not because 'it's nice' or 'it's pretty' but because it's like wearing the Iron Man suit when it comes to programming. It's helped me be more productive on non-trivial projects.
You can mix and match dynamic stuff with Typescript, depending on your compiler options, it'll treat non-typed things as if you were writing regular JS.
I always turned on 'do not allow 'any' types' because I wanted everything typed.
As far as C#... there are enough minor differences for it to be rather annoying if you have to jump back and forth every second day. C# is vastly more powerful and convenient as a language to Typescript, though. I'd write C# in the browser if it were a de-facto option, and I used to write and love Ruby. C# has all the functional stuff I doted over in Ruby, and it's all typesafe!
Other than those nuisances, I've grown to like using TypeScript a lot.
Back in my Backbone + CoffeeScript days, I reimplemented Rails style has_many/belongs_to "class methods" on Backbone.Model, and it was incredibly useful. But would've been doubly so if I could have had it statically checked somehow.
Arrays are no longer bivariant, and haven't been for at least a year. They are still covariant unfortunately.
Consider being in the situation of being in charge of a large coffeescript codebase, today. No thank you.
In particular I like how readable and clean CoffeeScript is when you have a long series of callbacks.