type-annotations should only be enabled in the JS engine by the developer, during development, using a browser extension or flag. It should never be enabled by default for users!

[lukaszpolowczyk]

As in the title.

This should never be a standard for the web.

This is just a transplitter built into a web browser.

Making this the default behavior of a web browser's JS engine is a total misunderstanding.
This has absolutely no basis or sense.
This should not be part of ECMA-Script.

This is going into an unnecessary situation.

Again:

1. Developer creates a website.
2. Turns on HIS web browser, turns on a browser extension called "type-annotations".
   From then on, "type-annotations" are supported in HIS browser.
   This could also be a flag in about:config (in Firefox) that should NEVER be enabled by default for users.
3. This way the developer doesn't have to use transpilations WHEN TESTING HIS WEBSITE.
4. Once the developer has done his job, he transpiles and minifies his site anyway, and only then does the deploy.

That is: Built-in and enabled by default "type-annotations" IS COMPLETELY UNNECESSARY!!!

[dfabulich]

This repo has a code of conduct. There are good arguments to accept this proposal, and good arguments to reject it, but calling it "madness" is not appropriate.

More to the point, the repository is operated by people who are advancing the proposal. Calling the proposal "madness" won't persuade the owners of this repository to give up. You'd have to make an actual argument, one not already addressed in the README.

[lukaszpolowczyk]

@dfabulich Ok, I edited the post. Sorry.

It seems to me that there is nothing in the readme about the approach I described.
That type-annotations is just a flag or browser extension, and not enabled for users.

[dfabulich]

I've never heard of a TypeScript browser extension (or a Babel browser extension, for that matter). Does such a thing exist today? I did some Googling and didn't turn anything up.

[lukaszpolowczyk]

@dfabulich That's not there now. I propose this.
That web browsers, instead of making type-annotations built-in, make it behind a flag. It would be enabled with a flag.
OR
It would be enabled via an extension that activates an additional API.
Then (perhaps) the entire type-annotations API would come with the extension.
Browsers would just create an extension API that allows type-annotations to be delivered externally.

That is: Either type-annotations behind a flag, or provided by an extension.
And for one and the other, browsers would have to prepare such a capability.

The most important thing is that this type-annotations API should not be available in users' browsers.
It has to be something the developer turns on himself, or provides from outside, in HIS web browser. Only in his own.
That's the difference.

[giltayar]

@lukaszpolowczyk what you said can be true of any future feature in JavaScript. You can edit your description above and instead of "type-annotations" write "records and tuples" or "pattern matching" or any future feature, and it would still have the same semantic meaning.

What I'm missing here is the reason this should not belong in JavaScript. And while writing it, please note that in 2022, almost half of the Github PR that are JavaScript are actually written using type annotations (i.e. TypeScript) based.

[lukaszpolowczyk]

@giltayar "You can edit your description above and instead of "type-annotations" write "records and tuples" or "pattern matching" or any future feature, and it would still have the same semantic meaning."

I believe that no. "records and tuples" has an effect on the page. "type-annotations" has an effect only for a moment during development.

So "type-annotations" should be a function in the developer's web browser, not a function of web pages.

The rule should be: Reduce to the minimum.

This feature should not go beyond the developer's web browser.

"please note that in 2022, almost half of the Github PR that are JavaScript are actually written using type annotations (i.e. TypeScript) based."
But it's also not target code, used on pages anywhere.
Neither TypeScript nor "type-annotations" is a function of web pages, only a function for the developer, during development.

Important: Just because there are comments that can litter your code if you don't remove them before deployment, and just because someone may not use minification, doesn't mean you need to add another area of code litter on websites.
One "mistake" does not make it necessary to make another "mistake".

[lukaszpolowczyk]

@dfabulich As for the extension API for today, there is a way.
WebRequest API - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest

This allows you to replace any request. So it will let you swap a file containing "type-annotations", for a pure JavaScript file.

This can be done today.

This has advantages. Currently, transpilation requires creating additional files on disk, etc. (This was said as an argument for "type-annotations")
If transpilation is done in the developer's browser, via a browser extension, at the request, at least some of the problems disappear.

Of course, if it was built in, and only ignored code fragments, without transpilation, it would be more efficient.
But for that, you would have to make an additional API for extensions, which would allow, for example, to ignore code fragments in the browser, either at the AST level or in some other convenient place.

