Typescript has come a long way since its inception over six years ago and is being adopted by leading web companies. While there may be good reasons to avoid using it, chances are your excuses for not using TypeScript are just bad.
In this article, I’ll cover common concerns like the learning curve, tooling, development speed, sustainability and standards compliance.
1. The learning curve is too steep
Here’s a code snippet in TypeScript:
.js files will run without issues in older browsers.
If you’ve been working with scripting languages for a while, you’ve come to appreciate the speed of development that they enable. You can freely wrangle data structures on the fly without ever having to declare them up front. This freedom, however, comes at a cost. Dynamically typed programs are much harder to reason about than the statically typed ones since there is no compile-time validation of the data flowing through the program.
By looking at the code, we can infer that the
person parameter should be an
Object with properties
lastName. But there’s no guarantee that this will always be the case at runtime.
The larger your project is, the higher the chance type-related bugs will occur.
One way to shield your code against such bugs is through runtime type checks and additional unit tests like this:
But this solution is very verbose and leaves the responsibility to validate data on the developer. What if instead, we could simply add a type annotation to our function?
The above example is much more idiomatic and lets us focus on just validating the business logic in our tests.
This code successfully compiles. Notice how we didn’t have to explicitly say that the
user variable implements the
Person interface, nor did we have to define a class that extends it. One of the language’s design goals is not to create a “sound or provably correct type system”, but to “balance between correctness and productivity”.
What’s also important is that the TypeScript compiler doesn’t force you to declare types everywhere, you choose how aggressive you want to be with type safety. You may even decide to apply a different level of type strictness in different areas of your project. Such flexibility is not something that traditional statically typed languages offer.
4. It’s not going to be around in 5 years
You work in a fast-moving industry, and if you and your project can seriously benefit from certain technology today, consider adopting it. Even if you swap it with something else in 1–2 years, the benefits you reap during that time would have accelerated your project enough to make it worth it.
5. It’s not community-driven
A lot has changed since then. The team behind TypeScript realized that if they wanted to see a broader adoption of the language, they needed to be better embedded in the web development community by providing high-quality tooling and listening to the feedback. They went far beyond merely putting the source code out there while continuing development in a vacuum, but fully embraced the concept of Open Development.
In 2014, TypeScript’s code was moved to GitHub, and the development actually happens there (as opposed to developing elsewhere and just exporting new versions of code to GitHub, as seen in some projects). The project invites contributions in the form of logging bugs, documenting proposals and submitting pull requests. The issue tracker gets regularly looked at and every submission usually gets triaged within a few days. The core team has published the language’s design goals that I referred to earlier, which help the project stay true to its mission while still taking input from the community. They keep an up to date roadmap (a new release now happens roughly every two months), as well as document any breaking changes.
Taking all of that into account and reiterating the fact that TypeScript heavily relies on ECMAScript, I think it’s fair to say that the project is community-driven and has been for the past few years. Here’s what Tom Dale, a co-creator of EmberJS, said about TypeScript in 2017:
Most of all, I continue to be impressed by the professionalism of the TypeScript team. In an ecosystem that can feel built on a house of unmaintained cards, TypeScript’s drumbeat of constant, iterative improvement is refreshing.
6. Converting an existing project is too much work
return statements at the end of functions or blocks of unreachable code. Then, you can start renaming
.js files to
.ts one by one and addressing new compiler feedback. The default compiler options are pretty lax, but you can turn on stricter checks. You can even use a different set of compiler options on different parts of your project, letting your teams adopt TypeScript at their own pace, using as much or as little of it as they want. The bottom line is there is a smooth transition path that doesn’t halt development across the company, it’s not an all-or-nothing commitment.
You can choose to convert an existing project to TypeScript gradually, or perform a “big bang” conversion, or simply use it on a new project. There are also community projects like TypeWiz that automatically add missing type information to code.
camelize, a TypeScript declaration for it would look something like this:
After you import such declaration into your project, the TypeScript will know about the function’s types.
The types will then be automatically included by the compiler, and you’ll get on-the-fly type checking and autocomplete in your code editor. All or most of the packages you use should already have high-quality type declarations created for them, either bundled in or available via the DefinitelyTyped repo. The engineering team at Slack shared their experience:
Looking ahead and thinking about code maintenance, we appreciate the ecosystem around TypeScript. As heavy users of React and the Node/npm ecosystem, the availability of type definitions for third-party libraries is a huge plus. Many of the libraries we import are already TypeScript compatible. If definitions do not ship with the module itself, they are likely to be found in the fantastic DefinitelyTyped project. React, for instance, does not ship with type definitions, yet a simple
npm install @types/reactinstalls them with no further configuration required.
Are you currently using TypeScript or planning on using it? If not, what’s holding you back?
¹[^] According to ECMAScript’s standardization process, Stage 3 (“Candidate”) is the fourth out of five “maturity” steps of a standard proposal. It means that the proposal specification is ready for implementation in real world.
LogRocket: Full visibility into your web and mobile apps
LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
3 Replies to “7 bad excuses for not using TypeScript”
“This makes the learning curve extremely lean”
Most people don’t know what “learning curve” means. A steep learning curve actually means that learning increases rapidly with experience, i.e. it’s easy to learn.
A “lean learning curve” can only mean the person who drew the graph with a sharp pencil and produced a thin (“lean”) line. 🙂
Just use TDD and you’ll catch a lot more defects
JiveturkeyJay – 100% agree – TDD should be the first thing people look at if they aren’t doing it.
The number of places using Typescript – lots more code only to catch a handful of bugs – when they aren’t even doing unit tests – which catch real problems and give you confidence refactoring.
It’s kind of crazy.