5 ms·

Dumb question incoming… Why not formalize TypeScript into the ECMAScript spec?

dham 5y ago
Why does Javascript have to have all of Typescript brought into it? The browser has supported multiple scripting languages before. Not unprecedented. <script language="typescript" />
- krapp 5y ago
  Unfortunately, the HTML5 spec dropped the language option for the script tag, so browsers will only ever natively support javascript now and in the future. We're not going to get multiple languages back until something like runtime embedding through WASM becomes commonplace.
nick_ 5y ago
If only the ECMAScript/JavaScript community were this sensible.
ByteJockey 5y ago
Google controls JS to the point of being able to ignore the spec (e.g. that time they left TCO behind an experimental flag and it just went away despite being in the spec). As long as node and chrome are so dominant, we're probably not going to see big shake-ups in JS that aren't driven by Google themselves. JS is flexible, you can cover up a lot with polyfills, but not completely different syntax. Doing that without Google's buy in would create a rift in the internet that would either end with browser specific web pages, or with the complete loss of power for the committee that sets the ECMAScript spec as JS officially goes from being a language that is defined by a spec to a language defined by a canonical implementation (in this case V8).
LudwigNagasena 5y ago
Yeah, isn't TypeScript without enums and decorators already kind of "types as comments"?
- city41 5y ago
  TypeScript does support JSDoc type annotations and will use them to validate types in a JS project. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
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 ago
    Why would more people adopt TS because it's native in browsers, which won't enforce specifying type annotations anyway?
    - mekster 5y ago
      No compiling process = easier?
  - hombre_fatal 5y ago
    But 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.
throw_m239339 5y ago
This actually isn't dumb question. Nothing precludes Typescript from becoming another ECMA spec. It's just not going to be ECMAScript. Nothing precludes Microsoft from allowing Typescript to run directly in the browser either. Nothing. Just that nothing forces any other browser to support Typescript as well. Nobody has to follow standards if they don't want to, in practice...

dham 5y ago

Why does Javascript have to have all of Typescript brought into it? The browser has supported multiple scripting languages before. Not unprecedented. <script language="typescript" />

krapp 5y ago
Unfortunately, the HTML5 spec dropped the language option for the script tag, so browsers will only ever natively support javascript now and in the future. We're not going to get multiple languages back until something like runtime embedding through WASM becomes commonplace.

nick_ 5y ago

If only the ECMAScript/JavaScript community were this sensible.

ByteJockey 5y ago

Google controls JS to the point of being able to ignore the spec (e.g. that time they left TCO behind an experimental flag and it just went away despite being in the spec). As long as node and chrome are so dominant, we're probably not going to see big shake-ups in JS that aren't driven by Google themselves. JS is flexible, you can cover up a lot with polyfills, but not completely different syntax. Doing that without Google's buy in would create a rift in the internet that would either end with browser specific web pages, or with the complete loss of power for the committee that sets the ECMAScript spec as JS officially goes from being a language that is defined by a spec to a language defined by a canonical implementation (in this case V8).

LudwigNagasena 5y ago

Yeah, isn't TypeScript without enums and decorators already kind of "types as comments"?

city41 5y ago
TypeScript does support JSDoc type annotations and will use them to validate types in a JS project. https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

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 ago
  Why would more people adopt TS because it's native in browsers, which won't enforce specifying type annotations anyway?
  - mekster 5y ago
    No compiling process = easier?
- hombre_fatal 5y ago
  But 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.

throw_m239339 5y ago

This actually isn't dumb question. Nothing precludes Typescript from becoming another ECMA spec. It's just not going to be ECMAScript. Nothing precludes Microsoft from allowing Typescript to run directly in the browser either. Nothing. Just that nothing forces any other browser to support Typescript as well. Nobody has to follow standards if they don't want to, in practice...