You make some good points here, I've also experienced the same with Haskell web frameworks. I think we can agree that the most important things to annotate are

You make some good points here, I've also experienced the same with Haskell web frameworks. I think we can agree that the most important things to annotate are points of interaction. If I'm part of a 5 developer team working on a code base, or I'm using a library someone made - I want the functions I'm calling to be very explicit about what they take and return and I want the functions I provide others to be very clear on what they take and return. The problem is that even something people use every day like a Promise or an event handler creates very complex types (like the example above). I think any viable solution that expects to be type safe needs to be able to express that. If your code does not expose any callbacks, or anything async I'd say it's simply not very typical JS code. The alternative of course is to be _less_ safe about our type. We could say that we treat a promise as: Promise<A> -> A -> Promise<B> -> Promise<B> (just a `bind` from Haskell) - this would let us maintain _some_ type safety which is better than nothing.