I'd argue that if you ever use a single "any" then you're not using Typescript but simply writing JavaScript with more steps and a compile time. Any can be usef

I'd argue that if you ever use a single "any" then you're not using Typescript but simply writing JavaScript with more steps and a compile time. Any can be useful during development, but it should never reach production. I think the reason you see so much of it in a lot of open source packages is that they've only really adopted Typescript because their consumers expect it and it was just easier for them to do it this way. We use very strict Typescript, but a lot of our internal utility packages are actually written in pure JavaScript because of the way the Node package environment works. Like our date tool, our helper API package for odata, and, our fascist linting extension package. They're all pure JS with provided types. This is because the handful of people, and the handful of times we work on these libraries it's always people who know exactly what they are doing while they do it. These same people (myself included) won't necessary be in similar positions when we write Typescript, which is why we don't use JavaScript in our day-to-day development. Since our strict Typescript setup protects us from ourselves. I'm not personally a big fan of Microsoft. Professionally I do think they are one of the absolute best IT-business partners for organisations either enterprise-sized or approaching, because of how they run their support for operations. That being said, I do think what they've done with both Typescript and C# where they sort of mix the best from both languages, has been really good for both languages. At least until you look at something like Blazor which is basically just rebranded web-forms. But I guess that's what happens with large organisations, and at least as far as Typescript is concerned, they seem to be making the "right" decisions.