4 ms·

>It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. The fo

>It means the supplemental information needed to run either static or dynamic type-checking is there & so that either browsers or toolchains can use it. The format isn't specified, it's just a comment. Browsers can't take advantage of it. Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. >what advantage does existing typescript language have, over a backwards-compatible & type-carrying enhancement to JS? Typescript is on a much faster release schedule than the standards. Just think of how slowly its (amazing) type system would've evolved if designed by committee. I'd be all for a type system in javascript a couple of years ago. But seeing how fast typescript evolved when it's not limited by a committee, I think that keeping that separate of the main language is completely acceptable.

rektide 4y ago
> The format isn't specified, it's just a comment The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec. Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win. > Browsers can't take advantage of it. Why not? They could. > Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"
- Matheus28 4y ago
  >Why not? They could. They syntax isn't fully specified (it does some basic syntax checking on the top level, but doesn't check anything inside brackets). Asking browsers to support every variation of type declaration syntax that will come out is a lot (even if that turns out to be just typescript and flow). Why bloat the language and implementations? Unless you propose an unified syntax for types... in which case it will hurt innovation as we won't ever be able to make backwards breaking changes, as people will rely on all sorts of quirky behavior. >Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation" Right, but why is this desirable? What does this bring to the table other than some convenience in exchange for adding more bloat to the language & implementations? If you want browsers to also type-check, then you're also adding more complexity to implementations. In exchange of a small bit of convenience? If you want the type-check to be used for optimizations, while a noble goal, would require some massive reengineering of current javascript engines. It's already possible to get optimizations that come from static typing by compiling things to webassembly instead (so they can use existing pipelines, like llvm. Assemblyscript comes to mind, it tries to be similar to typescript but with mandatory types). A lot of optimizations might not even be possible to do even with type annotations, unless they're a lot more strict than typescript's. See the following examples: * https://www.typescriptlang.org/play?#code/G4QwTgBAZg9jBcEDOAXMBLAdgcwgHwkwFcAbEiAXggCIRqBuAKEfSggApYYBKCAb0YRkAUxQAxOADlSJdtyZCuAOhLCcKABb0IAeh2EYEYWDAwwjAL7MoRTAGMU6GJhHipMuf0HQ4lQjKYrIA https://www.typescriptlang.org/play?#code/G4QwTgBAZg9jBcEDOA... * https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PQvAtgUwBcALASwDsBzALiwICdyLoAfaMgVxBGgF43OQAblQBfVKgBm7MsAIl4ZaABN4AZVyFSlABQTENBPACUKdJhITouxADps+YoxNpMr5Wo2PKAURAQ81sbCbph68HaeWhQ2IHiUxILQAPRJWETwnErQeHR08HQANNAARuwE7ngQZADkBGYYYmKS0rLyiirqDlG+-oEGiM710GERXYy8-FzCIkA https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8... * https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PQPoXgWwFMAXACwEsA7AcwC5oIiAnSq6AH2goFcQRoBeaACISBXvCEBudJirF6+YuWoAKAJR0Gzau048+aTEegh5jeYNJkIAOhyKr1accxXb9wo9aDuvZy+hzIi5GCkDifwwAX1QY1AAzLgpgIjJ4MIATeABlB2UqFXjEOgR4NRQZDDJ46ELEG1xPfPLDAKL4BryWG1NqUkloAHpB+hJ4HgzoAkZGeEYAGmgAIy4iaCyCCAoAciJK6BiYoA https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8... JS engines already optimize number-heavy code when they can identify that variables are always going to be numbers.
  - rektide 4y ago
    This feels like enormous de-bloating of the developmemt experience at zero cost to the language. A pragma at the top, "use typescript" that the browser could handle would bridge 98% of the rest of value while not overcommitting the language to a specific cause. This is all free cheap easy wins. Easy.

rektide 4y ago

> The format isn't specified, it's just a comment The authors intend to support a variety of type systems, such as TypeScript & Flow. That TypeScript would need to define it's own grammar doesn't seem harmful, & would surely be standardized quickly, exterior to this more general spec. Latter you say: "Typescript is on a much faster release schedule than the standards." Well, since the format isn't specified, TypeScript is free to release at their leisure. Not bundling orthogonal concerns together, providing low-level extensible capabilities is a win. > Browsers can't take advantage of it. Why not? They could. > Toolchains already do cross-compiling when they're bundling anyway, so it's not required on that front. Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation"

Matheus28 4y ago
>Why not? They could. They syntax isn't fully specified (it does some basic syntax checking on the top level, but doesn't check anything inside brackets). Asking browsers to support every variation of type declaration syntax that will come out is a lot (even if that turns out to be just typescript and flow). Why bloat the language and implementations? Unless you propose an unified syntax for types... in which case it will hurt innovation as we won't ever be able to make backwards breaking changes, as people will rely on all sorts of quirky behavior. >Ok, but you're ignoring the goal of this proposal: "The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation" Right, but why is this desirable? What does this bring to the table other than some convenience in exchange for adding more bloat to the language & implementations? If you want browsers to also type-check, then you're also adding more complexity to implementations. In exchange of a small bit of convenience? If you want the type-check to be used for optimizations, while a noble goal, would require some massive reengineering of current javascript engines. It's already possible to get optimizations that come from static typing by compiling things to webassembly instead (so they can use existing pipelines, like llvm. Assemblyscript comes to mind, it tries to be similar to typescript but with mandatory types). A lot of optimizations might not even be possible to do even with type annotations, unless they're a lot more strict than typescript's. See the following examples: * https://www.typescriptlang.org/play?#code/G4QwTgBAZg9jBcEDOAXMBLAdgcwgHwkwFcAbEiAXggCIRqBuAKEfSggApYYBKCAb0YRkAUxQAxOADlSJdtyZCuAOhLCcKABb0IAeh2EYEYWDAwwjAL7MoRTAGMU6GJhHipMuf0HQ4lQjKYrIA https://www.typescriptlang.org/play?#code/G4QwTgBAZg9jBcEDOA... * https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PQvAtgUwBcALASwDsBzALiwICdyLoAfaMgVxBGgF43OQAblQBfVKgBm7MsAIl4ZaABN4AZVyFSlABQTENBPACUKdJhITouxADps+YoxNpMr5Wo2PKAURAQ81sbCbph68HaeWhQ2IHiUxILQAPRJWETwnErQeHR08HQANNAARuwE7ngQZADkBGYYYmKS0rLyiirqDlG+-oEGiM710GERXYy8-FzCIkA https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8... * https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PQPoXgWwFMAXACwEsA7AcwC5oIiAnSq6AH2goFcQRoBeaACISBXvCEBudJirF6+YuWoAKAJR0Gzau048+aTEegh5jeYNJkIAOhyKr1accxXb9wo9aDuvZy+hzIi5GCkDifwwAX1QY1AAzLgpgIjJ4MIATeABlB2UqFXjEOgR4NRQZDDJ46ELEG1xPfPLDAKL4BryWG1NqUkloAHpB+hJ4HgzoAkZGeEYAGmgAIy4iaCyCCAoAciJK6BiYoA https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8... JS engines already optimize number-heavy code when they can identify that variables are always going to be numbers.
- rektide 4y ago
  This feels like enormous de-bloating of the developmemt experience at zero cost to the language. A pragma at the top, "use typescript" that the browser could handle would bridge 98% of the rest of value while not overcommitting the language to a specific cause. This is all free cheap easy wins. Easy.