I have recently started working with a repository that is written in JavaScript. This is after working with only TypeScript. It has only been one week but I already miss the familiar assistance afforded by TypeScript.
I find myself asking myself, should I convert the JavaScript to TypeScript or continue. That’s why I am writing this article. To complete the research required to answer the questions I have: Why use TypeScript and how best to convert an existing JavaScript project to TypeScript?
Airbnb estimated that 38% of bugs could be eliminated by using TypeScript
TypeScript isn’t only a spell checker but it reminds me of a spell checker in Microsoft Word or Google Docs. It catches basic errors in your IDE and assists in writing code. More recently this is a feature that AI has brought, completing your sentences. However, I feel TypeScript is making more educated inferences versus educated guesses.
TypeScript provides quick fixes through its language service. I miss being able to add missing imports quickly. If I’m working with an NPM package such as Mongoose, I can start writing mongoose in my code and TypeScript will suggest the import. This allows me to add it quickly, it will calculate the file path.
TypeScript will also organize my imports and can update them when I move or rename files. It will also highlight type errors.
This doesn’t feel like a huge advantage, except it allows me to focus on other things and write code more efficiently. It allows me to think about more important aspects of the code I’m writing.
There’s also a list of other errors that with JavaScript are only discovered at run time. Then you have to trace them and resolve them. With TypeScript the errors are flagged in your IDE while writing the code.
Just to confirm before I share the examples, think of a type as a primitive value: string, number, boolean, object.
Examples include:
These are all easy errors to make when writing code and with TypeScript it’s very easy to resolve them in the IDE before you run your code. In my limited experience this results in fewer bugs and a reduced amount of time spent chasing runtime errors.
In my professional experience, fuzzy, heterogenous sources of data and broken chains of data flow cause the most issues in a TypeScript conversion, however I argue that it is not TS being at fault here; it is the toxic flexibility of JavaScript that delays dealing with the consequences of coding mistakes to runtime.
I sometimes call it “HDD”: hope driven development.
You hope that the data would look like how you’d expect it to look like. You hope that the unit tests are describing the data accurately and you won’t have false positives. You hope it will blow up before it blows up at the user.
While it is exhausting to deal with these errors, it is way cheaper to address these during compile time than waiting until accidents happen to the customers. And for the entire company!
With a solid TS codebase you will unlock your true velocity because then you can rely on your data and the tooling around it.
https://dev.to/latobibor/7-years-of-experience-converting-javascript-to-typescript-my-caring-opinions-36ci