This is going to be yet another article about the pros and cons of TypeScript based on my experience. I hope to give you a better understanding on it. I also hope to help you decide whether switching to it or not is worth for you.
What is TypeScript?
Simply put, TypeScript is a JavaScript superset. Meaning the TypeScript code is compiled into the plain old JavaScript that most browsers can run.
TypeScript adds to JavaScript some missing features such as static types system (you probably guessed from its name 😊). You can easily learn it yourself using its documentation.
My experience with TypeScript
In my first job we used to develop and maintain a legacy code written in angularjs, a.k.a angular 1. The codebase was not a pretty sight.
There were global variables referenced from everywhere. You changed a line of code to fix a bug only to discover you made 3 other bugs somewhere else.
There was no real use of dependency injection which was the main thing about angularjs at the time. There were also no tests so you couldn’t tell if you broke something while fiddling with the code.
After about 2 years of working this way we decided to refactor and switch to React. React was such an improvement to our frontend stack. Our code was divided into smaller, more maintainable components and we used PropTypes for dynamically type checking.
After a while into using React my teammate convinced us to start using TypeScript and boy, how I loved it. The setup wasn’t easy, it took a few days to make it work with the existing code. But after doing that things started to get much smoother.
Now warnings and errors that showed in the browser’s console or the development server were now compile errors. It meant no more procrastinating. We fixed issues as soon as they rose instead of lazing out and waiting for them to become bugs.
A few years have passed since my first role in that organization. Now I’m in another project which doesn’t use TypeScript so I decided to write this article and I dedicate it to the team ❤.
Pros 👍
Static type checking
In JavaScript you don’t need (actually you can’t as far as I know) to define types for variables. In some cases it has its advantages. But since you don’t enforce types you can misuse or misinterpret code easily which can lead to bugs.
For example:
function double(x) {
return x * 2;
}
console.log("ali" + double("ba")); // prints "aliNaN"
In that case I could assume that “double” takes strings as argument and duplicate them. So in the example I would expect the output: “alibaba”.
In TypeScript you define parameter types which saves you from mistakes like that:
function double(x: number) {
return x * 2;
}
console.log("ali" + double("ba")); // error: Argument of type '"ba"' is not assignable to parameter of type 'number'.
Of course it applies on other things besides parameters such as variables, function outputs, etc. See Basic Types.
Compilation prevents from errors to get into production
JavaScript is a scripting language which is executed line by line. Because of that you will discover if the code is broken only when it’s executed by runtime environments.
In other hand TypeScript code must be compiled. So you’ll see the errors in your terminal or code editor right away which can save you time.
TypeScript can work with vanilla JavaScript
In other static languages like Java you must define types everywhere. But because TypeScript is a subset of JavaScript it can work alongside it, you just need to configure it.
Better code documentation and design
When you incorporate types in your code you basically make it self-documenting. You also make it easier to understand how to use it properly.
Furthermore you’re enforced to pay more attention and effort into design rather then rushing into implementation.
Extensive IDE integration
TypeScript is already supported on most used code editors and IDEs:
That means you can start developing with TypeScript today without replacing you favorite developing tools.
Visual Studio Code for example supports navigation, formatting, code suggestions, syntax highlighting and many more!
Ready TypeScript definitions for non TypeScript libraries
Some libraries are written with TypeScript and are shipped with the type definitions out of the box, for example: material-ui.
But in reality many libraries are still written in JavaScript so you need to get the type definitions somehow. Lucky for us the most of them have type definitions written by the community.
If you can’t find any types you can still write your own type declarations.
TypeScript sounds amazing, I’ll start using it today!
Wait, hold on! I do love TypeScript there are also drawbacks to consider which I’ll discuss about in this section.
Cons 👎
It needs to be compiled
Earlier I mentioned compilation as an advantage but it’s also a disadvantage since it adds time to development and building.
I think the compilation time isn’t that critical but I don’t have experience working with large scale projects.
I will mention that, mainly in frontend, you will run some tools to modify your code anyway such as webpack, babel, etc. So compiling to TypeScript isn’t so different than bundling or minifying.
It’s nice to know that deno (a potential successor to nodejs) supports TypeScript out of the box without needing to compile!
It takes time to learn and get used to
I agree that the syntax might be a little intimidating at first.
Lucky for us the TypeScript documentation is good.
You even have the playground to fiddle with and test TypeScript’s features.
We already have type checking with PropTypes (React developers’ argument)
Surely there are alternatives to type checking such as PropTypes for React components’ props. But what if I want to check types for other things?
PropTypes is also easily replaceable by TypeScript. You just have to define interfaces for your props instead or you can use automatic tools for that.
Final words
I hope you enjoyed reading this article. Please leave a comment and let me know what you choose because I’m really looking forward to hearing it 😁
PS
I’ll appreciate it if you share this article and motivate me to write more content about dev stuff 🤓.
I’m new into writing but I hope my content will become of better quality with time. If it’ll help you to make better products that serve the needs of your customers I’ve done my job😁
Top comments (2)
All you cons are really pros, compilation phase is a good thing, it is automation, some program does some work for you, in this particular example it does code correctness verification by type definitions and inference. Second, learning is a daily routine of every developer, at least it should be. Third, you don't need to use PropTypes. PropTypes are doing the same thing but in the runtime, where TS will do that in the compile time.
I guess you're right, these cons can really be pros depending on your needs 😊
I tried listing these cons from an objective point of view.
Thanks for your comment!