4 ms·

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

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.

ayaros 1y ago
Yes, this is what I want too. Give me "stricter" mode.
fngjdflmdflg 1y ago
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.
- teaearlgraycold 1y ago
  The most likely path forward on that would be a Typescript AOT compiler, maybe with some limitations on the code you write.
  - fngjdflmdflg 1y ago
    Compiled to what, wasm?
    - teaearlgraycold 1y ago
      I wasn't thinking about browser runtimes. But maybe one day browsers will have native TS support?
      - fngjdflmdflg 1y ago
        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.
      - Cthulhu_ 1y ago
        > 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.
        teaearlgraycold 1y ago
        Well we'd need browsers to natively support type stripping.
  - samwillis 1y ago
    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/ https://porffor.dev/
- rictic 1y ago
  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.
  - fngjdflmdflg 1y ago
    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?
    - rictic 1y ago
      > 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.
ihuman 1y ago
Like asm.js was, before webassembly replaced it?
- Timwi 1y ago
  No, the purposes of asm.js versus 'use strict' are completely different and in conflict with one another.
Cthulhu_ 1y ago
> 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.
- Timwi 1y ago
  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.

ayaros 1y ago

Yes, this is what I want too. Give me "stricter" mode.

fngjdflmdflg 1y ago

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.

teaearlgraycold 1y ago
The most likely path forward on that would be a Typescript AOT compiler, maybe with some limitations on the code you write.
- fngjdflmdflg 1y ago
  Compiled to what, wasm?
  - teaearlgraycold 1y ago
    I wasn't thinking about browser runtimes. But maybe one day browsers will have native TS support?
    - fngjdflmdflg 1y ago
      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.
    - Cthulhu_ 1y ago
      > 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.
      - teaearlgraycold 1y ago
        Well we'd need browsers to natively support type stripping.
- samwillis 1y ago
  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/ https://porffor.dev/
rictic 1y ago
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.
- fngjdflmdflg 1y ago
  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?
  - rictic 1y ago
    > 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.

ihuman 1y ago

Like asm.js was, before webassembly replaced it?

Timwi 1y ago
No, the purposes of asm.js versus 'use strict' are completely different and in conflict with one another.

Cthulhu_ 1y ago

> 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.

Timwi 1y ago
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.