Future of TypeScript on ESLint
I&#x27;m disappointed by the growing popularity of TypeScript.<p>My very first programming language was ActionScript 2 (which was also based on the ECMAScript standard without types; just like JavaScript) and I clearly remember that I was really enjoying ActionScript 3 when it came out in 2006 (that&#x27;s when ActionScript became a statically typed language; very similar to TypeScript).<p>Then a few years later, I got back to JavaScript&#x2F;Node.js (dynamically typed) and I noticed that I could create libraries and applications a LOT faster without types and that writing libraries was also a lot more enjoyable.<p>My view now is that statically typed languages are like training wheels on a bike. Statically typed languages force you to think about software in a structured way and in doing so, they teach you some fundamental concepts about abstraction. That said, if you&#x27;re experienced enough to know how to structure and test your code correctly, then, much like training wheels on a bike; they only slow you down.<p>I&#x27;ve been using TypeScript for the past couple of years at work so I can confidently say that it creates more obstacles than it solves for me.<p>Pros:<p>- Easier to keep track of all the places in the code which are affected by a refactoring (especially if the code is messy, poorly tested and components have poor separation of concerns; it gives useful warnings).<p>- Easier to find class and method definitions in the code.<p>- Easier to rename classes, functions and properties.<p>- Much less likely to leave forgotten unused variables or functions in your code.<p>Cons:<p>- Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests.<p>- Sporadic source mapping issues&#x2F;bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I&#x27;ve worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind.<p>- Type definitions from DefinitelyTyped are often out of date or have missing properties&#x2F;methods. It means that I can&#x27;t use the latest version of a library.<p>- Third party libraries are difficult to integrate into my project&#x27;s code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements).<p>- Doesn&#x27;t guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The &#x27;unknown&#x27; type helps but it&#x27;s not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript.<p>- Whenever I write any class&#x2F;method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library&#x2F;module instead of assuming that the user is an intelligent person who knows what they&#x27;re doing.<p>- Compiler warnings make it hard to test code quickly using console.log(...); I&#x27;m more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.<p>- The &#x27;rename symbol&#x27; feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up.<p>- It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It&#x27;s not always clear whether similar concepts should be different types or merged into one. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic only.<p>- Setting up TypeScript is a pain.<p>- Adds a lot of dependencies and complexity.<p>- Makes the bundling step a necessity. This goes against innovations like HTTP 2 which could potentially remove the necessity of the bundling step by allowing us to preemptively push scripts to the client.