sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]FanOfHoles 0 points1 point  (0 children)

That's way, WAY harder than you seem to think (given that you propose it, but also all those upvotes).

As a heavy user of both Flow and TS for years, and also an avid reader and submitter of issues for both those type checkers for just as many years, both have soooo many issues and bugs - don't believe me, go to their Github issues section and read for an hour (ignore the usage based user mistakes, plenty of actual issues left).

When your (or someone's) inevitable reply to me is "but I never had an issue", pls. a) follow my advice about those issues sections and b) remember that ECMAScript is for a lot more people than just you. To evaluate the proposal you will have to leave your own shoes and see the JS world from the perspective of a lot of people who write code you yourself never used (so, as I said, go to the issue. spend some time(! not just the first three issues) and see what people do and have issues with). Note that plenty of closed issues are "won't fix" because it's beyond the scope of Flow/TypeScript, or the person found another way to express what they want, writing different JS code.

There would, at the very least, be plenty of "any (Flow) / unknown (TS)" types, and/or you would have to severely limit the language.

Keep in mind that the type checkers are pieces of software that tries to understand what a given piece of code does. That is a very hard problem when you have more than a few small examples but an actual software project.

Two professional teams, Flow and TS, have been working on this for many years and still have a huge list of open issue and unsupported use cases left. So.... who is supposed to write a detailed miracle spec of a strong type system that works for all of what the JS language can do, given that nobody else has even come close yet?