> TypeScript usage is a tiny minority of JavaScript usage

shudders at the thought

After using TypeScript for almost 5 years now, I can not imagine a scenario where I would write JavaScript without type safety - other than a 5 minute POC to test something out.

I look forward to the day when TypeScript can be compiled to wasm binaries and it can be a language all on it's own rather than a superset/wrapper of JavaScript.

I like TypeScript but I think there's a complexity threshold — if you have a massive collection of other people's code, types are essential. If you're building a basic web app which is using the built-in behaviour and have a reasonably modern editor + linter + test setup, type safety is still good but it buys you less than it does when your baseline complexity level is higher.

Since modern browsers and JavaScript give you a lot of functionality out of the box which people used to use libraries for, there are quite a few projects which are under that threshold.

For smaller projects, I find that the value is less the type safety (still valuable) and more the much stronger control of intellisense. Yeah, if you have a language server that's able to deal with typings your JS code will still be a lot better than without it, but starting with TypeScript just makes that way more fluid. I find that I write TypeScript much more quickly, and more correctly, than I do JavaScript, both for small and large projects.

I agree that TS is a good pragmatic choice for any non trivial amount of code but I am still surprised how bad it is.

Error messages in TypeScript are quite cryptic for a modern language. Compiling it is super slow. Type safety, well they are doing their best considering the very dynamic nature of JavaScript but now if we compare it to other languages that compile to JS like Elm, it is just not that huge of a step.

With Elm you get a guarantee of no runtime exceptions at all in productions plus the most helpful compiler ever written. Even compilation time feels much faster. Similiar for competitors like ReScript, Purescript and the like.

Of course TypeScript is the easiest to learn for established JS Developers. And I am quite grateful that the option exists but I just wish it would be better considering how much money is put into it.

Typescript is completely different from Elm.

Elm is an entirely different language. Typescript is little more than a typing layer on top of JavaScript.

As such, your typescript should look almost exactly like your JS would, with the only difference being that all your variables are now typed.

That's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.

It can’t have it built-in without breaking backwards compatibility. NullAway adds this feature by enforcing sane use of @Nullable annotations.

> If anything it slows development down, not makes it faster

It doesn't really "slow development down", it just forces you to explicitly specify the data structures that exist whether you decide to acknowledge them or not. Eschewing types is just a form of technical debt that every developer has to repay as they deduce the application data structures through trial and error, often times in production.

My guess is that people who feel that types "slow development down" just haven't become sufficiently familiar with the type system.

In languages I am familiar with, types are just muscle memory. If anything, development is faster because of code completion.

In languages I am learning, yes there tends to be some fumbling with the type system. But that fades with experience.

Indeed, and Type-Driven Development is also a thing.

Given a great type system and editor/IDE types can even be used to derive implementations.