Is TypeScript the silver bullet for JavaScript?
Nathan Guenther
Chief Smart Ass (Technical Co-founder) | Full Stack Engineer | React Expert @ Donkey Chats
I was introduced to TypeScript back a year ago when our (then) team decided to transition from Angular 1.5 to Angular 4. It was a big hurdle--and quickly discovered that Angular 2/4 was tightly coupled to TypeScript. It was a coupling that I grew to appreciate because of how much community support was around the technology and its language, but I struggled because I wanted TypeScript to solve every gripe I had with JavaScript--namely that JavaScript shouldn't have compiled in the first place if there was something wrong with the code--it should've been smart enough (so I thought) to know ahead of time if I was going to cause a bug.
TypeScript was supposed to solve every problem with JavaScript right? It was supposed solve code failures by variables being undefined, and nested variable properties being reassigned without your knowledge (even if the variable was declared using `const`). In React-land it was supposed to solve for issues where parent components could blindly propagate its `props` down to its children through 10 generations of components! But I was mistaken.
TypeScript doesn't actually solve any of these issues because it sits on top of JavaScript as a transpiled language--which means that in reality, TypeScript is really just JavaScript and carries all of the same problems inherit to JavaScript with it. However, here's where that argument falls apart:
TypeScript, like Babel, Redux, Flow, or JSDocs, are tools. If the code or logic is bad, is the fault of the tool or the engineer producing the code?
To demonstrate this, I brought up some issues I was seeing in a repo to fellow engineer. I explained the problem--that there were instances where it next-to-impossible to know how the `props` were flowing down from parent to child in a highly nested component structure in React. I suggested that it might be time to transition from ES6 JavaScript to TypeScript within this repo to ensure contract integrity. He argued that it's the job of Prop Types to do that. I argued that Prop Types are useful only as a logging tool and that the engineer can ignore Prop Types. He suggested that engineers can have less strict contracts in TypeScript (essentially yielding the contract useless). He wasn't wrong.
After reflecting on this discussion, I came to the understanding that the faults I had with TypeScript were not faults with the technology, but that I was imagining it as a silver bullet to solve all JavaScript woes.
TypeScript is a tool to assist devs who want to improve their code base with stricter typing rules. That's all it is.
Do I think it works well as a tool? Absolutely! I love working with TypeScript, but I'm realizing it's not for everyone--just those who want contractual integrity between functions, and interface integrity within objects (I'll save those two for another blog post). But then again, it's only as good and useful as the dev using.
Continuously integrating & deploying containers
6 年What use would typescript have if it didn’t compile to JavaScript? Typescript is JavaScript. The silver bullet is an illusion. JavaScript won’t be making its way into the afterlife anytime soon.
Artist, Mentor, and RETIRED Senior Software Engineer
6 å¹´the point about silver bullets is they are imaginary
Leader (Engineering - Design - Business)
6 å¹´I hope it gets more traction. I think it would open the possibilities. But I don't think it's the silver bullet. It seems like WebAssembly is going to change the rules of the game here shortly .
React / Reason / OCaml developer
6 å¹´Yes