I've used typescript on a few projects now. What I've seen is that when first hacking on some code I use almost no types. Maybe some are inferred, and that's nice, but if not whatevs. As I'm playing with the code though, like when I'm re-reading a function or if I'm trying to debug something, I'll often add in types to see if the compiler can point anything out.

In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky.

I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).

>Does optional typing really work?

From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#.

Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything.

If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there.

Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.

If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside.

You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).

> If it spreads everywhere then that is because it is valuable everywhere.

Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty.

My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.

> ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ...

That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error.

And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.

> I'd rather have tests than types.

False dichotomy.

You want both and you need both.

> I'd rather have tests than types.

Why? Let the compiler do the testing for you.

Depends on what you mean. It doesn't spread in the same way that const correctness spreads in C++, i.e. once you add const somewhere you are forced to add it to a bunch of other places as well.

Optional typing works. Why wouldn't it?