Comment by lewisl9029 | Hacker News Reader

Comment by lewisl9029 | Hacker News Reader

Parent Full thread

Thanks for bringing that to my attention!

That sounds super exciting. I'm definitely going to have to give that a shot once it's ready.

Flow's excellent React Native support has also been a large part of why I've mostly been working in Flow-land these days, so I'm glad to hear TypeScript will soon become a first-class citizen in that ecosystem as well.

EDIT: As a follow up question, please correct me if I'm misunderstanding anything, but from what I've gathered so far, I suspect that the new babel-preset-typescript can't quite do _just_ type-stripping can it? Since some features in TypeScript have runtime implications, those would still have to be transformed as opposed to simply stripped, correct? So it looks like that fundamental difference between TypeScript and Flow remains in tact, but it's certainly still a huge leap in usability to be able to adopt the Babel toolchain as a first-class way of building TypeScript projects. Huge props to the Babel and TypeScript teams for making that possible!

> I suspect that the new babel-preset-typescript can't quite do _just_ type-stripping can it? Since some features in TypeScript have runtime implications, those would still have to be transformed as opposed to simply stripped, correct?

I'm quite new to Typescript myself so I really don't know. At least I'm not aware of such features and don't think this Babel feature would make much sense if there were any?

EDIT: I think some of the runtime features are just TS doing ES6 to ES5 compiling. Such as "for of" loops, generators etc., but since those are just ES6 syntax they can be handled by other Babel plugins/presets or even by modern browsers directly.

The two most obvious examples I can think of off the top of my head are features like Enums and constructor param visibility settings. Both must be transformed to retain their runtime properties, and both don't exist in any ratified ES spec. Luckily enough they both also happen to have fairly straightforward mappings to their respective JS implementations, and once you know that they do introduce runtime behavior (and it's fairly easy to notice that they do), you can simply avoid them, so the practical impact of these more obvious cases can be limited.

More troubling cases do exist though. I vaguely remember once coming across some obscure runtime behavior for decorators where they attach runtime metadata that's supposedly used for type reflection, which is a runtime effect that's definitely not immediately obvious or intuitive. This and other potential obscure edge cases like it, some of which may exist in TypeScript today and some of which might be introduced in some future version, are part of what makes Flow's focus on providing trivially removable static typings on top of spec-compliant JavaScript so attractive to me (in addition to opening up the option of minimizing the surface area of your transpilation step or skipping transpilation altogether).

Thanks. Here's the documentation about the enum issue https://github.com/babel/babel/tree/master/packages/babel-pl...

I hope that in future Typescript would take the same approach as Flow and just focus on being a good type checker on top JS.

Reply on news.ycombinator.com