Or we'd go back to "type-annotations" behind the flag, enabled by the developer by toggling the flag in his browser. It would be less flexible, but perhaps require less work, and be even more efficient.

Note: Currently, new features are often introduced first after the flag. So technically there is no obstacle for this to happen with "type-annotations" as well. It's just that "type-annotations" should never be enabled for everyone, it should only be available to the developer and only to his web browser, if he enables it.

[Jack-Works]

As for the extension API for today, there is a way.
WebRequest API - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest

Note: This is not available in Chrome Extension Manifest V3 unless your extension is installed under an enterprise setup.

[lukaszpolowczyk]

@Jack-Works Ah yes, Chrome messed that up recently.

But the topic itself is about making an extension API specifically under "type-annotations" etc., or as a flag.

I showed this solution with the WebRequest API as a temporary, replacement anyway.

[dfabulich]

For those not familiar, webRequest was replaced with declarativeNetRequest matching Safari's extension API, which has never allowed any browser extension full unrestricted access to the body of web requests.

I believe an automatic Babel or TypeScript browser extension was never possible in Safari, and in January 2023 it will no longer be possible in Chrome.

(Furthermore, in my opinion, Chrome didn't screw this up; having unrestricted access to all web traffic, even encrypted traffic, is too much power for a browser extension to have. I think Apple made the right call here, and that Chrome is following Apple's lead.)

As a result, I don't believe it's possible to write an extension that does anything like this today in Safari or Chrome, and I predict that Apple, in particular, will never allow an extension like this.

[dfabulich]

The suggestion to only support this feature only behind a dev-only browser flag was also raised here: https://twitter.com/matthewcp/status/1501653855297277955

My understanding is that the motivation of this proposal is to unfork JavaScript. At TC39, @DanielRosenwasser presented a slide like this:

Problem Statement
The strong demand for ergonomic type annotation syntax has led to forks of JavaScript with custom syntax. This has introduced developer friction and means widely-used JS forks have trouble coordinating with TC39 and must risk syntax conflicts.

Proposal
Formalize an ergonomic syntax space for comments to integrate the needs of type-checked forks of ECMAScript.

This slide, which clarified the motivation of the proposal, was persuasive enough to the TC39 committee to allow this proposal to advance to Stage 1. (I've filed PR #156 to update the README.)

The "dev flag" proposal would not solve this problem. Instead of unforking JavaScript, it would formalize the fork. There would be two versions of the language, one version supporting type annotations, and another version not supporting type annotations; only one version would be supported in browsers by default.

Regardless of what we decide here, at least some developers will accidentally forget to minify their code before publishing it to users. Today, unminified code bloats the application, slowing it down. If we had a type-annotations browser flag, unminified code would fail to run in browsers. But, worse, if the browser flag was still on, the developer would not immediately be able to reproduce the bug. Users would say "your site is broken!" and the developer would say "weird, it looks fine on my machine" because the developer would have forgotten that the dev flag was enabled.

I think it's clear that any proposal to intentionally fork JavaScript in this way could never get past the TC39 committee. TC39 requires 100% consensus; it is certain that at least one TC39 member would describe this approach of intentionally and formally forking JavaScript as "breaking the web." (Specifically, I, myself, would describe formalizing the fork as "breaking the web," and I'm sure at least one TC39 member would agree with me.)

[ljharb]

@dfabulich to be clear, stage 1 primarily means TC39 is willing to invest more time exploring the problem space. It's important that stage advancements aren't over (or under) weighted as a signal.

While I agree with your analysis about forking, "breaking the web" has a very clear definition (albeit sometimes loosely interpreted) for which this simply can not apply: existing websites that work in a majority of browsers, would need to stop working when the change is deployed for it to be web-breaking.

[dfabulich]

Yeah, my main point is that some TC39 member(s) will not accept a dev flag to fork JavaScript, and so that can't be the way forward for this proposal. It doesn't really matter whether the TC39 member justifies their rejection with the argument "don't break the web."

(Though, I really do think some TC39 member would say that! "Don't break the web" has sometimes been used to argue against any backwards-incompatible versioning of JavaScript, even under a use es2025 pragma. "Don't break the web" means anything and everything that any TC39 member thinks it does.)

[ctcpip]

The focus needs to be on the merits (or demerits) of a proposal. Hypothesizing about how TC39 delegates will respond to anything is counterproductive and can have a chilling effect if everything is always gated on assumptions about how TC39 delegates will respond.

