5 ms·
Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well?
by ihsw 10y ago
Do you have the same complaints about optional parameters too?
let x = (id: number, name?: string) => { return; };
Is it abuse to use interfaces as well? They are not present in vanilla JS.
How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes?
Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse?
I won't even get into generics as that's a whole different can of worms.
Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time.
TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that.
[1] https://flowtype.org/ https://flowtype.org/
- spriggan3 10y ago> let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse? The probability is higher for ES to implement async/await than the ! operator. The former is a safe bet, the latter isn't, by a long shot. > Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time. It means that language will break. Not very good if you write large TS codebases today. > TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that. That's your opinion. I'm not interested in Flow. Ultimately TS is successful because it more or less looks like Action Script 3/ES4/JScript.net and javascript itself. Make it too Alien and the people who refused to use Coffee script because of its semantics will not want to use TS. And FYI I use TS today. I may reconsider that.
- kbenson 10y ago> > let x = (id: number, name?: string) => { return; }; > hmm, it would make more sense if it was written like that > > let x = (id: number, name: string?) => { return; }; > But I guess it's more or less ok. But I definitely feel inconfortable with the ! . I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well. In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.
- spicyj 10y ago> I'm not interested in Flow. Curious: Why not?
- jsheard 10y agoI'm not him, but the Flow compiler not supporting Windows is a dealbreaker for some.
- spicyj 10y agoThanks. The Flow team is planning to announce official Windows support, hopefully in the next few weeks.
- Eridrus 10y agoIs there a reason to use Flow rather than Typescript now? It seems to have interprocedural type inference, which is really cool, but I'm not sure that's a feature I'd even want in Typescript, since I feel like it would make code less self documenting. Overall it seems like there is more community support for Typescript than Flow, which is essentially just group inertia, but it makes me not want to switch.
- shados 10y agoYou're right, it was never meant to just be annotations+ES6. Though when you talk to someone about TypeScript, they'll argue until they're blue in the face that its just "ES6 with types". I guess you can argue semantics here, but don't be too surprise people will argue back that way.
- nightski 10y agoWell it depends how you use it also. To them it really could be ES6 with annotations.
- spion 10y agoUhh, yes it is meant to be just annotations + ES6. https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... The exclamination is a forced cast to another type, just like "x as otherType". So this is still in the same category.
- spion 10y agoThere is no difference between TypeScript's and Flow's design goals. Flow using the same extension as regular JavaScript is just a dirty marketing trick. Microsoft would be lynched for "embrace-extend-extinguish" if they did the same. But since its Facebook, its completely fine that they're trying to co-opt standards. No problem at all.