2 ms·
Some FAQ items address this: https://github.com/giltayar/proposal-types-as-comments#why-not-define-a-type-system-for-js-in-tc39-instead https://github.com/gilt
by hombre_fatal 5y ago
Some FAQ items address this:
https://github.com/giltayar/proposal-types-as-comments#why-not-define-a-type-system-for-js-in-tc39-instead https://github.com/giltayar/proposal-types-as-comments#why-n...
Various good reasons, like how it would hinder TS evolution and you'd end up having to compile TS to whatever older version of TS the slowest implementors support anyways.
But one interesting point is that type analysis is for the developer's benefit. What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine?
- mekster 5y ago> What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine? Is that even a question? If more people adopt TS because it's native in browsers, producing less bugs means more user satisfaction.
- hun3 5y agoWhy would more people adopt TS because it's native in browsers, which won't enforce specifying type annotations anyway?
- mekster 5y agoNo compiling process = easier?
- hombre_fatal 5y agoBut how does the end-user care about static type analysis and why is it being done on their client? What exactly does this UX look like for them? If you push TS source that you didn't bother tsc'ing on your machine because hey it runs on the client, does it simply fail to run for the user even though the program would have worked? I don't see how pushing TS source is better than pushing compiled JS.