as someone working on a python type checker I can second this. we get occasional complaints that some feature is too complicated or too liberal, and the answer is usually "it works this way because python works this way, we are trying to support as much valid python as we can even if it's hard to express in terms of static types".

People would benefit more from a stricter subset of JS that has decent performance characteristics and actually sound typing.

I agree, but I can't help but think of that meme about there being N+1 standards. The introduction of a stricter subset of JS will make Javascript more complicated, not less. I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.

> I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.

This is the primary argument against worrying about N+1 standards. We know it's bad, if we simply do nothing at all, we know it will get worse. We can and should at least try.

As someone who's been part of the team who tried to do exactly this, I don't think it can work. Once you start subsetting things it quickly turns towards being "better" than the existing web, and soon all backwards compatibility is gone.

All those legacy features and existing pages are the back pressure that keeps the evolution of the web stable.

"use stricter"

At this point any other language soundly typed or not is semantically a subset of JS (at most plus some of their weird thing, like Rust ownership and move semantics). You are free to pick one and let JS be JS in all its glory.

Or more precisely, TypeScript is complicated because people insist on doing deranged things with JavaScript and its mess of a type system. TypeScript wouldn't need to contain so much complexity if the underlying JavaScript was doing simple, straightforward things. Blaming TypeScript here is kinda shooting the messenger.

It doesn't try to protect you from the really deranged things. Every TS check comes with an implied "assuming you didn't use a Proxy to make this property accessor mutate state or something"

It does reach admirably far into checking the regular dynamic-language programming patterns like using string variables to index into structures. Which is where a lot of its complexity comes from, but I wouldn't call that stuff "deranged". JS is a dynamic programming language, and people write it like a dynamic programming language, and typescript decided to meet it where it was at, which is probably the only reason it's gotten so much traction in the first place

You may not like this freedom, but I absolutely adore it. I really feel restricted when I'm writing in other languages, even dynamic ones after JS and TS shown me what should be possible.

The whole “Type manipulation” section has nothing to do with this issue, but at the same time is the usual source of complexity in type definitions. Even worse, it serves as a clever challenge for people to make such dynamic interfaces well-typed, instead of making it boring, autogenerated once and then discouraged.