5 ms·

I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it

I'm assuming by optional operator you're referring to optional chaining? If so, it's very cool but strikes me as an odd reason to move to TypeScript, because it's a stage 3 proposal in JavaScript too, so is likely to be widely supported soon.

nothrabannosir 7y ago
This is correct. Move to TypeScript for the types. If all you want is the latest syntactic developments from ES, babel is a better fit. It tends to be further ahead than TS for the bleeding edge features.
- z3t4 7y ago
  You can even make your own definitions and syntax sugar using Babel. (If we continue to add more syntax sugar to JS, it will soon be more complicated then C++.)
  - city41 7y ago
    You can as well in TypeScript, it's just never been promoted or talked about much. Which is a shame. When I get a decent chunk of free time I plan to play with it, I'm curious if it's possible to write a translation layer that would allow using babel plugins in TS. Here is an article on the TS feature: https://dev.doctorevidence.com/how-to-write-a-typescript-transform-plugin-fc5308fdd943 https://dev.doctorevidence.com/how-to-write-a-typescript-tra...
spankalee 7y ago
The operator is much better with nullable types because you're less likely to add it everywhere defensively. Hopefully tsc or eslint will actually warn when you use optional chaining on a non-nullable receiver.
nikeee 7y ago
The TypeScript team is only implementing features that have a chance of 100% of landing in JS or 0%. Therefore, they wait for Stage 3. If they start implementing features at an earlier stage, there is the risk of implementing a feature with different semantics in TS than in JS, since the JS spec can still change (or event get rejected). Both cases will result in diverging languages, which is something they try to avoid. Edit: In the past, that didn't work that well. TS 3.8 is planned to ship with JS private fields support (the one with the # syntax). TS had private fields for a long time. In fact, it's one of the first things that the language had. However, these private fields behave entirety different to what ended up in the ES private fields spec. They can't change it afterwards. So in the future, we will have two semantically different ways of declaring a private field in a class in TS. Another case are decorators. They are still in stage 2 and may change. They already exist in TS, behind a flag. But every Angular application depends on their current implementation in TS. If the spec changes, it will get interesting.
- amaranth 7y ago
  Not just Angular, TypeORM and NestJS and a bunch of other server frameworks written in TypeScript make heavy use of decorators. The JavaScript spec for them has been rewritten twice since what TypeScript has so there is going to be a lot of trouble.
- LocalPCGuy 7y ago
  > They can't change it afterwards. I would argue that TypeScript absolutely can change things that would be consider breaking changes. And they do have breaking changes in just about every release (sure wish they followed semver for that reason). They'd just want to be careful for big things like private fields or decorators, making sure the breaking changes get communicated publicly and loudly.

nothrabannosir 7y ago

This is correct. Move to TypeScript for the types. If all you want is the latest syntactic developments from ES, babel is a better fit. It tends to be further ahead than TS for the bleeding edge features.

z3t4 7y ago
You can even make your own definitions and syntax sugar using Babel. (If we continue to add more syntax sugar to JS, it will soon be more complicated then C++.)
- city41 7y ago
  You can as well in TypeScript, it's just never been promoted or talked about much. Which is a shame. When I get a decent chunk of free time I plan to play with it, I'm curious if it's possible to write a translation layer that would allow using babel plugins in TS. Here is an article on the TS feature: https://dev.doctorevidence.com/how-to-write-a-typescript-transform-plugin-fc5308fdd943 https://dev.doctorevidence.com/how-to-write-a-typescript-tra...

spankalee 7y ago

The operator is much better with nullable types because you're less likely to add it everywhere defensively. Hopefully tsc or eslint will actually warn when you use optional chaining on a non-nullable receiver.

nikeee 7y ago

The TypeScript team is only implementing features that have a chance of 100% of landing in JS or 0%. Therefore, they wait for Stage 3. If they start implementing features at an earlier stage, there is the risk of implementing a feature with different semantics in TS than in JS, since the JS spec can still change (or event get rejected). Both cases will result in diverging languages, which is something they try to avoid. Edit: In the past, that didn't work that well. TS 3.8 is planned to ship with JS private fields support (the one with the # syntax). TS had private fields for a long time. In fact, it's one of the first things that the language had. However, these private fields behave entirety different to what ended up in the ES private fields spec. They can't change it afterwards. So in the future, we will have two semantically different ways of declaring a private field in a class in TS. Another case are decorators. They are still in stage 2 and may change. They already exist in TS, behind a flag. But every Angular application depends on their current implementation in TS. If the spec changes, it will get interesting.

amaranth 7y ago
Not just Angular, TypeORM and NestJS and a bunch of other server frameworks written in TypeScript make heavy use of decorators. The JavaScript spec for them has been rewritten twice since what TypeScript has so there is going to be a lot of trouble.
LocalPCGuy 7y ago
> They can't change it afterwards. I would argue that TypeScript absolutely can change things that would be consider breaking changes. And they do have breaking changes in just about every release (sure wish they followed semver for that reason). They'd just want to be careful for big things like private fields or decorators, making sure the breaking changes get communicated publicly and loudly.