>Your tests would catch breaking changes as well. Absolutely. But it only tells me where the code failed, not necessarily where my structural assumptions first

>Your tests would catch breaking changes as well. Absolutely. But it only tells me where the code failed, not necessarily where my structural assumptions first fell apart. So I then have to walk up the stack looking for that point. It's pretty mechanical to do but typescript does it for me. This also assumes you have solid test coverage which unfortunately isn't always true. Especially for code that is being refactored because it's becoming (or already is) unsustainable. >In many typescript codebases (angular4) strict null checks is disabled befits are really minuscule. I agree that --strictNullChecks is very useful if the codebase often assigns meaning to null/undefined but that's more of an overall design problem. I feel there's a lot of benefit outside of that but I'm generally all for explicitness in code so I might be biased. >I am now doing an angular4 project and I do not feel any safer. If it's greenfield development, you probably won't for now. The implicit type system is fresh in your mind and having to explicitly put it into code is just going to feel like it's slowing you down. I suspect the benefits will come later when someone who isn't intimately familiar is looking at it (could be a new team member, could be you after another project or a vacation). >If you want to have real static typing use Elm, Reason, BuckleScript. For sure. But the downside with these is the commitment required. Typescript is as low effort/commitment as you need it to be. And an experienced js dev can pick up the basics in an hour. >Tooling is already bad on anything other than VS Code. I've only really used it in webstorm (which also uses the typescript language service) and it's never been an issue.