JS could be an amazing language to work with if they'd just spec out a "use type" subset that uses an actually-sound Hindley-Milner type system on typed parts (verify types at the untyped fringes and throw if they don't match) while disallowing all the bad parts like type coercion or any of the many other footguns in the language.

TypeScript??

Typescript doesn't do ANY of that. It is intentionally unsound. Rather than prevent the crazy from happening, TS gives loads of ways to abuse the worst parts of the language as it slowly expands to be one of the most complex type systems ever created.

Finally, a "use type" with guaranteed type boundaries could offer loads of runtime optimizations and speedups that TS cannot offer (and has no intention of offering).

What would happen at a call boundary from untyped -> typed and typed -> untyped?

JS JITs like v8 is already do this to some extent.

Objects aren't actually "untyped". Every object has a hidden class with a definite type or "shape" (a shape basically means the same keys with the same value types in the same order). The inline cache (IC) stores which shapes have been used (and how often they've been used) for a specific function. The shape is checked every time the function is run with a series of assertions.

If your function only ever sees one shape, it is monomorphic and will get a lot of great optimizations not only on itself, but maybe on it's parent function as monomorphic functions can be inlined (one of the most important optimizations) with some asserts to make sure things went as expected.

If a function is called with 2-4 types in the IC, it is polymorphic in v8 which slows down the IC lookup and disables some optimizations. More than 4 types is called Megamorphic in v8 and is the slowest possible option.

Here's a whirlwind overview of how this works https://www.youtube.com/watch?v=xckH5s3UuX4

Types offer a streamlined version of all this.

Untyped -> typed simply does what already happens, but the assertions throw if they fail.

Types have other advantages within a function. There's a tradeoff in optimization where you don't want to optimize too early because you might have gotten it wrong and wasted a bunch of time and energy. Types make guarantees that your optimizations are correct which means you can optimize more earlier and there may even be optimizations that would simply be impossible otherwise.

A strong type system would disallow some of the stupidly-dynamic JS stuff which prevents optimization. This is an indirect massive benefit of a good type system (one that TS misses out on as it makes it easy to make types for very slow code patterns).

Typed -> typed is another important consideration. Instead of waiting hundreds of runs for your simple `.map(x => x.foo)` to inline, strong type guarantees mean you can inline it from the very beginning and all those useless assertion conditional branch instructions simply aren't needed. Polymorphism slows down current operations as it waits to dispatch, but because the types show what polymorphism exists and exactly which variant each call site uses, you can always match the exact call site to the correct monomorphic variant which also speeds things up.

Typed -> untyped is super-easy. The compiler knows the shape of the typed objects. It could probably add a greater weight to typed IC entries executing so they produce optimized versions sooner because the types add stronger consistency guarantees.

Would hope your server time zone changes quite rarely and only when you know about it, though.