I do agree that they shouldn't cater to TypeScript or Flow or anything specifically, but I appreciate that they think about the impact of new changes on typing JavaScript. I find in general that code that can easily be statically typed is easier to understand and maintain.

Exactly this! And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! If you had a clear data flow/model the types will usually end up being much simpler too.

This is somewhat less true in some frontend projects, where the underlying libraries/frameworks come with infectious built-in interface complexity (side-eyes React/JSX even though I quite like JSX otherwise).

> And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated!

Part of it may also be due to the limitations of TypeScript. Structural typing is not always the best choice. ADT support is also not the best.

I definitely have wants for the TS type system, particularly in the area of nominal typing. But it’s usually not this IME. It’s usually that untyped JS often is written in an overly permissive style where anything goes, or where state and data flow is a big ball of mud, or both.

That's false equivalence. Typescript is trying to bolt on strict, formal types to a prototypical language. Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed. You'd need to have a lot of evidence that that were the case, as it's a bold claim about not just JavaScript, but programming language design in general - one that isn't entirely factual, IMO.

Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts.

Perhaps a contrived example - my point mostly being that you can't draw conclusions like that.

> Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed.

Oh, I wasn’t saying the language is poorly designed. I was saying the particular JavaScript code where people complain about the TypeScript types is usually poorly designed. It’s not the types’ fault the interface is so convoluted the types describing it are also convoluted.

Like people write variadic functions that take arguments, or an options map, or a boolean, or a magic string or enum… and then say “there’s 100 lines of types describing this functiona! That’s such a pain!” And like, yeah, it is a pain understanding what your function does.

> Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

Amusingly, you’d end up with a type system a lot like TS. Particularly template literal and mapped types.

> However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts.

I think this is the only point of disagreement for me here. I find shell scripting absolutely painful, and try to do as little of it as possible.

> Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself.

Everything is a string because every program deserializes and then serializes data from and into a string. But you still have expectation encoded into the tools. If not, they wouldn't be able to work together. Static typing is about making these expectations explicit.

They aren’t catering specifically to TypeScript (or Flow), but rather to increased interest in type safety across the community generally.

It’s worth noting though that the TypeScript team does participate in the standards process. And Microsoft has two members on the committee.