[easong]

I really wish that MS would release typescript as a collection of plugins for babel that would handle only one thing at a time (eg, the type system). Having my production build, es6 transpiler, type system, JSX compiler and so on (including a bunch of features I would rather didn't exist at all) all in one package feels like a failure of separation of concerns.

I understand that people find Babel's plugin ecosystem confusing and intimidating (it is), but I don't think a separate monolithic typescript that reimplements popular babel functionality is the answer.

[hasenj]

I'm actually glad they release TypeScript as a completely integrated and standalone solution.

[easong]

It definitely has advantages. But I don't think using babel precludes shipping a binary with a standard pre-built config.

[icholy]

I agree, the javascript ecosystem needs more fragmentation.

[easong]

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.

[ceronman]

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.

[easong]

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.

[wereHamster]

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

[shados]

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)

[easong]

I've had good experiences with https://marketplace.visualstudio.com/items?itemName=rtorr.vs... so far, but perhaps I've gotten lucky. When I first tried flow out a few months ago I was also very unhappy with the tooling.

[sotojuan]

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.

[easong]

Totally. I tell new devs to use typescript. But I don't think using babel precludes shipping a binary with a standard pre-built config.

[Chyzwar]

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.

[FrancoDiaz]

This was discussed a couple days ago.

https://news.ycombinator.com/item?id=12538106

[seanwilson]

I can't see how this would help things. Trying to separate it all out would surely lead to lowest common denominator support in terms of strong typing if things were optional (hard to design a type system when you don't know all the features) and create further JavaScript fragmentation.

[omegaworks]

Healthy competition to the Babel nonsense is good for all of us.