MICROSIVE

TypeScript development for code the next team can maintain

You own the code we write, and one day another developer will open it. TypeScript makes that handover easier because the code itself says what shape every piece of data should have.

Reviewed by: Rahul Jaiswar, founder

What TypeScript is

TypeScript is JavaScript with a type system, made by Microsoft. The types are checked when the code is compiled and stripped out before it runs, so they catch mistakes while the code is being written and change nothing about how the finished program behaves.

TypeScript or JavaScript for a new business app?

TypeScript, if the app will live longer than a few months or more than one developer will touch it. An order, a pallet or an invoice passes through a form, an API, a database and a report. When a field is renamed in one place, TypeScript flags every other place that still uses the old name before the change ships.

Plain JavaScript is the quicker choice for a one-off script, or a prototype meant to test an idea within a few days. If the team has never used TypeScript and the deadline is close, learning the compiler late in a project costs real time.

Looking for a CRM built with TypeScript?

Twenty, an open-source CRM, is written mainly in TypeScript. When you judge any TypeScript CRM, ask whether strict mode is on and how its API types are generated. Custom fields you add later should arrive typed, not as loose data.

Microsive CRM is built on Twenty.

What types don’t catch

Types vanish when the code runs. Data coming in from a web form, a carrier’s webhook or a CSV export from your warehouse system is not checked by TypeScript at all. Checking it takes validation code, which the first pitfall below comes back to.

Where we use it

Microsive ATS, the recruitment software we built and run, is written in TypeScript. We also build client websites and web apps with it.

What we check

We validate data at the point it arrives, whether from a form, a webhook or another company’s API, instead of trusting the type we declared for it. Types are checked while the code is written. The data only shows up once the app is running.

Questions to ask a team writing TypeScript for you

  1. Is strict mode on, and does the build fail on a type error?
  2. Where does the code use any or an as cast, and why there?
  3. How is data from outside the app checked at runtime?
  4. Are the database types generated from the schema, or typed by hand?

TypeScript pitfalls

  • Casts that hide real errors. as SomeType tells the compiler to take the code’s word for it. Every cast deserves a second look in review.
  • Types that drift away from the database. Types generated from the database schema, by an ORM such as Prisma, stay in step with each migration. Hand-written ones fall behind.
  • Slow type checks. In a large codebase, type checking can become the slowest step of a release. Plan incremental builds early, and see whether the native compiler can take over the checking.

TypeScript can run through a whole app, from Next.js screens to a Node.js server, so both sides share one set of types. For custom software in general, see software and web apps.

Want TypeScript code your next developer can read?

Tell us what you’re building and who will look after it once it’s handed over, or which JavaScript codebase you want moved to TypeScript.

Start the conversation