7 ms·

ECMAScript Proposal: Types as Comments

65 points by 0xedb 5y ago

sergiomattei 5y ago
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...
TazeTSchnitzel 5y ago
Ignoring the type declarations gives some freedom to type checkers to decide what meaning they have, but it also makes them useless to the runtime. I think that's a shame. Could JavaScript engines not benefit from the type information? PHP does.
- olliej 5y ago
  JS engines would not benefit significantly from the annotations (there may be some slight wins in code density through coalesced checks, but there would be increases in other data structures). Explicit types in this case are primarily a tool to make writing large scale software easier. But ignoring the types is actually worse than “not being helpful”, as it both locks in the current syntax (unlike claims it does provide space for experimentation), and it means that engines cannot in future start enforcing the types specified with this syntax.
mattlondon 5y ago
Why go to the effort of doing all of this, but not use typescript? I don't see the point - they mention ignoring the build step, but it's not like that is particularly annoying at the moment, at least not in the largish-projects I've worked on (enterprise angular apps staffed by approx 50-60 frontend engineers, so fairly chunky codebase)
- zapt02 5y ago
  Most apps are not staffed by 50-60 frontend engineers, so simplifying for solo devs (which is by definition the majority of developers) is worthwhile.
  - vinnymac 5y ago
    Most applications are certainly not staffed by large teams, but the advantages would be best seen in large codebases. Most solo developers are working on much smaller TypeScript codebases, and won't experience many issues with the build system. TypeScript is the main language that I program in every day, and I don't see the advantages of this proposal outweighing the disadvantages.
  - mekster 5y ago
    I would think the opposite. Solo devs are in the most flexible state and they don't care if they need to go through a bit of inconvenience for a slight boon to code quality but say you got several average devs who can only be taught on how to do these things, it gets annoying to set it all up and make sure nothing breaks or you'll be wasting time babysitting their environment.
    - giraffe_lady 5y ago
      > they don't care if Bold to speak for the group of devs likely to have the most variety. Personally I hate twiddling with build systems and will happily write worse code to avoid it so what I do know.
    - pjmlp 5y ago
      On my solo projects, I never care about JavaScript build infrastructure, it is all pure vanilaJS. It feels so liberating not having to deal with the usual mess of JavaScript toolchains.
dlbucci 5y ago
This topic came up earlier this week, and I just don't see what the big win is. I guess people want to be able to skip setting up a build system for TypeScript, but if you do that, you'll be sending a bunch of extra junk to browsers that will just be ignored. So you'll need to setup a minifier to strip it all out, which means you have to setup a build system anyway. Is there some other advantage? Easier debugging on the client, I guess, but proper source maps do that pretty well already. I dunno, this just seems to be making a complex language more complex for not much gain. That said, if the runtime actually used the types for safety or performance, I could maybe see some value added there.
- niedzielski 5y ago
  I wondered about this as well but speculated that basic compression, either gzip or Brotli, would account for it and, in the case that someone doesn't care about bundling their code, they probably don't care if it has comments (types) in it. If they do care about bundling, even if that is just `cat`, then I think the code is "built" to some extent already. I would enjoy the flexibility to ship types but personally don't have any need for it. Seems like "boiling the frog" for type-checking in the browsers to me but I personally like the idea of encouraging more typing in native JavaScript.
- vbezhenar 5y ago
  Browser could build optional type support (for example with warnings), so you can leverage it and skip all packaging stuff. And sending few percent of JavaScript is not an issue. It's gzipped well and it's not what will slow down the website. For example I really love that I can just write modern JavaScript and just send it to the browser and it works. Serious websites of course will use minifiers and stuff, but for some small sites it's unnecessary burden.
  - olliej 5y ago
    No they can’t. The effect of unenforced type annotations is that sites will end up writing code that is incorrect but works. Any future attempt to enforce the types will break that content, and so cannot reuse the : syntax for type annotations, but browsers will continue to have to support it. Mode switches are also not the solution: strict mode is responsible for a huge amount of complexity in the ES spec, and many annoying edge cases in JS implementations. The only reason I was ok with strict mode is the removal of |this| coercion, which could only be done via a mode switch. No other changes in strict mode would have warranted the mode switch. Adding type annotations to JS would not require a mode switch as it is a purely additive feature (as let and for(of) were), but adding the burden of the syntax without actually adding the semantics makes absolutely no sense - it burns the prefer type annotations syntax, it adds complexity to the language, complexity to the engines, and provides no actual improvements to the ergonomics of the language.
orangepanda 5y ago
This proposal doesnt support the full typescript syntax, you'll need a build step anyway. What problem does it solve?
- w3news 5y ago
  No, you don't need a build system, but most developers cannot work anymore without a build system. And what about node.js, it's a lot better to skip a build step. I think typescript is a temp hype just like jQuery, useful for many, but a few people can just do the vanilla JavaScript way.
- throw_m239339 5y ago
  It solves absolutely nothing for the people who do not use Typescript.
montroser 5y ago
Previous discussion: https://news.ycombinator.com/item?id=30626458 https://news.ycombinator.com/item?id=30626458
olliej 5y ago
Is this the same bad idea from MS earlier this week, or is it a completely different spec of the same bad idea? There are many reasons this concept of “unenforced type syntax” is flawed, and from the threads for the MS proposal there are already JS consoles/CLIs that support TS.
0xCAP 5y ago
This feels completely unneeded and a huge step backwards. Sure, TypeScript's language server is slow af, and making it better is no easy task, but TypeScript's syntax and overall language mechanics are the best I've ever used and I'm not trading them for whatever DX improvement this stuff promises to bring.

