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.