6 ms·
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
by easong 10y ago
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.
- icholy 10y agoI agree, the javascript ecosystem needs more fragmentation.
- easong 10y agoI 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 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.
- sotojuan 10y agoI 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 10y agoTotally. I tell new devs to use typescript. But I don't think using babel precludes shipping a binary with a standard pre-built config.
- ceronman 10y agoIf 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 10y agoMicrosoft 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.
- shados 10y agoim 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)
- 10y ago
- FrancoDiaz 10y agoThis was discussed a couple days ago. https://news.ycombinator.com/item?id=12538106 https://news.ycombinator.com/item?id=12538106
- omegaworks 10y agoHealthy competition to the Babel nonsense is good for all of us.
- hasenj 10y agoI'm actually glad they release TypeScript as a completely integrated and standalone solution.
- easong 10y agoIt definitely has advantages. But I don't think using babel precludes shipping a binary with a standard pre-built config.
- seanwilson 10y agoI 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.