Is there any hope of optional typing landing in ecmascript in future? Checking arguments at top of scope in functions, methods and constructors is getting really boring. It could even open the door to allow ecmascript to be a reasonable option for writing wasm.
Have you experimented with TypeScript at all?
There's also AssemblyScript.
1 Like
@aclaymore @senocular I use both TypeScript and AssemblyScript, and I'm avid in the AssemblyScript community, working on projects like,
and others.
It would be really nice to have type syntax officially in EcmasScript. This would also, as @ReinsBrain mentioned, open the door to compiling to WebAssembly (or even native) in a standard way, and would allow multiple implementations (even the browser engine) to exist and be interoperable.
If people could opt into type syntax and get type checking in the JS engine without any tooling, that'd be a huge win for the large amount of entry developers looking to easily start writing apps with minimal barrier to entry.
TypeScript and AssemblyScript both require a fair amount of build system knowledge in comparison.
1 Like
The following discussion moved here:
@ljharb the last thing you mentioned about the possibility of preventing (with string pragmas) a backwards compatibility nightmare if we were to enable optional types that the interpreter ignores and then making then errors later, was
@trusktr at present i don't believe it can ever possibly be prevented.
Would it better if we started with a tiny set of type features that introduce errors at the same time, so we con move forward towards the eventual best path? (avoiding a big all-at-once thing that might include mistakes we may regret?)
What I'm imagining is then something like what @WebReflection mentioned:
// no types used here
let a = 123
let b = a // ok
let c = b // ok
a = "string" // ok
b = a // ok
c = b // ok
then we can start to introduce types:
// type annotations added to the file
// do we want more-specific number types? Maybe `number` is the most generic and we can add more later?
let a: number = 123
let b = a // ok, b inferred as `number`
let c = b // ok, c inferred as `number`
a = "string" // causes an error (at runtime? or at parse time?), 'string' not assignable to 'number'
// These would be ok according to the inferred types, but this code is irrelevant due to the previous error.
b = a // ok
c = b // ok
The following is a live example of the type error using Hegel.js:
Hegel is a highly-inferring type system that is capable of making meaningful types out of plain JavaScript without type annotations, but type annotations can be used to specify intent as needed in order to override inference. TypeScript on the other hand likes to make everything type any, which is less beneficial.
A new version of Hegel is in the works but not released yet:
https://twitter.com/rage_monk/status/1468917558078283779?s=20
Here is another example showing Hegel's type inference on the same example, but without a type annotation:
Here's a more advanced example including a function, still with no type annotations:
I'm not sure how we could enable such a type inferring system in JavaScript without it being a breaking change (@ljharb any ideas?). Maybe the only way is to opt in with type annotations?
Being able to have the sort of type inference as in Hegel without requiring type annotations is really convenient and useful.
I don't understand how string pragmas can help in any way with syntax additions.
My understanding of string pragmas is that they change the runtime behavior in a backwards compatible way, so that implementations that don't recognize the pragma simply ignores it. Thus the changes enabled have to be strictly runtime and less permissive that without the pragma.
Type annotations are usually in the form of new syntax (except for JSDoc style), which wouldn't be parse time compatible. The only thing I can imagine is a one time breaking change to carve out a place where typing syntax can live an be ignored at runtime (aka make TS/Flow valid JS syntax), then in the future add string pragmas to opt into some kind of runtime check based on a specific flavor of the typings.
However my understanding is that even a syntax carve out for typings previously failed or got stuck. For example GitHub - samuelgoto/proposal-optional-types: A proposal for an optional type system for JS.
Or, we could go with what we already have: lintable comments that provide non-runtime annotations and can never cause runtime behavior in any edition of the spec. JSDoc is one flavor (or set of flavors, since there’s multiple kinds of jsdoc), but you could certainly invent your own.
Having done, JSDoc style typing as well as Flow and TypeScript, I admit that there is a significant overhead with stuffing type annotations into structured comments. JSDoc is fairly cumbersome compared to TS/Flow. Furthermore, most syntax used by TS/Flow is virtually unavailable to JavaScript at this point (as-is JSX unfortunately), so an argument could be made that introducing type carve outs is codifying reality. While I'd personally love to see inert typing syntax in JavaScript, I sure am not willing to pick up that battle.
2 Likes
runtime type checks would be so awesome though. So the syntax would have to have runtime behavior up front to make that possible, and to avoid having one inert syntax, and one runtime syntax (if the first syntax takes up all the space, just imagine what the second one would look like).
If you haven't seen them, there are libraries that have looked at taking the 'inert' syntax and outputting the necessary runtime checks:
e.g.
function f(v: string) { ... }
compiles to something like:
function f(v) {
assertString(v);
...
}
Look what people voted for in State of JS:
2 Likes
Microsoft is putting inertia behind this proposal:
3 Likes
They're doing the same thing I suggested "type hinting", a.k.a types as comments;
Which nobody here's interested in unfortunately.
I have used typescript - i think it would be a great basis upon which to include optional typing into javascript. i'm thinking 'use strict-typing' declaration at the top would be nice way to inform the javascript engine of intent
1 Like
just checked back on assemblyscript after a few years - really nice progress on that project
looks like it's number 1 again this year : The State of JS 2022: Opinions
although i might add that #5 on the list is Observable ( seems many missed the memo re: Proxy )
1 Like
number 1 again (and #4) on state of js 2024: State of JavaScript 2024: Features ... looking forward to seeing Type Annotations proposal moving forward.
To progress to Stage 2 the proposal needs to show that the solution space has been fully explored, and that's difficult because the proposal has not articulated (does not articulate) a generalized problem statement.
It is my feeling that any such generalized problem statement would make it clear that the Type Annotations proposal competes directly with other proposals for generalized parser augmentation including DMChurch's and mine, BABLR. My solution is under very active development and specifically innovates in permitting parser extension without requiring central blessing of new syntaxes by TC39.
I think central blessing of specific syntax extensions is improper in general because it creates an unlevel playing field which favors the incumbent technologies by forcing would-be new players to have a (clearly-reviled) build step unless they choose to look exactly like TS looks.
If you agree with the premise that blessing a particular syntax extension is wrong but that syntax extensions in general are a proven concept which deserve support (at runtime), then it starts to look like there was tremendous progress on achieving these much-voted-for goals in 2024. I would hope that the committee will see things in the same light and will consider these as three competing proposals in the same solution space so that it would be appropriate to consider all of them before one advances to Stage 2.
Thanks for responding. I can only offer my subjective opinion which is I favor whatever gets us there sooner because it's taking a long time :)
At this point I believe am the expert on this topic, not by way of official designation but because I've done the work of exploring the complete design space and coming up with a concrete proposal and a reference implementation for that proposal.
What makes it strange is that my proposal takes the form of a bootstrapped compiler -- a system of grammars which uses its own grammars to define itself. This is really the only way to build this since BABLR is intended to replace Babel as the way in which syntaxes are proposed to (and accepted by) TC39.
I don't believe that any committee is likely to be able to give me permission to do this though -- there is no process document for replacing the whole process. Should I succeed though I will create a de-facto standard which, once established, should be a natural candidate for actual standardization.