That being said, objections from delegates more often result in further consideration, iteration, and refinement of proposals, rather than stopping them dead in their tracks.

[dfabulich]

I disagree. The Type Annotations proposal can be (and has been) frequently sidetracked by unproductive discussions of how JavaScript could be better if we'd simply introduce a new, incompatible fork of JavaScript, or if everyone would just stop using TypeScript and use JSDoc instead.

We should welcome a "chilling effect" on proposals such as these, precisely because it's not obvious to folks making these suggestions that this really won't happen, really, and that discussing their merits and demerits is therefore a waste of time.

("But what if, in open conversation, we uncover a really compelling use case for a new, incompatible fork of JavaScript??" Even then, it's simply impossible to get 100% consensus from TC39 on this. All it takes is one member to say no. The rocks are littered with the corpses of people who thought they could sail these waters. Some of them had good ideas! Maybe even great ideas! But 100% consensus makes some good ideas unachievable.)

[dfabulich]

Setting aside the discussion of what is or isn't productive to discuss here, I wanted to address another point @lukaszpolowczyk made earlier in the thread.

Important: Just because there are comments that can litter your code if you don't remove them before deployment, and just because someone may not use minification, doesn't mean you need to add another area of code litter on websites.
One "mistake" does not make it necessary to make another "mistake".

As I read this argument, it says that allowing comments in JavaScript was a mistake, because comments should be removed (minified) before deployment. This proposal intends to make type-annotation comments more useful and easier to use, but since comments were a mistake, improving comments would compound on that mistake.

The FAQ already has an entry about this question:

https://github.com/tc39/proposal-type-annotations#will-the-ability-to-deploy-typed-source-code-directly-result-in-bloated-applications

Will the ability to deploy typed source code directly result in bloated applications?

Returning to a world where code does not strictly need to be compiled prior to being used in production means that developers may end up deploying more code than is necessary.
Hence larger payloads over-the-wire for remotely served apps, and more text to parse at load time.

However this situation already exists.
Today, many users omit a build step and ship large amounts of comments and other extraneous information, e.g. unminified code.
It remains a best practice to perform an ahead-of-time optimization step on code destined for production if the use-case is performance-sensitive.

I think this answer could use more elaboration, so I've filed PR #157 to address the question of whether allowing developers to skip transpilation will also encourage developers to skip minifying. I argue that it would not.

Specifically, note that the TypeScript compiler tsc does not have a built-in option to minify. Allowing TypeScript users to skip tsc during development will not inherently encourage users to skip a minification step, since that would have required separate action in any case.

Babel is another popular transpiler for TypeScript, Flow, and Hegel. Babel's preset-typescript and preset-flow transpilers do not minify. In Babel, minification requires a separate step. Allowing Babel users to omit preset-typescript will not encourage users to skip minification.

In this proposal, type annotations are treated as comments. Making comments more useful and easier to use is an appropriate evolution for JavaScript, even when we expect developers to remove comments and type annotations via minification.

[lukaszpolowczyk]

@dfabulich About webRequest - Actually I thought Safari should support webRequest. But it doesn't, sorry for the incomplete information.
As about Chrome - extension developers are VERY complaining about these limitations. Mozilla, fortunately, for the time being, continues to bend, and maintains webRequest, and continues to work for extension developers and for users.
After all, extensions are there to extend capabilities. Theoretically, it's all about balancing capabilities and security, but all of this makes the idea of extensions lose its meaning a bit. The user is willing to take a risk to have a better function provided by an extension, but security stands in the way. But that's a topic for another discussion.

As a last resort, you can establish Mozilla Firefox as the developers' web browser, and Chrome and Safari will be user-only browsers. :)
This is just a joke of course.

---

I know that the flag needs to be formalized anyway.
And rather my motivation against, is to litter the web. And I wrote from what approach it comes (The rule should be: Reduce to the minimum. etc.).

Even I myself wrote on Twitter then somewhere, when it was loudest about type-annotations.
Now I wrote a thread because I was saddened that type-annotations is still proposed as it is.

The "dev flag" proposal would not solve this problem. Instead of unforking JavaScript, it would formalize the fork. There would be two versions of the language, one version supporting type annotations, and another version not supporting type annotations; only one version would be supported in browsers by default.

There is some rationale in this, but not entirely, either. Currently there are a lot of development features, and they are behind flags (I've already written about this). And there is, for example, ServiceWorker after http, working only when DevTools is enabled.
Somehow it all works. I don't think anyone is complaining. No one calls it a fork, etc.

To make sure that the developer does not forget to disable the flag and test the target version, you can remedy, for example:

• allowing type-annotations only when DevTools is enabled (just like the operation of ServiceWorkers after http in Firefox DevTools).
• special marking in the browser "dev function mode" (similar to the Private Mode marking in browsers).
• a warn in the DevTools Console that the flag is on.
• maybe allow behind the flag, and only under localhost (rather not enough, but for the sake of formality I wrote).

I would call it a "developer's browser feature", not a "JavaScript fork" or "web breaking". That sounds less dramatic.

---

This proposal intends to make type-annotation comments more useful and easier to use

That would be true if we were talking about JSDoc. But we are talking about another, additional, separate comment syntax.

The FAQ already has an entry about this question:

I just disagreed with this FAQ entry.

The FAQ has an entry on this, but I wanted to elaborate on it, by pointing out that no popular transpiler minifies by default. Minification always requires a separate, non-default step.

That's not what I meant. I wrote it as an example of "littering the web" that exists - transpiler separately, minification separately.
That if there is one example that exists, it doesn't mean that you can create a new situation that will cause littering.
It was a response to someone else's argument. About creating a new field to litter - type-annotations enabled by default.
This refers to "However, this situation already exists." From the FAQ.

But it doesn't hurt to add this clarification of yours. Although I didn't raise it.

[dfabulich]

JavaScript is weird. In other languages, like Python, Java, or PHP, the "standard library" comes with the language, containing functions for files, networking, cryptography, etc. For most languages, their standard library is normally held to the same/similar standards as the language, and the standard library specifications might often appear in the same document (or at least alongside) the language syntax document, and they're both controlled by the same governance groups.

JavaScript's standard library is tiny. (This is partly due to TC39's "100% consensus" governance.) Look over the specification here: https://tc39.es/ecma262/ If the feature you're thinking of doesn't appear in that document, it's not part of "JavaScript," and it's not part of TC39's concern. Service Workers appear nowhere in there. The DevTools Console isn't in there. console isn't there. setTimeout() isn't there.

Those are all part of the DOM API. The DOM API includes stuff that most developers think of as "part of the language," including not only window and document, but also console.log(), fetch(), setTimeout(), and and structuredClone().

"Dev flags" might well be appropriate for some DOM APIs, especially ones that perform I/O over non-secure channels, but none of those are managed by TC39. TC39 owns the syntax of JavaScript (language keywords, parsing, etc.) and that stuff isn't controlled by a "dev-only" flag. (And it wouldn't/can't be, because at least one member would object to forking JavaScript in that way.)

I would call it a "developer's browser feature", not a "JavaScript fork" or "web breaking". That sounds less dramatic.

But this repository is a TC39 proposal, where we're discussing changing the syntax of the language. (Specifically, we're proposing changing the syntax of comments.)

