I suppose the problem is that I see typescript as the fragmentation. If MS leverages babel (they can even keep shipping TS as their own thing if they want, I just want them to provide babel plugins), we can all use that and focus on making it as cross-compatible and streamlined as possible. (Well, really, we can focus on providing a single well-documented on-ramp to new javascript developers, which I think is the main problem and the one MS set out to own with typescript.)
Right now, we have the typescript ecosystem, the babel ecosystem, and the other wannabe ecosystems. If I like Typescript's type system but want to use babel for async-await (for instance, I'm aware it's in TS next), I'm basically SOL. Babel has more end-users (AFAIK), generally has the first/only implementation of <feature>, and my impression is that the surrounding development community is larger and more active (typescript stuff tends to come down from On High).
For instance, you can use https://github.com/gcanti/babel-plugin-tcomb to get run-time type checking with babel/flow for free. That's really cool! Unfortunately, the same is not possible with typescript (AFAIK), because MS decided that was out of scope. If Typescript was offered as a babel plugin, somebody else could implement it for typescript and we could all be happy.
If you implement TypeScript as a Babel plugin, you would likely lose all the superb IDE support that TypeScript has. Which is one of the major selling points of TypeScript IMO. When your language is unstable like in a typical Babel setup, any number of features might be on or off, the static analysis done by IDEs becomes almost impossible. Performance would be affected too.
Microsoft has absolutely done an amazing job with typescript IDE integration. But are there any end-user IDE benefits to typescript over flow/eslint? (Not being snarky.)
I've been using both on separate projects (with MS IDEs) and haven't noticed anything major.
The design of TypeScript is explicitly so that it can provide a good API (called "language service") to IDEs and other tools. And not just "give me all the errors/warnings in this file" but also to give detailed information about the types at specific positions of the source code, and the whole design is so that it can efficiently recheck a whole project if you change one part of a file. One of the lead engineers of TypeScript talked about that in one of his techtalks (can't find the link right now).
im a Flow fan, but Flow's IDE support is pretty bad. WebStorm only souped it up recently, and aside for that, outside of Nucleide (and even there!) its pretty awkward/slow/clunky and in many cases downright buggy.
TypeScript's type system is very bleh, but its IDE integration IS pretty good across many editors (not just VSCode)
I think people like not having the usual Babel plugin/config + setup soup. There's value in all-in-one solutions with clear limitations. For example, TS doesn't implement JavaScript stuff below stage 2 while many devs liberally use stage-0 and stage-1 features with Babel. Some prefer TypeScript's way.
Babel is temporary solution and we should all remember this. Babel should ideally be obsolete in 2-3 years when IE11 will get eradicated by MS. Babel imo is pretty bad idea, I think its name imply this as well.
Right now, we have the typescript ecosystem, the babel ecosystem, and the other wannabe ecosystems. If I like Typescript's type system but want to use babel for async-await (for instance, I'm aware it's in TS next), I'm basically SOL. Babel has more end-users (AFAIK), generally has the first/only implementation of <feature>, and my impression is that the surrounding development community is larger and more active (typescript stuff tends to come down from On High).
For instance, you can use https://github.com/gcanti/babel-plugin-tcomb to get run-time type checking with babel/flow for free. That's really cool! Unfortunately, the same is not possible with typescript (AFAIK), because MS decided that was out of scope. If Typescript was offered as a babel plugin, somebody else could implement it for typescript and we could all be happy.