Unions, generics, required fields, default values, enums that don't pollute the global namespace are things that immediately caught my eye. I assume it also doesn't repeat Protobuf's the mistake of not being able to distinguish between a missing string value and an empty string value.
Protobuf is old, and has some really strange warts that are only explainable historically (for example, by reference to the behavior of C++, which used to be Protobuf's primary target).
I have long used protobuf as the source of truth for API's, but it does have some weird idiosyncrasies since its primarily a binary spec, and doesn't always transfer to json well (e.g optionals, maps, etc).
As someone who works on TypeSpec, my feeling is that they are mostly different things. TypeSpec is a general purpose DSL which supports "emitting" to protobuf and other things, but in and of itself doesn't prescribe any particular protocol or serialization format.
Gotcha. I think this might be where Protobuf falls short because you have to "source" the tooling for all its different outputs, but support for OpenAPI 3.0 spec generation has existed for over a year.
Superior in performance and easy-of-use, which for most people is all that matters. Atom still won in general "hackability", which was one of its main selling points. Unfortunately that didn't stick, and the kind of people that want a hackable-to-the-core editor are probably using Emacs. I know I am.
TypeScript wasn't better than Flow when it gained dominance. It happened because Microsoft created an out-of-the-box experience with VS Code that worked great with TypeScript but made Flow types look broken.
More generally Microsoft treated Typescript as a product - they built it based on feedback from outside users and worked hard to make it easily adoptable and to grow a community around it. They are also "pragmatic" - willing to have weird, unsound semantics if it's needed to help people adopt Typescript and model existing JS ecosystem patterns.
Flow has always been an inwardly-focused project that is for Facebook's needs first. The Flow team at FB made an explicit decision to focus more on compiler performance improvements (what Facebook's usage needed) over outside users & community.
The way I remember, when flow was introduced, you had to do small changes to 3rd party dependencies your code might have had to make them flow-compatible.
With typescript you could just write a type definition file for any 3rd party library, so you could essentially make any 3rd party dependency "typescript compatible" without needing to change its code.
This small difference made a huge impact for adoption. Eventually flow also got that feature but by then the adoption difference was already too big.
From what I remember TypeScript was a superset of Javascript, so you could just rename your files and enable TypeScript and it all worked, and then gradually move stuff over. That probably helped a lot.
It was released. It was on a growing number of webpages and an important part of the Dev Tools of IE9+ (also giving them a massive install base from before Atom existed). If Atom didn't build Electron what became the VS Code team might have built something similar on their own eventually (though it probably would have been IE-based and Windows-only in that alternate history). It truly seemed convergent evolution at work.
Protobuf is old, and has some really strange warts that are only explainable historically (for example, by reference to the behavior of C++, which used to be Protobuf's primary target).