TypeScript, Understanding the why.
Diving into why TypeScript is becoming the preferred language for large development teams.
If, in the past ten years you have worked in or adjacent to the tech industry, there is no doubt you have heard of Javascript. JavaScript, is the de facto programming language of the internet. Odds are somewhere in the sea of open tabs on your browser, a modern Javascript SPA (single page app), has found its way into your personal space. Due to JavaScripts flexibility, ease of use, and power, the language has evolved into one of the leading programming languages of the 21st Century. The paradigm of JavaScript everywhere, follows the practice of using one language on both the client and the server. Such a method allows for a single developer to jump seamlessly from the frontend to the backend, with little adjustments.
One language to rule them all,
One language to find them,
And in the darkness….. Yeah yeah we get the idea.
In a 2020 stack overflow survey, JavaScript was listed as the 10th most preferred language to either continue a project with or to expand upon further. While a relatively new language, TypeScript came at a whopping number 2!.
So why is it then that TypeScript has caught the eye and encouraged more developers to pursue its use over this powerhouse known as JavaScript. Before we can dive into the why, let’s take a step back and examine what is TypeScript.
TypeScript is a programming language designed and maintained by Microsoft. It first came to market in 2012 and is described as a strict syntactical superset of JavaScript which adds the option of static typing to the JavaScript language. TypeScript is designed for the development of large scalable applications and trans compiles down to JavaScript. TypeScript may be used both for server side (node, deno) and client side (react, angular, vue) application development.
Yikes, that was a mouthful. From a simpler point of view, TypeScript builds on top of the already strong benefits of JavaScript and adds additional features such as static typing, type checking, and more robust object oriented design patterns.
To understand what these benefits are and how they work, let’s take a look at a few examples of some simple code snippets from JavaScript and TypeScript
As you can see in the example above, when we declare a variable in JavaScript we need not tell JavaScript what type of data belongs in the variable. Right now we are declaring it with a string, but what if, somewhere, thousands of lines of code away, this variable is reused, and due to errors we as developers have all made, this variable gets reassigned to an integer type? We would have an error, one that could take one minute or even an hour to track down. When it’s crunch week, and you have a mountain of jira tickets pilling up, I promise you the last thing you want is more unexpected behavior.
With TypeScript, immediately after the variable is named we specify exactly what type of data is going to be assigned to it. If later that variable’s data type changes, we would have an immediate syntax and compile error the moment that variable became overwritten with an integer data type. Thus preventing the audit trail back to the errors origin.
Now, this is a simple example, and a far fetched one at that. It does shed light on how we as developers can be proactive in reducing development time and unexpected behaviors by taking a step back and explicitly telling our data what type it is. Type… TypeScript…. Get it?
The type checking extends way beyond the primitive data types included in JavaScript. We can create interfaces for a method or functions parameters, we can explicitly type the expected return data type of said function as well.
The features do not stop there, included in Typescript is a large set of object oriented features from abstract classes, interfaces, and private fields. Making for a more fine tuned and robust class design.
Ok, we know now what TypeScript is. What we have not done is answered the “why”. Let’s imagine a scenario, there are two developers who are new additions to two separate teams. Team A uses Javascript and Team B uses TypeScript. Both teams have been under a tight deadline, and the last few months worth of production code has been a tad sloppy. As the new dev, it’s your job to start building and expanding on these features your colleagues have worked hard on. As a member of Team A you quickly tackle your first ticket with enthusiasm but soon after compiling you notice several client errors a few minutes into use. So you backtrack and find the fault was an incorrect prop being passed to one of your react components. Same scenario but with Team B, Team B uses typescript and when adding the props to your new functional component you noticed the syntax in your ide complains about the missing props before you even began to compile. A quick look at your interfaces shows you that you were in fact missing a required prop and you can now easily add them with little effort. Two teams, two languages, same problem. One fix took additional developer hours, while the other took a few moments.
With TypeScript we caught the error during our build time, quickly looked at the code and made the required fix. With Javascript no build errors occurred but during our runtime some nasty behavior popped up and we then had to investigate further.
To be clear, I’am not saying TypeScript makes a better developer. A Developer is only as good as their ability to allow themselves to learn and adapt. What I’m saying is that in the pursuit of being the best developers we can be, we should take inventory of the tools that make our lives easier down the road. Does typescript mean typing more code, Yes. But the productivity gained and the codes ability to scale, and be maintained by multiple team members both junior and senior is worth that extra bit of typing.
I’am sure each developer has their own reasons for choosing to adopt TypeScript, these opinions are mine and may differ from your own. In the pursuit to write better, cleaner, and scalable code, Typescript is my cup of tea. As someone who loathes spaghetti code but accepts it as an unnecessary evil, my hopes are that over time more languages like these will help us humans make better decisions when turning our ideas into code. I hope you enjoyed this, and in a later piece we will explore getting set up with a react and node typescript project.
