I'm sure that this has been discussed somewhere extensively but what is the status on supporting type declarations?
// before
var x = 10;
// with type declaration
var x: number = 10;
// before
var response = await fetch("post");
// with type declaration
var response: Promise<Response> = await fetch("post");
I have four reasons for supporting it instead of using typescript type inference.
I read that and a related post about a meeting held a year ago and the topic was brought up.
But I couldn't find if the answer was, yes we want to support it or no we don't want to support it.
If the feature is built already could it be enabled behind a flag?
If it is not built could it be added and then put behind a flag?
And a related question, is it possible to add versioning metadata to JS documents where you could inform the compiler that this version of Javascript you are writing is version 2024 and that means you, the compiler can handle (leave in or take out) the type annotations?
Versioned document:
#ecma2024
var x: number = 10;
Sort of like strict mode
It isn’t built, because its design is nowhere near agreed upon.
There’s lots of material you can google for about why versioning JavaScript would be a bad idea.
The proposal is stage 1. So that means the committee agreed there was interest in exploring the problem space. The TC39 Process
That proposal is not behind a flag in any browser. However a similar feature is available in server runtimes like Node.js, Deno, Bun.
Flags and versioning has been avoided so far, with the exception of strict mode. It makes the language more complicated.
Similar to: GitHub - tc39/faq
I read the TC39 process, the TC39 faq link, and then read the test262 repository readmes (2).
One comment about this. In the readme for the test262 testing harness for node-js I found this block of code:
module.exports = function(test) {
try {
test.contents = babel.transform(test.contents, options).code;
} catch (error) {
test.result = {
stderr: `${error.name}: ${error.message}\n`,
stdout: '',
error
};
}
return test;
};
Immediately I thought what type is the test parameter? What type is error? What type is test.result? It looks like poorly written code. And by itself it's missing the type information that tells the code reader what those objects are and what to expect.
And that author knows that. He knows it's missing information. He has to make a comment about it before hand:
In some cases, a preprocessor may want to signal to Test262-Harness that a certain result has already been reached, and that it must not further evaluate the test. To create this signal, the preprocessor creates a result property on the Test262Test object, which will indicate to Test262-Harness that it must not evaluate the test, but instead return the value of the result property as though the test had been executed. For example, a preprocessor may attempt to transpile the value of test.contents—which may fail! In the case of failure, the preprocessor can create a result property whose value is a Result Object. This will skip the code evaluation and report the given result object.
I'm mentioning this as an example that without typing JS code is missing information. Without typing JS can't be self documenting. Without typing it can't self-inform the author of preventable errors (without tooling).
My comment on this is that my application // developer experience has been this:
You could just say version 1 is everything before.
Version 2 is this new branch / new VM path.
If you did that you'd only have to support two versions / branches (and not forever).
When version II had major browser support in VMs then JS developers / web authors could switch to it if they chose to and not break the web. I understand the reasoning behind avoiding versioning. If things are that hard to implement, then make a version 2 path and you could add new features to that new path to eventually only have to support one branch. That's if things can't be done otherwise.
Yes, they would all have to be supported forever, because we can never break the web. Forever is a very very very long time.
You misunderstood. I don't suggest versioning. I suggest two branches. One is the existing that is supported forever and the other would be version next. It could be designed from the ground up. New future features could appear and be added to that branch. It is not the same as versioning. Existing branch could have features added or bugs fixed on a feature by feature basis. It would or could be less work and more supportable by having a separate version next branch.
The main drawback is that version next may have to have major browser support before it could be used (that's mainly client side though). But that could be up to the javascript author. They already have to decide that with feature testing.
"not only one branch" is versioning, and every "version" that was ever released would have to be supported forever.
FWIW, some JavaScript features do get implemented by browsers behind a flag which can be enabled in the browser settings. It's up to browsers if they want to use that technique to gain more information about a proposal.
What you're suggesting here would be a fork: developing an entirely new language that is incompatible with and grows in a different direction than JavaScript (even if possibly sharing common roots).
Indeed the main problem with that is to get browser makers to support it, if you don't just want to compile to JavaScript. This has been tried before, see Dart and WebAssembly for two examples of how it went.