However you decide to call it, you'd have to convince every TC39 member that the parsing the syntax of the language should change based on parameters from the host environment, and that there would be two versions of the syntax, both standardized. As long as any TC39 member thinks this is a bad idea, if anyone calls it forking, (and some members certainly will!) then adding a dev flag will not happen.

---

As for litter, if you weren't raising a "bloat" argument about this proposal, then I'm struggling to understand your point about litter. What exactly is the "litter" you're referring to?

I thought you were saying that all unminified comments are "litter," because they slow down web sites and apps, and that you argued that this proposal would result in more unminified comments (more "litter"). That's why I argued that this proposal wouldn't result in more unminified comments.

But I think you're saying that something else is litter. Maybe you think that type annotations are, themselves, "litter." But, if so, I'm unclear on what you mean by that.

Litter has no value. But JavaScript comments have value, right? They have no value to end users, (or negative value, because comments slow the program down) but that's why developers should remove comments via minification. Are all JavaScript comments "litter"? Is JSDoc "litter"?

---

This proposal intends to make type-annotation comments more useful and easier to use

That would be true if we were talking about JSDoc. But we are talking about another, additional, separate comment syntax.

This proposal is proposing a comment syntax that's easier to use than JSDoc, and more useful than JSDoc. Users of TypeScript and Flow have found this syntax so useful, (and so much more useful than JSDoc) that they've forked the language to gain these benefits. Thus, under this proposal, JavaScript will unfork the language, by making comments more useful and easier to use.

[lukaszpolowczyk]

