TypeScript catches the mistakes your staff would otherwise find for you.
A field gets renamed in the API. Nothing breaks on the developer’s laptop, because the one screen that reads that field is never opened during testing. Three weeks later a branch manager rings to say the invoice total is blank.
That is the class of problem TypeScript removes. It sits on nearly everything we build, including this site, so it is not advice we hand out and then avoid taking ourselves.
TypeScript is JavaScript with a written description of your data attached. You state that an invoice has a customer, a date and a list of items, and the compiler refuses any code that treats it as something else. The check happens while the code is being written, not while your accounts clerk is using it.
Where it earns its place.
What the types actually catch
Not logic errors. A rule written wrongly will still be wrong. These are the dull mistakes that cause most support calls.
- A field renamed on the server and missed on one screen
- A value that can be empty, used as though it never is
- A number arriving as text, so two amounts join instead of adding
- A function called with arguments in the wrong order
- A screen left behind when the data model changes
Where we use it
Front and back, which is the point. The same description of a customer covers the web portal, the mobile app and the API.
- React and Next.js interfaces
- NestJS and Node APIs
- React Native and Expo apps
- Shared types between an app and its backend
- Scripts that touch production data
The part that pays for itself
Year one, types are a small tax. Year three, when somebody who did not write the system has to change a permission rule, they are the reason it can be done at all.
- Renaming something and being shown every place it is used
- Editors that suggest the right field instead of a guess
- A new developer reading the shape of the data before the code
- Changes reviewed against a contract rather than a memory
This matters in proportion to how long the system will live. For a campaign microsite it is close to worthless.
Adding it to JavaScript you already run
It goes in file by file. Nothing has to stop while it happens.
- Turn it on
- Types at the edges
- Convert by module
- Tighten
- Start with the API responses and the database rows
- Convert the modules that change most often first
- Leave settled code alone until there is a reason to touch it
- Tighten the compiler settings once the noise has gone
A full conversion in one go is usually a bad trade. Halfway is a legitimate place to stop.
When this is the right choice.
- A system several people will work on over years
- A mobile app and a web portal reading the same API
- A codebase somebody else will inherit from us or from you
- Rules about money, stock or permissions written in JavaScript
- A JavaScript application that breaks in a new place after every change
When it is not.
- A small script or a one-page site, where the setup costs more than it saves
- A team fluent in PHP with nobody to maintain a JavaScript toolchain
- A prototype meant to be shown once and thrown away
- An existing JavaScript application nobody is actively changing
Questions we are asked about it.
Is TypeScript a different language from JavaScript?
No. Every JavaScript file is already valid TypeScript, and the types are removed before anything runs in a browser. A developer who knows JavaScript can read it on day one.
Does it make the application slower?
No, because nothing extra reaches the browser or the server. The types exist only while the code is being written and compiled away afterwards.
Will it slow the build down?
It adds a compile step, so the first build of the day is longer. Day to day the editor does the checking as you type, and most teams stop noticing within a week.
Can you convert our existing JavaScript project?
Yes, gradually. We usually start with the data coming out of the API, because that is where the mistakes with real consequences are, then convert modules as they come up for change.
Do we need TypeScript if the project is small?
Probably not. Under a few thousand lines with one developer, plain JavaScript is fine and faster to move in. Size is the wrong question, though. Ask how long it has to live and how many hands will touch it.
Does it replace testing?
It does not. Types say the data has the right shape. They say nothing about whether the GST calculation is correct, and that still needs a test and somebody checking the output.
Services that use it.
What it sits with.
Not sure TypeScript is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private