Why I Migrated From JavaScript to TypeScript Again | by Nicholas Obert | Mar, 2022

The benefits of TypeScript and when you should migrate to it

Photo by Chris Briggs on Unsplash

JavaScript runs the web, people say. However, it’s also true that 39% of JavaScript developers hate it, according to the 2021 Stack Overflow survey and only 61% of them really want to work with it.

In 2012, while JavaScript was still king of web development, Microsoft released their new programming language, TypeScript. It was designed to make up for JavaScript when it comes to large, complex systems where its more flexible cousin would get the developers upset.

The survey also shows that a significant share of JavaScript developers wants to work with, or even switch to, TypeScript. The data shows that the latter is currently the third most loved programming language and 75% of its developers want to use it in 2022.

A while back, I started working on a relational database management system (RDBMS) I wanted to implement from scratch. Even though I never was a fan of JavaScript, I still decided to write the system in it with Node.js because I wanted to learn more about this technology.

Initially, I was kind of satisfied with JavaScript’s dynamic typing system and extremely flexible structure. I could write code much faster than I would have in a language such as Java or C++, which would have been my first choice for such a project.

However, as the codebase was becoming always larger and increasingly complex, I started having frequent typing issues. I’m sure most of you know the frustration of receiving the “Cannot read properties of undefined/null” error message, but you have no clue where it might have originated.

Null TypeError in JavaScript.

Another struggle with JavaScript was working with objects. I always had to go back to where I created such objects, as there was no way of defining a strict template all instances must adhere to. To make it even worse, the IDE couldn’t help with catching typos and, most importantly, it couldn’t give any hint about what methods and properties an object had. After all, the any type doesn’t provide much information for both you and the IDE to work with.

While JavaScript does the job just fine in codebases that extend for just a couple hundred lines of code across a few files, you will definitely get lost in thousands of lines spread across tens of deeply nested files and folders, not to mention the struggle of getting back to work after a while, when you will probably have forgotten how the object stored in the sqlToken variable that came seemingly out of nowhere looks like.

In addition to that, other developers that look at your code might go insane trying to figure out what a certain structure is comprised of or how it should really be used, not to mention the struggle of debugging edge cases-related issues.

Although it may seem scary to migrate your codebase to another technology, especially when you are not familiar with it, and most people tend to stay away from it, it is sometimes necessary. In my case, I had to switch to TypeScript two times.

The first project I had to migrate was the database management system, which was an absolute pain to rewrite. First of all, I had to learn the language and how to set up the development environment. Then I went through the whole codebase and found dozens of dumb typing errors and bad practices I didn’t even think about. In fact, when you are not required to invest much mental effort into consciously designing the data structures you will be working with, you tend to pay less attention when writing code.

The second project I had to migrate was a React frontend of a booking system. Fortunately, frontend code doesn’t usually consist of much logic, so it was relatively easy to rewrite in TypeScript. However, it is crucial for an application to handle correctly data exchanges between the backend and frontend. In particular, the most tricky part is agreeing on a common structure, usually JSON, to represent the data inside requests.

When defining such a structure, it’s a good idea to be as strict and precise as possible with types, defining what is allowed and what is not to avoid potentially dangerous edge cases. This is where statically typed languages ​​such as TypeScript come in handy, as they don’t allow you to perform operations — at least directly — that could result in type errors.

TypeScript catching a dumb bug.

Now, to change the codebase language from JavaScript to TypeScript, you have to go through a two-step process. First of all, you need to set up the development environment. This includes installing the needed dependencies and creating a tsconfig.json to define the compiler settings.

In the root directory, run the following commands to add TypeScript to the project. Note that you have must have npm installed on your system.

npm install typescript — save-dev
npx tsc --init

Now you have to edit the newly created tsconfig.json file according to your needs. To keep the article more concise, I won’t focus on how to do it, but you can follow this simple guide. Anyway, below is an example of tsconfig.json for a Node.js project:

tsconfig.json for a Node.js project.

The second step is to adjust your JavaScript code by adding static types and fixing eventual obvious bugs that will come to light. However, to accomplish this you have to know some TypeScript in the first place. Fortunately, it’s not hard to get started with and there are countless good online tutorials about it.

Below is shown an example of a Redux store slice first in JavaScript, then in TypeScript:

JavaScript code for Redux storage slice.
TypeScript code for Redux store slice.

Congratulations! You have just made your codebase much more robust and reliable with little effort.

Even though I personally don’t like JavaScript, I must admit it has its place in the software development world. In fact, its flexible syntax is perfect for quickly and simply handling web requests and all kinds of events. Moreover, thanks to its high abstraction level, it’s a great tool to get started with and allows you to easily your ideas in code.

Despite that, though, JavaScript is not always the best answer. While it still holds its throne in the development of frontend layers, unfortunately, it lacks the reliability and robustness required for complex logic and large-scale systems for all the reasons I’ve mentioned before.

In essence, if you don’t foresee your codebase growing beyond a few hundred lines of code, might be better off sticking with JavaScript, as TypeScript may be somewhat overkilling. On the other hand, if you plan on implementing numerous features or handling large amounts of data, then you should start directly with TypeScript.

If you are unsure instead, you can start building with JavaScript and eventually adapt your codebase to the situation. At least in my experience, your code will become too hard to manage before it’s too large and entangled to migrate to a more well-structured tech stack.

TypeScript vs JavaScript use case diagram.

To wrap it up, JavaScript is good enough for simple and small systems such as an application frontend or a minimal API backend. However, when it comes to more complex software such as a booking system backend or a database management system, you had better use a better-structured programming language such as TypeScript or any other language that features static types.

As much as it would be nice, JavaScript is not the solution to every problem. This is the reason why many different programming languages ​​and technologies exist in the first place: they were designed to accomplish a specific task. And, even though you can indeed use just one tech stack for every system you build, it doesn’t mean that you should. After all, you don’t use a hammer to bump in a screw: a screwdriver does the job much better.

There is no one-size-fits-all approach in life. It all boils down to using the right tool for the right job.

I hope you enjoyed this article. If you have anything to add or any question, please share your thoughts in a comment.

Thanks for reading!

Leave a Comment