6 ms·

This is absurd, if you're going to add the annotations at least have the runtime enforce them, otherwise all this is doing is saving a "compile" step for ts use

by olliej 5y ago

This is absurd, if you're going to add the annotations at least have the runtime enforce them, otherwise all this is doing is saving a "compile" step for ts users specifically. It would actually be a net negative for JS, as it would allow the syntax to be shipped on sites, and then because it isn't actually checked at runtime you will inevitably end up with sites if the engines ever do start performing type checks, and so will directly prevent them from adding it later. So as I understand things: * This does not actually add type checking * It does not support the full typescript syntax, so you don't get to skip a compile stage * This prevents JS engines actually adding type checking later, due to breaking existing content

DanRosenwasser 5y ago
As the FAQ of the proposal mentions (https://github.com/giltayar/proposal-types-as-comments/#FAQ https://github.com/giltayar/proposal-types-as-comments/#FAQ), we believe adding runtime type checking would be untenable. This stems from both performance concerns and concerns around evolving whatever type-checking would be built in. For that reason, not only do we not expect engines to perform runtime checks, we would specify that these type annotations have no runtime effect.
- olliej 5y ago
  Yes, and having spent many years working on browsers I am saying that if the annotations have no effect there will be code that ends up depending on the engine not performing those checks. At the point the syntax is burned because enforcing the checks breaks content. I am unsure why you believe performing the checks is untenable if TS already does them? The runtime checks should be relatively cheap and in perf critical code if it turned out type checks were too expensive there are a bunch of optimizations engines can do, or the impacted functions could drop the annotations. Adding a significant parsing surface, with the related page load perf impact, with the potential (im going to be generous) to burn the syntax, this seems like nothing but downside.
  - kinjba11 5y ago
    > TS already does them? TS runs the checks at compile time and compiles to JavaScript without annotations. There is no runtime cost. > related page load perf impact Type annotations would likely still be stripped by minifiers, just like comments. No change. > burn the syntax As a dev that regularly uses TypeScript, being able to use debug builds with annotations and copy paste TypeScript into the console would save a lot of time. This would be part of larger trend of adding type annotations to dynamic languages. Python, Ruby, and other dynamic languages have blazed the trail here. There are ways to add enforcement in the future if needed, just look at 'use strict';
    - olliej 5y ago
      > > TS already does them? > TS runs the checks at compile time and compiles to JavaScript without annotations. There is no runtime cost. If there were performance costs this can be mitigated very easily - to be able to do compile time checks means TS is designed largely around early binding, at least in the default case. A JS engine can do this trivially. > > related page load perf impact > Type annotations would likely still be stripped by minifiers, just like comments. No change. You're kidding right? You're proposing permanently changing the language, in a way that burns the type syntax for a feature that you're now saying will be stripped before a JS engine ever sees it? > As a dev that regularly uses TypeScript, being able to use debug builds with annotations and copy paste TypeScript into the console would save a lot of time. That sounds like a feature for your console, not the language > This would be part of larger trend of adding type annotations to dynamic languages. Python, Ruby, and other dynamic languages have blazed the trail here. Which enforced the types. Understand I am not opposed to the type annotations, I am opposed to this because it does not enforce those types. That means that broken content will exist, and thus burn the syntax. > There are ways to add enforcement in the future if needed, just look at 'use strict'; Which will never happen again. As the person who implemented strict mode in JSC I can tell you that the cost of a mode switch is massive, in spec and implementation complexity. Adding another mode switch is simply not going to happen. The only reason I was ever ok with adding strict mode to javascript was the removal of the this conversion. No other part of strict mode would have warranted the cost.

by olliej 5y ago

DanRosenwasser 5y ago

As the FAQ of the proposal mentions (https://github.com/giltayar/proposal-types-as-comments/#FAQ https://github.com/giltayar/proposal-types-as-comments/#FAQ), we believe adding runtime type checking would be untenable. This stems from both performance concerns and concerns around evolving whatever type-checking would be built in. For that reason, not only do we not expect engines to perform runtime checks, we would specify that these type annotations have no runtime effect.

olliej 5y ago
Yes, and having spent many years working on browsers I am saying that if the annotations have no effect there will be code that ends up depending on the engine not performing those checks. At the point the syntax is burned because enforcing the checks breaks content. I am unsure why you believe performing the checks is untenable if TS already does them? The runtime checks should be relatively cheap and in perf critical code if it turned out type checks were too expensive there are a bunch of optimizations engines can do, or the impacted functions could drop the annotations. Adding a significant parsing surface, with the related page load perf impact, with the potential (im going to be generous) to burn the syntax, this seems like nothing but downside.
- kinjba11 5y ago
  > TS already does them? TS runs the checks at compile time and compiles to JavaScript without annotations. There is no runtime cost. > related page load perf impact Type annotations would likely still be stripped by minifiers, just like comments. No change. > burn the syntax As a dev that regularly uses TypeScript, being able to use debug builds with annotations and copy paste TypeScript into the console would save a lot of time. This would be part of larger trend of adding type annotations to dynamic languages. Python, Ruby, and other dynamic languages have blazed the trail here. There are ways to add enforcement in the future if needed, just look at 'use strict';
  - olliej 5y ago
    > > TS already does them? > TS runs the checks at compile time and compiles to JavaScript without annotations. There is no runtime cost. If there were performance costs this can be mitigated very easily - to be able to do compile time checks means TS is designed largely around early binding, at least in the default case. A JS engine can do this trivially. > > related page load perf impact > Type annotations would likely still be stripped by minifiers, just like comments. No change. You're kidding right? You're proposing permanently changing the language, in a way that burns the type syntax for a feature that you're now saying will be stripped before a JS engine ever sees it? > As a dev that regularly uses TypeScript, being able to use debug builds with annotations and copy paste TypeScript into the console would save a lot of time. That sounds like a feature for your console, not the language > This would be part of larger trend of adding type annotations to dynamic languages. Python, Ruby, and other dynamic languages have blazed the trail here. Which enforced the types. Understand I am not opposed to the type annotations, I am opposed to this because it does not enforce those types. That means that broken content will exist, and thus burn the syntax. > There are ways to add enforcement in the future if needed, just look at 'use strict'; Which will never happen again. As the person who implemented strict mode in JSC I can tell you that the cost of a mode switch is massive, in spec and implementation complexity. Adding another mode switch is simply not going to happen. The only reason I was ever ok with adding strict mode to javascript was the removal of the this conversion. No other part of strict mode would have warranted the cost.