11–20 of 247 posts
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.
I saw that they have a completed 2.0.3 milestone in Github, but just a RC release at the moment.
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.
OT: 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.
Also, since this seem to be a popular misconception, JSX support in TypeScript is not wedded to React. The default JSX target is React, but you can set JSX to "preserve" and get very vanilla semantics as well as keeping the JSX in the emitted code so you can pipe it through a custom transformer.
The question also points out that the reader is looking at lots of tutorials -- it should be unsurprising that these don't use TypeScript as it's an optional thing that would only increase the concept count in an educational setting where you want to only show the thing you're trying to explain.
If you need a notable React + TypeScript project, see the Delve team's write-up of their use of TypeScript - https://medium.com/@delveeng/why-we-love-typescript-bec2df88...
Earlier quoted context omitted.
OT: 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.
No, I mean nightly build 2.1.0: npm install typescript@next
I just wanted to know when 2.0 will be officially released and it seems like never, since they already at 2.1, lol
TypeScript is a PITA when working with typed immutable records, I don't think there will be a happy solution to that. React stack encourages stuff like immutable.js. In general TS React feels bolted on rather than designed with TS in mind like Angular 2. I love TS and using ng2 at work. If I was using React I would probably also skip on TS.
I am not actually sure what you mean by typed immutable records in this context, can you explain in more detail?
Because a lot of notable ReactJS projects are irritatingly enamored with all the latest ES6/ES7/ESCloudCuckooLand features, not all of which are supported by TypeScript. I've noticed this a lot in the Redux realm. For every possible problem there seems to be a solution that harnesses one particular new/proposed bell & whistle.
This. Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place. Now if you want to add types, Flow is easier to integrate than switching to another compiler.
Earlier quoted context omitted.
No, I mean nightly build 2.1.0: npm install typescript@next
I 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
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.
Earlier quoted context omitted.
This. Many React projects use JSX, decorators and class properties to the max, so they needed babel in the first place. Now if you want to add types, Flow is easier to integrate than switching to another compiler.
My opinion is that all the extensions on JavaScript should be implemented as Babel plugins, including Typescript. That would solve all the compatibility problems. Well, when Babel first came out I also thought that it should have been a Sweet.js plugin so maybe I don't have the best understanding of this "transpiling" circus.
For example, if you desired to implement a plugin for "thin arrows", and a plugin for JSX, how would you parse this?
const x = } />
You'd have to have the JSX parser know to invoke the thin arrow parser, then the thin arrow parser has to know how to invoke the JSX parser, then when you emit, you have to do the whole dance over again.
If you're willing to take some trade-offs in the parsing phase, it's OK. But the emit is where you get killed - either every plugin has to be written generically and correctly enough to deal with any arbitrary nesting of syntaxes (including the cases where the semantics of nesting aren't even clear, like where a 'fat' arrow here would capture 'this' from), or you do one tree pass per transformer, which gets very expensive.
There's a reason you don't usually see architectures like that live very long.
TypeScript is a PITA when working with typed immutable records, I don't think there will be a happy solution to that. React stack encourages stuff like immutable.js. In general TS React feels bolted on rather than designed with TS in mind like Angular 2. I love TS and using ng2 at work. If I was using React I would probably also skip on TS.
I recently started using TypeScript for my React projects and I am actually pretty happy. I am not actually sure what you mean by typed immutable records in this context, can you explain in more detail?
A nice typescript-friendly alternative to redux+immutablejs is MobX (https://mobxjs.github.io/mobx/getting-started.html). It does go a bit against the latest cool and hip trends (immutability, functional programming), but IMO its quite brilliant