3 ms·

The beauty of this proposal is that it would keep JS as exactly that. Optional type annotations, packaged as a part of vanilla JS instead of requiring a build

by ketzo 5y ago

The beauty of this proposal is that it would keep JS as exactly that. Optional type annotations, packaged as a part of vanilla JS instead of requiring a build step, would be the only benefit. They'd be stripped out at runtime; the compiled JS would be identical.

fulafel 5y ago
The complexity / change cost: Since this would be a JS language addition, this would add complexity and churn to the JS language syntax. (There is no separate runtime / compile time in the JS model as implemented by JS browsers and tooling - except when run through JS-to-JS compilers). The benefit: Sown by TS users or possibly some kind of of TS-lite using this subset of TS features. Not benefiting: non-TS languages targeting the browser, like Elm, ClojureScript, ReScript, PureScript, Haxe, Nim, Kind, and <the next big language here>.
- ketzo 5y ago
  > Not benefiting: non-TS languages Why? If anything, this gets vanilla JS users more comfortable with types in their JS. That seems like a win, and a good gateway to more strongly-typed languages. Even if other languages aren’t actively benefiting, does it hurt them in any way? They wouldn’t even have to make any changes to their compilers; their compiled JS would stay just as valid. The benefit is not to just Typescript users and advocates; the benefits are for everyone who wants more sanely developed JavaScript. Seems pretty good.