It's good that you specify and differentiate between JavaScript and HTML APIs, etc., but I guess it doesn't change too much?
The point is that there is precedent in the practice of web browser developers, and developers.
Such functions, working on demand, only for the developer, is something that already exists and works.
And the purpose of this is to make these features disabled by default for simple users (for security reasons mainly, but still).

litter - code that does not affect the operation of the site, included in the code of the implemented site. It includes:

• declared but unused functions
• comments (including JSDoc)
• excessively long names of, for example, functions
• code without minification
• type-annotations

As you can see, the point is not that such code is unacceptable in general, but the point is to avoid it whenever possible. The point is to have as little of it as possible. (The rule should be: Reduce to the minimum).

I don't know what would be more compelling for TC39 members. Something that makes changes for every web user, or something that is only a function of the developer's browser?
Maybe I'm wrong, but the latter seems easier to accept.

This proposal is proposing a comment syntax that's easier to use than JSDoc, and more useful than JSDoc. Users of TypeScript and Flow have found this syntax so useful, (and so much more useful than JSDoc) that they've forked the language to gain these benefits. Thus, under this proposal, JavaScript will unfork the language, by making comments more useful and easier to use.

Well, but there will be those benefits. After all, on I am in favor of type-annotations, but as a feature of the developer's web browser, not implemented for the user's web pages.

[rektide]

No one asked me, but it's very unclear to me what the complaints actually are in this issue. It don't know what would be bad or wrong from the description posted here, what the harm would be. Is this a performance concern? What's bad here?

This is just a transplitter built into a web browser.

So what? What does that mean? Why should we be concerned about that? What are the dangers? What outcomes do you not want to see, and why?

[lukaszpolowczyk]

@rektide There is no need to build DEVELOPER FUNCTION into websites.
A function that is nothing that does anything on a website.
It can be done, without creating support for additional garbage in the code.

[spotandjake]

@rektide There is no need to build DEVELOPER FUNCTION into websites.
A function that is nothing that does anything on a website.
It can be done, without creating support for additional garbage in the code.

Considering javascript isn't just used on the web but also server side. What about in node transpiration requires installing dependencies and setting your project up with npm there are tools like tsnode but they are rather slow and still require some setup. This would create a super simple way to make scripts with the benefits of type syntax on the server side where it isn't considered garbage because you often are not shipping that code.

As for what you are suggesting with a flag, I see an issue there all the current flags refer to experimental api's this is a fully fledged developer api, its a different concept entirely.

As per what you are noting about this being garbage and litter it is negligible in comparison to all the other forms of waste such as comments any developer who actually wants a fast website should be using minification. This pr greatly reduces develop friction especially when working on smaller scripts. One thought would be if these type comments are detected logging a browser warning to the console that notes the website is in dev mode that could be controversial though but is an alternative idea that would help prevent this code being shipped while allowing this pr to reduce friction during development.

One idea though towards the idea of adding it being development only would be only allow it similar to strict mode with a

'use types';

at the top of your program. This could also be saved for the future though and allow the same syntax to be used for runtime typing in js.

This issue title also seems like it would be better off being changed to something like:

Consider Making type-annotations a developer only feature.

Given the scope seems to have grown to an argument for it being a development only feature rather then just relating to a flag or browser extension.

[Eiluviann]

I don't think you understand what's the point of this proposal. This adds support for type annotations. We already add type annotations using JSDoc. No one is going to be forcing you to add types to your code and the types won't be validated on runtime either. You can think of it as a new way of adding comments to your code but for specific information - types.

JSDoc takes a lot of space and is quite redundant, this proposal will combine type documentation with function declaration. You save space and code is more readable. It's only adding support, types are already "opt-in" only.

[ivanjeremic]

I don't think you understand what's the point of this proposal. This adds support for type annotations. We already add type annotations using JSDoc. No one is going to be forcing you to add types to your code and the types won't be validated on runtime either. You can think of it as a new way of adding comments to your code but for specific information - types.

JSDoc takes a lot of space and is quite redundant, this proposal will combine type documentation with function declaration. You save space and code is more readable. It's only adding support, types are already "opt-in" only.

I agree and I like that they are comments for special information like types, but I somehow feel why don't go with the existing

