I don't really agree with this take. The point is that TypeScript allows you to type standard JavaScript idioms. The whole "type equals string" thing is a standard JavaScript idiom. Are discriminated unions better? Yes. But we are where we are and JavaScript is complicated.

There are lots of better languages that compile to JS and don’t let you make mistakes in the same way the two grand parents do. Just saying JS is complicated to make typed is completely true and not a good reason to use TS; it doesn’t excuse the fact that I spend all this time doing a Typescript dance and still wonder if my Types have weird flaws.

I would encourage people to consider Reason or Dart or Elm or even plain old ES6 before they decide Typescript solves their problem.

If anyone gives these other compile-to-js languages a look, I would add ClojureScript to that list, especially if doing React work. The re-frame framework is great, and the cljs ecosystem is a joy imo. You won't get the kind of type system these other langs provide, but there's some interesting stuff going on with spec.

Agree strongly ClojureScript - shame it has a terrible name which probably means it won't gain the popularity it deserves. I've also heard good things about PureScript.

I haven't been able to put my finger on why cljs isn't more popular, especially given all of the great stuff David Nolen did in the early days of React and the ease of use of figwheel and some other cool things in the ecosystem.

I always just assumed it was too big a syntactical hurdle for lots of teams. I.e., I suspect a lot of individuals appreciate it, but it's hard to choose cljs from the business side of things because it looks so foreign to many. That's a shame!

Haven't looked into PureScript yet. I'll add it to the list!

How can you recommend Dart when it has globally nullable types?

I like Dart in the context of Flutter, Typescript has “any” which is even worse!

In ES6, every variable is "any" and implicitly nullable.

Typescript requires any for ES6 compatibility, but if your code is converted enough ("enough" occurring pretty early in conversion projects in my experience) you can set the compiler flag to forbid non-explicit usage of any.

I agree with you but we were talking about Dart vs Typescript. ES6 is fine if you’re sketching something and wanting a flexible (i.e. subject to change) view of something, if you have a clear/certain design there are far better systems than building the most complicated type system that both the OP and the GP can’t tell are truly type safe? Why on earth would you choose to build your type safe system in something this broken? If you don’t understand why the other systems are better that’s fine but I think try doing Golang, then Lisp, then Haskell, then maybe Elm or even Dart you’ll see that Typescript is just a lie that causes huge amounts of extra work on top of your usual work. Just my opinion but the effort/reward/beauty ratio is all wrong in TS.

I don't think you understand Dart's type system. It has “dynamic”, which is equivalent to “any”!

Dart's type system is worse because you can pass in null for any type at any time. This circumvents any sense of type safety your method signatures might suggest. It's no better than Java.

I have used Dart's type system and prefer it to Typescript because it's much simpler and better integrated into the language. I think "dynamic" is better than "any" because the type is inferred by dart which gives more type safety than Typescript does here. Obviously TS won't have a clue what to do after an "any" is passed into another Type afaik?

You are right that that checking for nulls is a bit weird but you just set default values using ?. and. ?? and get on with your life - it doesn't make the whole type system bad and there will be attempts to fix this in the future.