It is becoming more likely that TS and JS are becoming one language.
So here are some of my thoughts as of the end of 2024:
()=>{} is ugly enough.
():void=>{} is worse.
Don't do https://github.com/tc39/proposal-type-annotations.
Clearly separating impacting and unimpacting code might not be the worst idea.
/** @type {true | null} */
let b = something || somethingElse;
vs.
let b: true | null = something || somethingElse;
Everybody already knows that comments do not impact.
People have to learn and remember what part of TS syntax does not impact. Or they can apply the "comments don't impact" principle.
It is in line with the nature of what a type in a dynamic language is.
Lots of types can be inferred. TS already does it.
let str = "string";
If the rules of when something is inferred and when it is not are clear and simple inferring trumps explicit type declarations.
I am not advocating for any less build time type-checking. Use and create tools that type-check your JS files just as strict and even stricter than your TS files.
The goal is for the .js file ecosystem
to become safer than the .ts file ecosystem.
Eliminating the transpilation step makes the type-checking step optional. That is something to be wary of, but speeds things up and adds flexibility.
The Google people seem to prefer keeping JavaScript simple.
JS0 slides: https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o
TS already allows to express types in comments in .js files.
I do believe they fit in there.
I would not clutter the JS syntax any more for this purpose.
Once sufficient tooling exists for commented types in JS: TS syntax can die.