I was building a basic web app with HTML, CSS, and JS. The code got pretty complicated, so I decided to clean it up using some OOP patterns. While doing this, I messed up and renamed some variables like changing leftElement to elementLeft, but forgot to update all the references. JavaScript didn’t warn me that this.leftElement was now undefined. It just quietly broke and caused weird bugs.
It took me forever to find the problem.
After that, I started looking for ways to catch these errors sooner. I added "use strict" to my files, but it didn’t help with this specific issue. Even when I tried accessing obviously fake properties like this.randomStuff.data, no errors showed up. I also set up ESLint which caught some problems, but not this one, and the configuration was pretty annoying for such a simple check.
Then I got curious and changed my file extension from .js to .ts without modifying any actual code. TypeScript immediately found the error! Everything still ran like normal JavaScript but now I had proper error detection.
This got me thinking: if TypeScript catches these issues automatically, why do people still use regular JavaScript? What am I not seeing here? I’d appreciate your opinions.
Build tooling complexity is definitely a real issue. Sure, TypeScript catches errors great, but it adds another compilation step that can mess up your workflow. I’ve seen projects where the TypeScript compiler randomly fails on CI/CD because of version mismatches or config problems - suddenly you can’t deploy what should’ve been a simple fix. Some devs work in places where they need to ship fast without wrestling with type definitions for third-party libraries that are half-broken or out of date. Plus, constantly thinking about types slows you down at first, even if it helps later. And honestly? Tons of JavaScript codebases work just fine with these ‘potential’ issues, so teams stick with what already works instead of risking a migration.
sometimes you just don’t need the overhead. for quick prototypes or simple scripts, TypeScript feels like overkill - especially with legacy codebases that’d take forever to migrate. some teams prefer JavaScript’s flexibility even if it means more runtime surprises.
You nailed exactly why TypeScript exists, but there are still good reasons to stick with plain JS. Performance-critical apps sometimes skip the compilation step entirely - I’ve worked on real-time systems where every millisecond mattered and the team wanted direct control over what got generated. Plus, many seasoned JS developers have solid debugging skills and coding patterns that naturally avoid these problems. They just rely on comprehensive test suites and runtime monitoring instead of compile-time checks. There’s also the learning curve - some teams don’t have time to retrain developers on TypeScript syntax and tooling when their current JS workflow already works reliably.