If you are wondering why TypeScript development services have exploded in popularity in the last few years, read on. JavaScript is the most popular programming language in the world. Its humble beginnings as a DOM manipulation scripting tool pale in comparison to what it has grown into. With NodeJS and other tools at the community’s disposal, it’s become an all-purpose high-level programming language that rivals Python in popularity and utility.
Having said that, it’s no secret that JavaScript is divisive. In 2021 Stackoverflow’s developer survey over 38% of respondents dreaded JavaScript. Not the worst place to be in (PHP is twice as dreaded, for example), but just enough to make us question why.
What’s the problem with JavaScript?
JavaScript is quirky. Some developers learn to live with its idiosyncrasies, but it’s hard to deny that as a language JavaScript seems to have a mind of its own. As Douglas Crockford put it in his book “JavaScript has some good ideas and a few very bad ones”.
Without getting too technical, let’s just say that JavaScript is prone to unexpected behaviors. For example, an instruction that compares if 2 numbers are equal can potentially fail if the numbers are high enough (9999999999999999 is the same as 10000000000000000 in JavaScript).
Another point of contempt is one of JavaScript’s greatest strengths, its flexibility. JavaScript is permissive, which means that even if the code isn’t perfect, the engine tries to run it making an educated guess at what the developer was aiming for. When it works it’s magnificent, but when it doesn’t, it can produce weird results.
Case in point, semicolons (;) in JavaScript have a very specific role: they act as an end of statement signifier, telling the engine when a block of code ends. But in JavaScript, they are mostly optional. You could write a whole program without a semicolon and it would run seamlessly. Once again, JavaScript is making educated guesses of where each statement ends. Except, that’s not always the case.
Third-party libraries or specific engines might have a different opinion on where a statement ends, which translates to irregular behavior. A code might run in one environment and throw an error in another.
Some of the worst offenders have been ironed out in newer releases of JavaScript. Other quirks have been adopted by the community as shortcuts and features. Finally, some popular libraries and frameworks have done their part in fixing the worst aspects of the language.
JavaScript and scaling
Quirks aside, JavaScript is here to stay. There are no other competitive browser scripting languages on the market, and for all its issues, it’s a great language for beginners and professionals alike.
JavaScript is perfect for small-scale projects, or small teams. When you have one or two developers working with a thousand lines of code it’s very easy to spot irregular behaviors and squash them out.
Unfortunately, JavaScript quirks grow as products scale. What was originally an odd behavior can quickly become a nuisance, one that can be extremely difficult to debug. The bigger the team and the bigger the product, the more you need to rely on stable and predictable technology.
Remember the educated guesses I mentioned before? Imagine that one developer in a team makes a mistake that goes unnoticed because the code works as intended. Then, when the code is integrated into the project, the error still goes unnoticed.
Down the line the project scales, but this time around, the new code breaks down because it relies on the previous buggy code. Should be an easy fix, right? Maybe, unless another aspect of the project relies on the outcome of that odd behavior, in which case, changing it would break something else.
And so, one small and innocuous mistake snowballs into a full-on crisis. We would be telling a very different story if the language didn’t allow odd behaviors in the first place.
Enter TypeScript
JavaScript’s community is huge and there are hundreds of tools designed to avoid that kind of situation. Still, some developers prefer to cut the problem at the root, and that’s where TypeScript comes in.
TypeScript is a superset of JavaScript developed by Microsoft and released in 2012. It has a strict syntactical approach that adds optional static typing to JavaScript. To avoid technicalities, let’s just say that TypeScript enforces some rules that make code more predictable and reliable.
TypeScript was designed from the ground up to be like JavaScript but scalable. That’s why, just like its predecessor, it’s a multipurpose language that can be used to write client-side or server-side applications.
TypeScript isn’t a different programming language. Anyone who knows JavaScript can adapt to TypeScript with very little effort. It’s like an English speaker learning to write with a different style instead of learning a whole different language.
TypeScript code transcompiles to JavaScript, so it can run effortlessly in any environment that runs JavaScript. From an investment perspective, it’s a low-cost upfront investment of both time and resources.
Remember that StackOverflow survey I mentioned before? TypeScript ranks as the third most loved programming language right behind Rust and Clojure. It’s the second most mentioned programming language when asked what technology developers would like to incorporate into their projects.
The reason for that is simple: TypeScript has taken over a decade of JavaScript and has incorporated fixes that developers have been begging for. To be fair, JavaScript gurus will have very little reason to migrate to TypeScript. But it can save hundreds of hours of debugging and migraines for junior developers and big teams.
Think of TypeScript as an implicit communication tool. When a developer writes code in the language, other team members can be sure that nothing weird is happening under the hood. You can grab and use the code without having to check for abnormal behaviors first.
And that’s why TypeScript is such a great tool for scalable projects: its outputs are more reliable, and the code is easier to understand. If a developer declares that a variable is a number it’s not going to magically turn into a string.
A few cautionary words…
TypeScript is great, but it’s not without its own set of issues. For one, it’s harder to read since there is a lot more to declare in comparison to JavaScript. When working with unfamiliar code, lack of readability can slow down production times.
Second, TypeScript is at its best when all its dependencies are typed. That’s unfortunately not true for most JavaScript third-party libraries, so by using another dependency you are opening the door for odd behaviors to creep back in.
Having said that, most developers slowly but surely adapt their libraries to a typed style. As a quick example, Angular and Vue 3, two of the most popular front-end frameworks in the market, have migrated to TypeScript.
Even with its limitations, if you are working with a big project or one that is bound to scale, then I hope I have made the case for TypeScript. This superset, young as it is, is gaining momentum with each passing year and has become a standard for IT companies worldwide.
