4 ms·
The main reason for using Babel was async/await. However, the lastest TypeScript verion (typescript@next) can compile async/await for older browsers, so there i
by denisanerson 10y ago
The main reason for using Babel was async/await. However, the lastest TypeScript verion (typescript@next) can compile async/await for older browsers, so there is no reason for me to use Babel anymore.
- k__ 10y agoOT: When will 2.0 finally released? I saw that they have a completed 2.0.3 milestone in Github, but just a RC release at the moment.
- denisanerson 10y agoNo, I mean nightly build 2.1.0: npm install typescript@next
- k__ 10y agoI know. I just wanted to know when 2.0 will be officially released and it seems like never, since they already at 2.1, lol
- moogly 10y agoThey might be waiting for VS2015 tooling support, because VS2015 support for TypeScript is still hilariously atrocious. It feels like the TypeScript team and VS team do not communicate and are set on completely different workflows. The VS Code team gets it though, but that's probably because they use TS to write their very product.
- whatever_dude 10y agoThings like babel-core are still a must though.
- saosebastiao 10y agoThey are? I haven't run into any problems with the latest typescript@next.
- whatever_dude 10y agoAs great as TypeScript is for enforcing certain guidelines for your own code, it does not provide much in terms of supplying polyfills so certain browsers can support some ES5/ES6 features. If you're working with the cutting edge of browsers it shouldn't be a problem, but if you need to go back a couple of years, you either need that or at the very least core-js. Even the ECMAScript feature table (https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/) uses Babel and TS with core-js when comparing features, otherwise it'd be heavily browser dependent.