I'm going to agree with several of the comments that async/await sugar around generators would have been more welcome than non-nullable types.
Then again, I kind of find TypeScript itself of questionable value over es2016 + stage1 via babel.
Well typescript is first and foremost important for the types system which es6 / babel do not provide. And since you can have the best from both worlds (es6 + types + babel) - why not :)
Because at runtime, typescript doesn't provide type checking... ie: when interacting with a foreign API... Beyond this, with small, well-organized modules, TypeScript tends to only add boilerplate, and doesn't tend to prevent as many errors as the time to write boilerplate prevents.
I can see why some would like it, I just don't find much value in it.
I agree that type checking at runtime is really important for JS applications. That's why I made this: http://objectmodel.js.org ; it works really well with Babel, and it has non-nullable types by default from the beginning
It's an interesting idea: to have both types and rich configurable pre-processor like babel. Is it viable or would it be easier to use flowtype for types and babel transformers for everything else?
IIRC, flow doesn't/didn't work on windows, which is a non-starter for a lot of users... not sure where this stands now, last looked at it when using flow types to be able to use angular 2 without typescript, as I mentioned, I didn't see the point as I still needed bits from babel.
I am actually using typescript only for types and then passing the code (even with JSX) to babel to do all the cool stuff we know it can do. So async / await is no problemos.
But flow adds type support (same as typescript), and can also be used with babel... flow only does one thing, so better integration. Typescript doesn't offer much beyond types (and flow does that) over babel.. and as you say, you're using babel anyway.