When a company hires a new developer, it can take up to six months for them to get fully up to speed on the company’s codebase.
One way to make this process less painful for the developer, and less expensive for the company, is to use a strongly-typed language like TypeScript.
A product manager commented to me that he had noticed that developing with TypeScript is faster.
TypeScript is more hospitable
When a developer is new to a codebase, it takes time to learn all the objects and components that have previously been built, and what properties and methods belong to them, and what helper functions have already been written.
Because TypeScript is strongly-typed, when you type a dot after the name of an object, your editing tool will offer only the properties and methods of that object in a dropdown. When editing JavaScript, it will offer anything that you have previously typed on the page, which is not nearly as helpful.
Static types are a sort of living documentation about what the code does and how to use it and extend it.
Expressing business logic with TypeScript
Objects, components, and functions can and should reflect business logic. For example, the workflow of a sale can be broken down into a series of objects and components; similarly, different types of people involved in business processes can be described by objects.
TypeScript is more reliable
Because it can catch type mismatches such as a number not being the same as a string, or a more complex object such as a customer address missing a key detail, TypeScript prevents at least 15% of bugs being shipped to production.
Static type systems like TypeScript (or Facebook’s Flow) can conservatively catch around 15% of bugs that seasoned developers inadvertently let slip into their code. If your team had an extra 15% time to ship features instead of fixing bugs, that would be nice, wouldn’t it?
TypeScript will tell you if the property you referenced does not exist.
If you call a function, you know what it returns, or if an argument is required, optional, or nullable. There are built-in safety rails so a developer is less likely to introduce new bugs.
TypeScript is more scaleable
As projects get larger, checking types becomes more of a headache. You will also have more developers writing code and using each other’s components and objects, so being able to reference these reliably without introducing bugs becomes even more important.
Your unit tests are more likely to catch errors if they are written in TypeScript. You will also need to ensure that your unit tests cover as many lines of production code as possible.
Manual migration to TypeScript
This involves migrating your project file by file, fixing type errors, and repeating until the whole project is migrated. The advantages of this approach are:
- There’s no need to pause development;
- It allows time for educating and onboarding developers.
The disadvantage of this approach is that it can take a very long time.
Automated migration
In this approach, you take a JavaScript or partial TypeScript project and convert it completely, using a script such as ts-migrate.
- This gives consistency across a project;
- Fixing just one type is much easier than fixing individual files;
- You are getting the reliability of TypeScript across your project straight away.
The disadvantages of this approach are:
- You may need to pause development;
- Many errors may be generated by the migration if your JavaScript is not easily convertible to TypeScript;
- The pull request resulting from the migration of an entire project will be huge;
- The migrated project may need a lot of QA testing.
Hybrid migration
Another approach is to automate the migration of some parts of your project, where this does not produce too many errors that will need manual intervention, and to manually migrate the rest.
In this way you get the advantages of both automated and manual migration, and lessen the impact of the disadvantages.
Find out more
- Training courses – Carnelian Web Services
- The Business Case for TypeScript – DEV Community, by Ben Makuh
- 8 Reasons to Adopt TypeScript for Scaling – Quantum Mob, by Ben Lokash
- Reflecting business logic rules into the domain models using typescript – Part 1, by Mohsen Sareminia – ITNEXT
- Reflecting business logic rules into the domain models using typescript – Part 2, by Mohsen Sareminia – ITNEXT
- Better Software Design with Application Layer Use Cases – Enterprise Node.js + TypeScript, by Khalil Stemmler
- Achieve Type Safety With TypeScript Magic, by Sunny Sun – Level Up Coding
- ts-migrate: A Tool for Migrating to TypeScript at Scale, by Sergii Rudenko
Leave a Reply