To be frank, I hate to be the typical HN luddite, but this proposal [1] feels like it will add too much parsing complexity to runtime JS. The counter-argument

To be frank, I hate to be the typical HN luddite, but this proposal [1] feels like it will add too much parsing complexity to runtime JS. The counter-argument to that is: everyone minifies code anyway, but this feels like a very poor argument. "Adding cruft is OK because most people have complicated build chains to get rid of it" is very different from "we've opted into a build chain (tsc) and now have access to adding cruft"; there's a default situation here, which is the many people who write JS (FE or BE) and aren't minifying it. Additionally, their pipe dream of allowing TS to become standard JS "if they stick within a certain reasonably large subset of the language" (an actual quote from the TC) is... wild. Wild. No thoughts, just vibes. Typescript is an extremely mature, fast-moving, complex project. Their list of TS features not supported under this TC is only three items long (with enums and namespaces among the list, lol), but I guarantee there are TONS of very complex type-level assertions typescript is capable of which JS is years, maybe decades, from reaching considering the glacial speed ECMA moves at. Typescript will always be a superset, which they admit. The problem is: I hold extreme doubt that JS/ECMA is even capable of communicating what that differential is to average users. Will JS support control flow analysis for dependent parameters, aliased conditions, and discriminants? Const assertions? Middle rest elements in tuples? Typescript adds all these assertions, and more, every couple months, because it turns out that type systems are something of a pandora's box. Few language-level type systems remain at the simplicity of, say, Go; most become TS, or Rust, or Java. That's not a bad thing, but not everything should be that. If this gets traction and built, JS will in-effect, though not in-requirement, turn from an interpreted language to a compiled language, whose compiler isn't even maintained by the core development teams. That's a major, major shift; and I'm not sure the proposers have even considered the ramifications of it. [1] https://github.com/giltayar/proposal-types-as-comments/ https://github.com/giltayar/proposal-types-as-comments/