Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> > 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.


Personally, I'd love to see some of the operators that F# has make it into ES stage-0 proposals...

    |> 
    <| 
    combinedFn = function1 >> function2
etc... Though the last is mostly handled with fat-arrow syntax


> I'm not interested in Flow.

Curious: Why not?


I'm not him, but the Flow compiler not supporting Windows is a dealbreaker for some.


Thanks. The Flow team is planning to announce official Windows support, hopefully in the next few weeks.


Is 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: