[AgentME]

I'm on a large codebase that transitioned from Javascript to Flow a few years ago (which is very similar to TypeScript, though nowadays I'd recommend TypeScript over it). Before we started using Flow, big refactors were extremely painful. It was practically guaranteed that we'd have to spend a week manually double-checking things, and then spend at least a few days finding and fixing bugs after deploying the refactor to users. Therefore we avoided refactoring at all costs. With Flow, we suddenly can refactor something, find the loose ends with Flow immediately, be sure about it, and be done with it. The difference between now and then is night and day. We can get things done so much faster now. The article author's experience is completely alien to me.

[ng12]

Agreed. My watershed moment was trying to refactor a custom charting library we had written in CoffeeScript. I was on the fence about TypeScript before then but that experience completely changed my view. All the nice little features of CoffeeScript paled in comparison to the utter misery of doing that refactoring.

[ericelliott]

I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

[ng12]

With TypeScript I can make a change and immediately get a list of every single line I need to update. None of those replace that very key functionality.

> and you can't leave those out safely

Who's advocating for the replacement of code review, specs, and tests with TypeScript? TypeScript makes these things better, it doesn't replace them.

[z3t4]

You can make the life of others more easy by always naming the same thing the same, eg always naming foo.bar foo.bar and you wouldn't need to annotate them, and everyone will know what it is. But if changing something means you also need to modify code at a lot of other places you have a architecture/pattern issue. Such a change should always be a semver major.