Is TypeScript a good investment for your next digital product?
There is no doubt that TypeScript is exploding in popularity while maintaining very high levels of developer satisfaction. However, being an improvement over JavaScript and an extension of its syntax does come with a cost — it requires writing more code, which takes more time and increases costs. If you’re planning to develop a digital product, you may at some point arrive at a conundrum — is TypeScript worth it? Answering that question requires taking a closer look at what exactly TypeScript is, what it does, why it takes up more time, and what benefits it brings.
Table of contents
Since its first release in 2012, TypeScript has taken the web development world by storm. In the 2021 Stack Overflow Developer Survey, TypeScript has advanced to the 7th spot on the list of most popular programming languages (source), with a little over 30% of all developers saying that they are familiar with it. That constitutes an increase of 5 percentage points over 2020 (source) and more than 20 percentage points over 2017 (source), when TypeScript first appeared on the list.
And it’s no surprise. In the same survey, TypeScript ranked as the 3rd most beloved programming language, behind only Clojure and Rust. 72% of developers said that they enjoy using TypeScript and want to continue, while only a little over 60% said the same thing about JavaScript and only 40% about PHP.
What is TypeScript?
TypeScript is an open-source programming language that builds on top of JavaScript and supports types. It brings better tooling into programming processes, so it’s widely used across all stages of digital product design and development.
TypeScript was invented for the development of large and complex apps. It enables developers to implement advanced tools and features into new and existing digital products. Its goal is also to help identify and fix bugs.
At Boldare, we use full-cycle product development that splits building a product into a number of phases. In the early phases, prototyping and MVP, pure JavaScript may be the right choice, but as the project grows and enters the product-market fit and scaling phases, TypeScript becomes indispensable.
What does TypeScript actually do?
Imagine that you’re storing merchandise in plain, unlabeled boxes. You’re familiar with your inventory, so you always remember which box to search for a specific item. Even when you hired an assistant, you were able to quickly get them up to speed so they could use your storage system with ease.
This approach may be beneficial at some stages of the business, as you don’t have to come up with an elaborate inventory management or labeling system or concern yourself with the logistics of updating all of that data.
However, as you start hiring more employees and expanding your warehouse, keeping track of the contents of each box and disseminating that information to all of your employees becomes much more of a burden. Why use TypeScript? It gives you the ability to label each box in a familiar, convenient way.
Benefits of TypeScript: Practical Examples
An object in JavaScript is a little like a box with named slots inside of it except that, unlike a physical box, it contains information.
This is how you would define an object in plain JavaScript:
manufacturer: 'Ford',
model: 'Explorer',
color: 'black',
year: 2019
}
console.log(car.manufacturer); // prints:
Ford
console.log(car.model); // prints: Explorer````So far, this is working perfectly fine. But what would happen if we invited a jolly British developer onto the team?
`console.log(car.colour); // prints: undefined`Oops! The ‘car’ object does not have a ‘colour’ property, it only has a ‘color’ property. In JavaScript, an error like this would fail silently. If it managed to get through the QA process, it would result in an ugly ‘undefined’ value somewhere in the user interface. Not an uncommon sight on the Internet.
This is an underlying fundamental flaw of JavaScript — as a loosely typed language, it defaults to failing silently and prefers an incorrect value over an error.
TypeScript offers a way to prevent errors like this by allowing developers to first declare the shape and contents of objects.
type Car = {
manufacturer: string,
model: string,
color: string,
year: number
}
// then create the object itself
const car: Car = {
manufacturer: 'Ford',
model: 'Explorer',
color: 'black',
year: 2019
} ```Now, if our tea-sipping teammate were to try and introduce their native spelling into the code, TypeScript would promptly warn them:
```console.log(car.colour); // Property 'colour' does not exist on type Car. Did you mean 'color'?```Of course, this doesn’t only help with reading properties — or taking things out of boxes, it also enforces the declared structure when new objects are created — when things are put into boxes.
```const car2: Car = {
manufacturer: 'Honda',
model: 'Civic',
color: 'red'
} // Property 'year' is missing in type '{ manufacturer: string; model: string; color: string; }' but required in type 'Car'.```As you might imagine, this is just the very tip of the iceberg. TypeScript also introduces concepts such as interfaces, abstract classes, generics and many more, taking JavaScript to a completely different level of sophistication.
How does all that translate to business applications?
CONS: Cost & complexity of using TypeScript
As with most things in life, the advantages of TypeScript are not free — they come with a cost in the form of additional work for the development of typings. This increased workload comes in several layers.
The most basic and obvious is simply the work required to develop typings — manually writing out the structure of all the objects and functions. This simply takes more keystrokes than plain JavaScript code.
Sometimes data is structured in a way that’s difficult to express in TypeScript. While this may be a code smell, suggesting that the application’s architecture or logic has itself become too complex, other times it’s actually because of TypeScript’s limitations. In the context of JavaScript development, this is a completely new type of challenge.
Typings also introduces a brand new type of bug: typing bugs. If a developer introduces incorrect typing into a codebase then other developers may be slow to catch it because of the perceived type safety.
Then, there is the issue of working with third-party libraries, which may not always include typings. In that case, the development team would have to either create their own typings — which may be prohibitively expensive — or loosen TypeScript’s settings to allow untyped code; although that would somewhat defeat the purpose of using TypeScript in the first place.
Libraries may also have incomplete or incorrect typings. Imagine the frustration of a comedically inclined burglar breaking into your warehouse and shuffling all your labels!
Finally, there is the issue of talent sourcing. Every TypeScript developer is also a JavaScript developer, but not every JavaScript developer is a TypeScript developer, therefore the pool of available talent is by definition smaller for TypeScript.
Overall, introducing TypeScript into a codebase means that more work will be needed to implement the same functionality. It also adds new types of bugs and challenges and increases the complexity of dependency management and the build process.
PROS: Developer experience, quality & scale in using TypeScript
What advantages does TypeScript offer to make up for all of that overhead? Some developers tend to perceive TypeScript as purely a quality assurance tool, helping to minimize the amount of bugs that make it out of a developer’s IDE and into the codebase. Thanks to static type checking, certain bugs can be caught and fixed very early on, significantly reducing their total harm, cost, and the amount of technical debt.
As you may know, code debt causes a lot of problems: low code quality, missing documentation, unintuitive design, etc. This can lead to lower customer retention, gaps within security systems, and other consequences — potentially resulting in the business failure of the product. Using TypeScript helps to minimize technical debt and keep the code documented.
One of the biggest benefits of TypeScript is the reduction in mental overhead it provides. You can easily remember what’s inside five or ten boxes. But a hundred? A thousand?
A popular phrase to describe TypeScript is “JavaScript that scales“. Just like businesses, applications tend to grow in scope and complexity. Without TypeScript, developers have to keep a lot of that complexity in their heads, which is difficult and exhausting, leading to a decrease in productivity and an increase in the number of bugs. TypeScript’s static type system not only analyzes the code for errors in real-time but also acts as a rudimentary form of documentation built right into the code.
This also has the effect of improving maintainability. TypeScript makes it easier to jump into a codebase after not working on it for an extended period of time. Onboarding new developers, or even transferring an entire codebase to a different vendor, is vastly easier, cheaper, and less risky when the codebase is fully typed.
Is TypeScript worth it?
While it is somewhat difficult to settle on a hard ROI for TypeScript, its soft benefits are extensive and hard to overstate. It’s an investment in the future of your codebase and your business, and it is almost guaranteed to pay dividends over the entire lifespan of your application.
In many cases, using TypeScript is a short-term loss for a long-term gain. The return on investment appears after a period of time, and it comes much quicker if you apply TypeScript to a larger project, or use it as a main programming language for conducting digital transformation.
TypeScript helps achieve long-term business goals and supports the scaling phase of software development by making future amendments to the code not only possible but also easily manageable. This results in lower development costs, less struggle with software for development teams and more chance of turning your digital application into a truly exceptional and widely desired product.
Share this article:
