3 ms·
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 r
by 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.