| > Are you serious right now??? He (or she) is totally serious and I agree. Here is what I wrote here in some discussion a few days ago: https://news.ycombinator.com/item?id=34454774 ----- TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool,also adds a transpiler is a distraction that made a lot of people believe TS is a different language. But the TS folks have always taken great pain to only ever support features that are or are about to be in the ECMAScript standard, and not to deviate from it. That they did initially with some namespace stuff and enums was before ES2015, when JS was lacking some things many people thought were essential. Even then they only added less than a handful of "TypeScript-code". When you look at the Babel "transpiler" for Typescript, before they added a bit more for class stuff, it pretty much showed that "transpilation" of TS to JS - as long as you targeted a recent ES version - was achieved by doing nothing more than to remove all those type annotations. I'm still mad at the TS guiys for muddying the waters so much by confusing soooo many people by bundling type checking and transpilation in one tool. This could have been much more clear. I too stuck to using Flow for quite some time until I realized TypeScript really is Javascript, while Flow communicated in its architecture and usage already that it just "added types" (literally). ------ Actually changing the nature of Javascript, and quite radically too, were those who wrote the newer spec themselves - introducing more and more "class" things. > Interfaces being one such example. They are not part of the JS code produced, they are simply type annotations. They don't change the actual JS code at all. Being fine with JSDoc but not with TS types is strange to me, there is no difference as far as the JS code outcome is concerned unless you - needlessly! - use the very few, mostly legacy (made obsolete by ES2015+), things in TS that actually end up as JS. Just treat the TS types exactly the same as the JSDoc: It's just comments, it's not part of the code! Get it removed by Babel or tsc just like you could remove (as packers will do) the JSDoc comments for a production build. I once started with Flow (the other JS type checker), experimented with JSDoc+Webstorm as praised here, and very quickly found an actual type checker and full type annotations are far superior. Maintenance and team work, especially when people change what projects they are working on, and even more when you have (your own) libraries that other teams use to build something atop of, then string types are a godsend IMO. And why would I go for the far inferior JSDoc "solution"? I too am VERY keen on using ECMAScript. If TypeScript really messed with the underlying code I would not have chosen it. I simply avoid enums and the other stuff is not even on the radar any more, nobody needs to use the namespacing hacks any more that TS once introduced because prior to ES2015 JS was severely lacking. |