Here's my strongest argument in favor of type safety: if you're building a project that is intended to have a long life and be seen by many people, type safety <i>may</i> be a hassle for you but it'll be a blessing for the hundreds of people who will have to eventually figure out your code.
Note that it's possible to use both TSLint and ESLint in the same project, and that's what I've been doing for nontrivial projects. ESLint has a big community and a lot of nice rules, but there are a few things that ESLint can't (yet) do and that aren't implemented by TS itself:<p>* The TSLint no-unbound-method rule is really helpful for avoiding the React bug of passing `this.handleClick` at render time without it being a bound method. This is one of the "needs type info" rules that uses the type analysis from the TS compiler, and generally these sorts of rules are much more powerful than what you can normally get in ESLint.<p>* The TSLint ordered-imports rule with autofixing is a much nicer way to force import ordering than anything I've seen in ESLint. (ESLint sort-imports won't reorder your imports, for example.)<p>But as mentioned, the TS team has said that they want ESLint to be the future for TypeScript linting, so hopefully ESLint will get all of that soon enough.
My biggest grape with staticly typed languages like TypeScript is that many developers considers type safety a replacement for test - it is not. It is completely at best.
Static typing doesn’t reduce bug density, this is no news, just a risk compensation principle at work.<p>But there’s another factor: static typing creates a nice puzzle for you to solve instead of solving the actual problem. You solve the puzzle and feel nice, you show the solution to management later and they feel nice to because it’s all neat and hierarchical. Then you write majority of the code that doesn’t neatly fit the puzzle’s constrains, then new feature requests/requirements come in and after a time the puzzle needs to be solved again. And so the wheel turns.<p>What people usually mean when they talk about static typing is a language to specify promises and requirements. To my knowledge that language has not yet been successfully reduced to mostly static and rigid annotations that are useful in dealing with changes to the software itself.
This thread is going to quickly devolve into the pro-type safety vs. the pro-flexibility camps. Look, if you looooove declaring types and somehow thinks this reduces bugs, great. If you just want to focus on the logic of your app and don't feel like managing the minutia of how the computer stores a number or string, great.<p>But if you want to declare one is fundamentally or empirically better, then you need to get a grip. We can all like different things, it's allowed.<p>The one core thing I'd like to stress, however, is that TS is not JS. If you use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe uncle and niece, but they are not the same.
The title alone makes a good reason to further ignore typescript. If i should name a single major product that has the most horrible UI/UX it would be PayPal.
>> What took took me so long?<p>It took a while for all of Microsoft's marketing to kick in and for the mindless hypewagon to reach full speed.<p>I have decades of experience with Typed ECMAScript (first with ActionScript 3 from 2006 and then TypeScript). It's not worth it. Productivity will drop enormously and bug density will not change at all.