/**
 my types...
* 

from JSDOC instead of trying to add the new comment syntax to engines just so it can look like typescript, Note I didn't say use JSDOC syntax I just mean write types in the existing

/**
 my types...!
* 

I think not adding types to the code directly keeps it clean and nice to look at.
Types in /**..*/ Comments are the perfect place to describe things, (which is why comments in languages exist for decades) and describing Types in here just makes sense because it is for decades a place to "describe" something in the code below, so JS going with /**..*/ would not only make adding types to the language easier without changes to the engine it would also be a better place, since like already said is easier to read & write, and would make JS even more unique and be a good example for making the right decision in changing the syntax without actually changing it.

[idleman]

I think not adding types to the code directly keeps it clean and nice to look at.

That is the most common critic against TypeScript, it bloats the code and is probably one of the reason why TypeScript code contains more bugs compared to the JavaScript ones. A recent research study makes it clear.

[ivanjeremic]

---

I think not adding types to the code directly keeps it clean and nice to look at.

That is the most common critic against TypeScript, it bloats the code and is probably one of the reason why TypeScript code contains more bugs compared to the JavaScript ones. A recent research study makes it clear.

To be clear what my position is here, I really want asap. types in JavaScript and I don't think Engine Devs should "NOT" focus on them like @lukaszpolowczyk said. I think having types is important all I say and want is to have them in Comments not between the code all over the place.

[lukaszpolowczyk]

@ivanjeremic I use JSDoc and I'm fine with it. It is more clear to me.
JSDoc is for developers, that's what you don't need to support in browsers. Well, unless in DevTools, some type checking stored in JSDoc. Nothing else.

[ivanjeremic]

@ivanjeremic I use JSDoc and I'm fine with it. It is more transparent for me.

I use JSDoc and I'm fine with it. It is more clear to me. JSDoc is for developers, that's what you don't need to support in browsers. Well, unless in DevTools, some type checking stored in JSDoc. Nothing else.

JSDOC is a nice project but JSDOC types are not officially part of ECMA Spec, I want JS to get official spec for types and I want them to be in comments, I think it is still not clear to you what this spec does or mean, nothing changes for you even if it gets implemented, you seem confused about this proposal. "YOU DON'T NEED TO WRITE TYPES" like proposed, it is optional and will forever be just like you don't need to use Comments //in your code.

[Eiluviann]

Your critiques are valid but reasons for blocking the submission are not. Fact that something is not appealing to you and you won't use it is not a valid reason to block a support for something. It's entirely optional. Presence or lack of static types will not affect the runtime as they won't be validated. This is documentation which can be used in IDEs for error checking, that's it.

Also don't try to argument it with "time and effort", you do not have any insight into the workload of JS engine devs nor do you fund their team. This is a support for an optional feature, does not affect you if you don't want to use it, development of this feature does not affect the release timeline and it has no financial cost to you or the community. This proposal isn't going to force you to switch from JSDoc to static in-code types.

I don't like seeing some code formattings but I'm not going to vote to discontinue support for them just because I think it's ugly. It works for whoever wants to use it.

I'd like to point out that the syntax would be treated as comments. You can purge it from production code, just like you purge JSDoc and other comment blocks.

When I read your comments it feels like you don't even know how types work in TypeScript. In case of TypeScript types are validated before they are compiled to JavaScript. You do not execute .ts files, you execute compiled .js files. If you play around with configuration you can even omit the validation and your code would run as if there weren't any types there, just compiled TS to JS.

[ctcpip]

Gentle reminder that all participants are expected to abide by the TC39 Code of Conduct. In summary:

• Be respectful
• Be friendly and patient
• Be inclusive
• Be considerate
• Be careful in the words that you choose
• When we disagree, try to understand why

[Eiluviann]

Let's dissect then.

In the original post you only describe what you propose we do instead of introducing this new standard, you did not explain why you think it's a bad idea. Proposal would not be a transpiler (I assume that's what you meant), proposal is an addition to the syntax.

This should never be a standard for the web.

This is just a transplitter built into a web browser.

Making this the default behavior of a web browser's JS engine is a total misunderstanding. This has absolutely no basis or sense. This should not be part of ECMA-Script.

This is going into an unnecessary situation.
(...)
That is: Built-in and enabled by default "type-annotations" IS COMPLETELY UNNECESSARY!!!

Then you go onto explaining that this should be an API (not how APIs work) or an extension. That's not how types work. As per proposal types would be embedded in the code. You already embed types in code using JSDoc but you contain all of them in a single comment block. Just like with JSDoc - it doesn't matter if you keep those comment blocks or not in production, if you want you'll minifying anyway.

