|
Honestly, using ES6+ syntax with Babel and ESLint is a good experience. A comment above recommends Flow for type checking. I haven't tried it so I can't comment. Static type checking is great in theory but it's just not worth it if you can't get it to play nice with npm modules. I haven't been able to do so reliably in my year of using TS, among other issues. However, don't necessarily take it from me: if you can get it to work, then great, maybe you'll like it more than I did. If your project has a simple build process, you could still try TS with vscode; it works far better than with VS2015/2017 (that's not to say you won't encounter issues, but it won't be as hellish to diagnose). Although, IMHO, I would argue that Types just don't fit JavaScript; TypeScript is very OO while JavaScript is not. My TS code is all classes and interfaces. It's quite Javaesque and a departure from the non-TS part of the codebase. It feels a bit too enterprisey and unproductive for the JavaScript ecosystem. This last part is just opinion, though. This, in addition to the relentless bureaucratic weirdness I encountered, has driven me away. For instance, it doesn't polyfill Promises, Maps, or Sets, even though its front page says it's an ES2015 transpiler. You have to polyfill them yourself, and then you have to get TypeScript not to reject them by providing typings (https://stackoverflow.com/questions/30019542/es6-map-in-type...). You also have to set a config flag in tsconfig.json that tells TypeScript that you're providing those polyfills, i.e. {"lib": [ "es5", "dom", "es2015.promise" ]}. Good luck finding all of this information in one place. I think TypeScript is secretly the enemy of JavaScript. |