Comment by halapro

Comment by halapro 19 hours ago

5 replies

Because TypeScript is a (legacy) mess.

There's effort towards "erasable syntax" but in practice not many really want to run anything more than basic TS in the browser, simply because you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.

The real reason however is that TS is just a language, not part of any standard, and browsers are not just going to support random languages headed by corporations (Microsoft) and that are not community projects.

WorldMaker 16 hours ago

> you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects.

I think importmaps are reasonably practical even for larger projects today. I know Firefox supporting multiple importmaps in the same HTML is still a wishlist item for some to avoid more scenarios that need an importmap compile step in very large projects, but importmaps are relatively easy to automate (it's just JSON wrapped in a script tag; merging them can be just a matter of a couple Object.assign calls or object spread notation; the multiple importmaps standard that Firefox is behind on is just that, a basic Object.assign merge).

> The real reason however is that TS is just a language, not part of any standard

Right, which is why the TC-39 (committee that owns JS) proposal for "erasable syntax" for "type annotations" isn't Typescript-specific and isn't a pure superset of Typescript syntax. The node implementation of erasable syntax doesn't use the Typescript compiler and doesn't support the full Typescript syntax and is relatively close to the TC-39 proposal.

> not just going to support random languages headed by corporations (Microsoft) and that are not community projects.

Nitpicking somewhat, but Typescript has been open source since it was publicly launched and a fair enough chunk over the years of contributors aren't/haven't been Microsoft employees. It's fairly reasonable to say it is a community project. I appreciate the point that it is still seen as a specific-vendor solution and the point of separating the JS language standard proposal from being "just do what Microsoft decides is right for Typescript" (as TC-39 is trying to do), but to be fair to Typescript, it is a also bit wilder and more open than that "just a Microsoft solution" at this point (and arguably also for most of its history).

nikeee 18 hours ago

The "types as comments" proposal has a stated goal to not codify any semantics to the annotations.

This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.

  • conartist6 17 hours ago

    That proposal is a practical joke. You haven't got a language at all if the words don't mean anything.

    • WorldMaker 16 hours ago

      It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.

      • conartist6 8 hours ago

        If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!