@dfabulich That's not there now. I propose this. That web browsers, instead of making type-annotations built-in, make it behind a flag. It would be enabled with a flag. OR It would be enabled via an extension that activates an additional API. Then (perhaps) the entire type-annotations API would come with the extension. Browsers would just create an extension API that allows type-annotations to be delivered externally.

That is: Either type-annotations behind a flag, or provided by an extension. And for one and the other, browsers would have to prepare such a capability.

The most important thing is that this type-annotations API should not be available in users' browsers. It has to be something the developer turns on himself, or provides from outside, in HIS web browser. Only in his own. That's the difference.

Here you say that TypeScript and type annotations are a "function" for developers during development. That's exactly it. No one has ever said that this standard is some kind of a website functionality (although I don't understand what is the category). In fact it was highlighted that this is to standardize and make it easier for developers to add types to their code. Comments and JSDoc are also for developers yet you are not forbidden from executing your code because it contains them.

So "type-annotations" should be a function in the developer's web browser, not a function of web pages.
(...)
This feature should not go beyond the developer's web browser.

"please note that in 2022, almost half of the Github PR that are JavaScript are actually written using type annotations (i.e. TypeScript) based." But it's also not target code, used on pages anywhere. Neither TypeScript nor "type-annotations" is a function of web pages, only a function for the developer, during development.

Lastly the below comment makes no sense (at least to me). What do you mean "building developer functions into websites"?

@rektide There is no need to build DEVELOPER FUNCTION into websites. A function that is nothing that does anything on a website. It can be done, without creating support for additional garbage in the code.

Feel free to correct me on any assumptions.

Lastly:

• TC39 is responsible for defining standards for JavaScript, not developing JS engine used in chrome or other browsers
• JavaScript is not only executed in the browser but also by the server (i.e. server side rendering, javascript backends)
• You cannot simply alter syntax interpretation with an addon or an extension
• You can include non-functional (as in "developer only") functionalities (i.e. comment blocks, JSDoc) and they should not prevent you from running your code
• Proposed standards adds additional layer of comments to the code which can be utilized by other tools (ex. VSCode) to type-check your code and warn you of potential errors but it does not introduce any validation upon execution meaning the additional comments are simply omitted.

[Eiluviann]

Just to be clear - what is proposed here is an alternative to what we already do in JS to type check. Current solution is to utilize JSDoc for defining static types and use ts-check in VSCode for error checking. This proposal would drastically improve code readability and developer experience and you can still use JSDoc on top of that to compliment it with readmes, sources and other comments.

[idleman]

Just to be clear - what is proposed here is an alternative to what we already do in JS to type check. Current solution is to utilize JSDoc for defining static types and use ts-check in VSCode for error checking. This proposal would drastically improve code readability and developer experience and you can still use JSDoc on top of that to compliment it with readmes, sources and other comments.

This a huge subjective claim and there is no evidence this is the case. To be honest, TypeScript code contains equal or more bugs than JavaScript code. See research paper here. And this is the overall problem in this community, too many subjective feelings and claims that lack deeper knowledge. There is people on both sides, so it is therefore extremely important a proposal has technical benefits that everyone can agree with. And here comes the problem. This proposal, at the current state has no technical benefits. This is also hinted in the meetings notes if I remember correctly. It is completely understandable if people find this proposal offensive. Subjective thoughts, no matter how many people who has it, million or billions, should never matter, only pure technical benefits.

[Eiluviann]

This is NOT a discussion whether you should or should not use static types. This is an improvement for people who do use types in their JS code.

[lukaszpolowczyk]

@ivanjeremic Few people know, but there is a "simplified JSDoc" syntax in VSCode, in the form of an experiment to be included:

Now imagine that VSCode adds another option - "TypeScript mode" for "simplified JSDoc". Then the character /* and */ disappear IN THE EDITOR (not in the text file itself), and only the comment content is visible, that is, the visible code looks identical to TypeScript.

Thus, in VSCode you have visually the same as in TypeScript, only you don't have to clean it up when transpiling TypeScript -> JavaScript, nor does the Gecko/Blink/WebKit engine have to bypass "type-annotations" - because types are still inside the simple /* ... */, as in JSDoc.

And in a simple text editor, it's still visually quite clear to edit, even if the /* and */ are visible.

---

Simple, type-annotations is a complete overkill, and it's the worst possible idea we could come up with. Even though the problem itself is real.