Warning: These views are highly oppinated and might have some slightly incorrect facts. My experience with typescript was about 2 weeks in Node and a week in angular2.
TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.
Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, CoffeeScript, the list goes on. If you have a large code base, picking TypeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt.
Its also worth noting that they have built some things like module system and as soon as the spec came out they ditched it and started using that. Have fun updating!
It should also be worth mentioning that this language has been around for a long time and only recently gotten popular because of Angular2.
There is no community really driving the language itself. From what I see, random new things end up there with little to no community feedback. I could be wrong here, but I just don't see it much.
Its like trying to fit a square into a circle hole. A lot of the ES6/7 things I try to do don't work at all and will likely never work with the way some of the types work. I think it should be JS first and then types not the other way around.
It probably doesn't help that the main people that wrote this weren't big JavaScripters before they started but thats just my personal thought.
Babel is the ****! The plugin architecture system is amazing idea! I love being able to get community driven plugins ( Even if they might not be standard thats the risk I accept and am ok with ). I can target multiple environments ( node 4,5 / browser ). Plus, they are implementing specs and even if they are stage-0 and change, they are atleast some spec and i can run that plugin until I can update too.
I've been watching some of the targeting issues and they are pretty far out, TS on Node seems like a great fit, why not get that going asap?!
Babel is just SOOO far ahead ... The fact that people are using Babel and TypeScript together is a huge flag that TS needs to up their game.
Um, why do I need to mock fake TSDs for things that aren't TypeScript!? Your creating more headache, work, etc. This should have been addressed in v0!
I hit this all the time, I had no idea what ES* features I could use and what I couldn't. I spoke about this on a issue and they said they are only doing stage-3 but they have other things that are stage-0?
I think I've heard about 100x you can use as much or as little of it you want. Ya, good luck. Having to put any everywhere is not my idea of that statement.
I do generally like the approach FlowType is taking.. they put JS first and then lay types on top. Also, I can use babel to compile it and its not as much of a plunge into a java/c# like language.
TS and Babel are doing similar type declaration syntax so its a safer bet that might be included in a upcoming spec and if it doesn't you can always use babel-remove-flow-types ;).
Not specifically a criticism of Typescript, but everything that uses a babel pipeline has been a huge boondoggle (other than for app packaging), now that browsers finally have decent ES6 import support, it's amazing how few ES6 import codebases are actually import compatible and which wholly rely on transpile via babel and not actually are 1) importable themselves 2) have an import compatible dependency tree. instead of 1 migration... why not have 2?
Often TS maintainers only generate the dist artifacts on publish and do not document the various interfaces (babel rendered ES5, babel rendered ES6 + modules, commonjs, AMD - returnExports, etc) So I'm left trolling CDNs to find out which target I need and hoping the developer doesn't suddenly deprecate that target :P (it totally happens).
The "build 5 targets model" only further encourages fragmentation, when so much work was put into unifying codebases we're left with close-ish yet still incompatible junk by the powers that be. How much of everyday JS programmers jobs are normalizing between environments that the standards body's JOB was to make uniform? How much work are we doing to support code-time type hints for APIs we all should know?
It totally precludes buildless development. even if I want NOTHING to do with TS I need a build system to compile jsdoc to .d.ts (though this locks you to old versions because the jsdoc transformer has fallen out of date).
"But surely it saves us work... I can just use those types to push out wire formats (proto, thrift etc)"... well, no. "But it makes everything more secure by preventing type mismatches?" well, at the compile time it forces you to use it makes sure any of the linked code doesn't declare passing the wrong type (not the kind of security that makes you secure, but the type that can help not ship a broken build, AKA what tests already do). "Look dude, Typescript encourages adoption of modern standards right?" Not the actual ones that finally land, just a new language target invented by the maintainers and configurators of babel. In the end TS does 2 things really well: 1) provide type hints 2) serve as a transpile base for other meta languages to compile to (Google used this for Dart, MS for C#).
If your code fits those use cases by all means use it, but if you're in the vast majority of people using it on a small to medium sized project because you don't like to sit down and design your approach (and instead like to freeform select from dropdowns) and you don't like to write tests... deep inside you know what you're doing is wrong.