Yeah, it is quite impressive!
It's a real example of "you can solve just about anything with a billion dollars" though :)
I'd prefer JavaScript kept evolving (think "strict", but "stricter", "stricter still", ...) to a simpler and easier to compile/JIT language.
I want JS with sound types. It's interesting how sound types can't be added to JS because runtime checks would be too expensive, but then so much of what makes JS slow is having to check types all the time anyway, and the only way to speed it up is to retroactively infer the types. I want types plus a "use typechecked" that tells the VM I already did some agreed upon level of compile-time checks and now it only needs to do true runtime checks that can't be done at compile time.
Tricky thing there is that the VM would still need to do checks at all the boundary points, including all of the language-level and runtime-level APIs. At what point along such a migration would it become net faster?
It'd need a ton of buy-in from the whole community and all VM implementors to have a chance at pencilling out in any reasonable time span. Not saying I'm against it, just noting.
Agreed, but I do think all major libraries would be rewritten in any soundly typed version of JS pretty quickly, especially if it was faster (assuming that is the case).
>runtime-level APIs
like the Document APIs?
> like the Document APIs?
Yeah, the DOM in the browser, node APIs in nodejs, etc.
> especially if it was faster
Well, that's the thing. Initially it'll be slower, 'cause the code you call, and that calls you will be mostly unsound.
Unless you can run the sound code without the soundness checks at boundaries, at which point it becomes harder to reason about, and you'll be tempted to add some additional runtime checks to your code that the type system should catch.
The most likely path forward on that would be a Typescript AOT compiler, maybe with some limitations on the code you write.
Porffor is doing that, JS -> WASM (an an IR) -> C -> Native
For TypeScript it uses the types as hints to the compiler, for example it has int types that alias number.
Very early still, but very cool.
https://porffor.dev/
Compiled to what, wasm?
I wasn't thinking about browser runtimes. But maybe one day browsers will have native TS support?
> But maybe one day browsers will have native TS support?
This may already be a thing; node has native TS support by just ignoring or stripping types from the code, TS feature that can't be easily stripped (iirc namespaces, enums) are deprecated and discouraged nowadays.
TS is not actually that special in terms of running it. TS types are for type checking which isn't done at runtime, running TS is just running the JS parts of the code as-is.
Well we'd need browsers to natively support type stripping.
For non-browser runtimes, react native is actually working on an AOT TS/Flow engine. But they ship a bytecode binary rather than what I'm proposing, although what I'm proposing might also be infeasible.
> I'd prefer JavaScript kept evolving (think "strict", but "stricter", "stricter still", ...) to a simpler and easier to compile/JIT language.
This is / was ASM.js, a limited subset of JS without all the dynamic behaviour which allowed the interpreter to skip a lot of checks and assumptions. This was deprecated in favor of WASM - basically communicating that if you need the strictness or performance, use a different language.
As for JS strictness, eslint / biome with all the rules engaged will also make it strict.
ASM.js and 'use strict' have completely different purposes. One is a performance thing and is (or was supposed to be) used as a compiler target. The other is all about making the programmer’s life easier by disabling features that conflict with principles of maintainability.
Yes, this is what I want too. Give me "stricter" mode.
Like asm.js was, before webassembly replaced it?
No, the purposes of asm.js versus 'use strict' are completely different and in conflict with one another.