65 points by 0xedb 5y ago

sergiomattei 5y ago

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...

TazeTSchnitzel 5y ago

Ignoring the type declarations gives some freedom to type checkers to decide what meaning they have, but it also makes them useless to the runtime. I think that's a shame. Could JavaScript engines not benefit from the type information? PHP does.

olliej 5y ago
JS engines would not benefit significantly from the annotations (there may be some slight wins in code density through coalesced checks, but there would be increases in other data structures). Explicit types in this case are primarily a tool to make writing large scale software easier. But ignoring the types is actually worse than “not being helpful”, as it both locks in the current syntax (unlike claims it does provide space for experimentation), and it means that engines cannot in future start enforcing the types specified with this syntax.

mattlondon 5y ago

Why go to the effort of doing all of this, but not use typescript? I don't see the point - they mention ignoring the build step, but it's not like that is particularly annoying at the moment, at least not in the largish-projects I've worked on (enterprise angular apps staffed by approx 50-60 frontend engineers, so fairly chunky codebase)

zapt02 5y ago
Most apps are not staffed by 50-60 frontend engineers, so simplifying for solo devs (which is by definition the majority of developers) is worthwhile.
- vinnymac 5y ago
  Most applications are certainly not staffed by large teams, but the advantages would be best seen in large codebases. Most solo developers are working on much smaller TypeScript codebases, and won't experience many issues with the build system. TypeScript is the main language that I program in every day, and I don't see the advantages of this proposal outweighing the disadvantages.
- mekster 5y ago
  I would think the opposite. Solo devs are in the most flexible state and they don't care if they need to go through a bit of inconvenience for a slight boon to code quality but say you got several average devs who can only be taught on how to do these things, it gets annoying to set it all up and make sure nothing breaks or you'll be wasting time babysitting their environment.
  - giraffe_lady 5y ago
    > they don't care if Bold to speak for the group of devs likely to have the most variety. Personally I hate twiddling with build systems and will happily write worse code to avoid it so what I do know.
  - pjmlp 5y ago
    On my solo projects, I never care about JavaScript build infrastructure, it is all pure vanilaJS. It feels so liberating not having to deal with the usual mess of JavaScript toolchains.

dlbucci 5y ago

This topic came up earlier this week, and I just don't see what the big win is. I guess people want to be able to skip setting up a build system for TypeScript, but if you do that, you'll be sending a bunch of extra junk to browsers that will just be ignored. So you'll need to setup a minifier to strip it all out, which means you have to setup a build system anyway. Is there some other advantage? Easier debugging on the client, I guess, but proper source maps do that pretty well already. I dunno, this just seems to be making a complex language more complex for not much gain. That said, if the runtime actually used the types for safety or performance, I could maybe see some value added there.

niedzielski 5y ago
I wondered about this as well but speculated that basic compression, either gzip or Brotli, would account for it and, in the case that someone doesn't care about bundling their code, they probably don't care if it has comments (types) in it. If they do care about bundling, even if that is just `cat`, then I think the code is "built" to some extent already. I would enjoy the flexibility to ship types but personally don't have any need for it. Seems like "boiling the frog" for type-checking in the browsers to me but I personally like the idea of encouraging more typing in native JavaScript.
vbezhenar 5y ago
Browser could build optional type support (for example with warnings), so you can leverage it and skip all packaging stuff. And sending few percent of JavaScript is not an issue. It's gzipped well and it's not what will slow down the website. For example I really love that I can just write modern JavaScript and just send it to the browser and it works. Serious websites of course will use minifiers and stuff, but for some small sites it's unnecessary burden.
- olliej 5y ago
  No they can’t. The effect of unenforced type annotations is that sites will end up writing code that is incorrect but works. Any future attempt to enforce the types will break that content, and so cannot reuse the : syntax for type annotations, but browsers will continue to have to support it. Mode switches are also not the solution: strict mode is responsible for a huge amount of complexity in the ES spec, and many annoying edge cases in JS implementations. The only reason I was ok with strict mode is the removal of |this| coercion, which could only be done via a mode switch. No other changes in strict mode would have warranted the mode switch. Adding type annotations to JS would not require a mode switch as it is a purely additive feature (as let and for(of) were), but adding the burden of the syntax without actually adding the semantics makes absolutely no sense - it burns the prefer type annotations syntax, it adds complexity to the language, complexity to the engines, and provides no actual improvements to the ergonomics of the language.

orangepanda 5y ago

This proposal doesnt support the full typescript syntax, you'll need a build step anyway. What problem does it solve?

w3news 5y ago
No, you don't need a build system, but most developers cannot work anymore without a build system. And what about node.js, it's a lot better to skip a build step. I think typescript is a temp hype just like jQuery, useful for many, but a few people can just do the vanilla JavaScript way.
throw_m239339 5y ago
It solves absolutely nothing for the people who do not use Typescript.

montroser 5y ago

Previous discussion: https://news.ycombinator.com/item?id=30626458 https://news.ycombinator.com/item?id=30626458

olliej 5y ago

Is this the same bad idea from MS earlier this week, or is it a completely different spec of the same bad idea? There are many reasons this concept of “unenforced type syntax” is flawed, and from the threads for the MS proposal there are already JS consoles/CLIs that support TS.

0xCAP 5y ago

This feels completely unneeded and a huge step backwards. Sure, TypeScript's language server is slow af, and making it better is no easy task, but TypeScript's syntax and overall language mechanics are the best I've ever used and I'm not trading them for whatever DX improvement this stuff promises to bring.