2012
TypeScript goes public
Microsoft introduces TypeScript on 1 October 2012. The aim: make JavaScript easier to use for larger applications, with static type checking and better development tools.
Around half of our projects use TypeScript. Since switching from JavaScript to TypeScript for our projects in 2020, it has become our preferred language for a wide range of applications. We use it for the screens you see and the software running behind them. Why do we enjoy working with it? We get fast feedback on our code and can use plenty of existing building blocks.
Around 50% of our projects use TypeScript
Our preference over JavaScript since 2020
One language for frontend and backend

TypeScript at 10KB
An ordering portal, a learning platform or an integration between systems: TypeScript appears in around half of our projects. Since our switch in 2020, we have built up plenty of experience with it.
Its value becomes clear during development. When we change a data structure, the type checker points out which code needs to change with it. And because the Glossary · In brieffrontendThe frontend is the part of a website or application that users see and operate, such as pages, buttons, forms and interactive screens.Read more and Glossary · In briefbackendThe backend is the part of an application that processes data, applies business rules and communicates with other systems on the server. Users usually access it through a frontend or API.Read more share a language, we can use those contracts on both sides. Here is why that works so well for us.

Why we use TypeScript
The extensive type system catches many errors during development and compile-time checking. That is particularly useful when we code with AI: generating code, checking it and adjusting it can happen in quick succession. An incorrect field or an unhandled case shows up straight away. Tests and careful review still matter, but we do not need to start the application to spot every type error.
TypeScript compiles to JavaScript, which runs in the browser and on the server with Node.js. This lets us write the frontend and backend in the same language and share types between them. Outside languages that compile to JavaScript or WebAssembly, that combination is fairly unusual. It means less switching between languages and makes it easier to check the contracts between components.
The web ecosystem is enormous. Good libraries often exist for forms, charts, authentication and integrations. We do not have to build these parts from scratch every time. That leaves more attention for the logic specific to your application. Choosing which dependencies to add still requires care.
The extensive type system catches many errors during development and compile-time checking. That is particularly useful when we code with AI: generating code, checking it and adjusting it can happen in quick succession. An incorrect field or an unhandled case shows up straight away. Tests and careful review still matter, but we do not need to start the application to spot every type error.
How we decide
Ruby and Python also have increasingly capable typing tools. In our work, we still find the integration between language, editor and Glossary · In brieflibraryA library is a collection of reusable software code for a defined task. An application can call that code to use existing functionality.Read more stronger with TypeScript. That is an important reason for our preference.
There is a downside, too. The ecosystem moves so quickly that a year-old Glossary · In briefcodebaseA codebase is the collection of source code used to build and maintain a software product or component.Read more can already look hopelessly outdated by the latest fashion. And we understand developers who feel that TypeScript and JavaScript Glossary · In briefframeworkA framework is a coherent foundation for software development, providing reusable code, a defined structure and conventions for building an application.Read more add unnecessary complexity. Configuration, build steps and elaborate types can make a simple application needlessly difficult.
So we do not choose TypeScript automatically for every project. Another language may be a better fit for the challenge, the existing system or the team taking it forward. And working software does not need rebuilding just because a new framework has appeared.
Which language suits your application?
Our work
At Zetprofiel, we use TypeScript for an ordering portal that draws and calculates custom profiles. For Stichting Techniek Bedrijven, we use it in a platform connecting students and businesses. Different projects, with the same need for clear data contracts.
At Brainstud, we worked with React and TypeScript on an existing learning platform. And the website you are reading right now is written in TypeScript, too.
Explore our cases
The language explained
TypeScript is an Glossary · In briefopen sourceOpen source is software whose source code is available under a licence that allows others to use, study, modify and redistribute it.Read more programming language from Microsoft that adds types to JavaScript. You can specify that a price is a number, a name is text and an order has only a few valid states. The type checker checks whether the code follows these rules. You will often see an error in your editor as you write.
The types disappear when the code is converted to JavaScript. They do not automatically check what a user enters or an external Glossary · In briefAPIAn API is a defined way for software to exchange data or call functions in other software without needing to know how that software works internally.Read more returns. We need to validate that input separately. An incorrect calculation can also pass a type check. TypeScript helps us find errors; it does not prove that an entire application is correct.
A mistake a customer could notice
An order costs €20, with €5 for shipping. But an input field supplies the shipping cost as text: "5". When JavaScript adds a number and text, it joins them together instead of adding their values. The result is "205".
If the payment code treats that value as an amount in euros, the application requests €205 instead of €25. The code keeps running. We use whole euros in this example to make the mistake easy to follow.
// JavaScript: an amount that changes unnoticed
const price = 20;
const shippingInput = "5";
// A number + text joins the values together.
const wrongTotal = price + shippingInput;
console.log(wrongTotal);
// "205", although the customer expects 25 euros.
// Suppose the payment code reads this as euros:
const wrongPaymentRequest = {
amount: wrongTotal,
currency: "EUR",
};
console.log(wrongPaymentRequest.amount);
// Still "205". JavaScript reports no error.A function with clear rules
A function is a small recipe: give it the price and shipping cost, and it returns the total. With number, we specify that both ingredients must be numbers. The result must be a number too.
If we pass the text "5", TypeScript flags the mismatch when checking the code. That is why the incorrect call is commented out in the example. Simply converting a JavaScript file to TypeScript does not fix the mistake; these type rules make the difference.
// TypeScript: rules for the calculation
function calculateTotal(
price: number,
shipping: number,
): number {
const total = price + shipping;
return total;
}
const amountAsText = "5";
// TypeScript would reject this call:
// calculateTotal(20, amountAsText);
// Text (string) does not belong in a number field.
// With two numbers, addition works as intended.
const exampleTotal = calculateTotal(20, 5);
console.log(exampleTotal);
// 25From form to calculation
The fix is to convert the text from the input field to a number first. That is what Number does. We also check for empty, invalid or negative input. Then the calculation can proceed: €20 plus €5 becomes €25.
TypeScript helps us spot the mismatch between the input and the calculation. Checking what a user enters is still necessary while the application runs. The two checks complement each other.
// Convert and check the input
function readShipping(input: string): number {
const amount = Number(input);
if (
input.trim() === "" ||
!Number.isFinite(amount) ||
amount < 0
) {
throw new Error("Enter a valid shipping cost.");
}
return amount;
}
const shipping = readShipping("5");
const correctTotal = calculateTotal(20, shipping);
const correctPaymentRequest = {
amount: correctTotal,
currency: "EUR",
};
console.log(correctPaymentRequest.amount);
// 25: the amount we expect.
// Input such as "free" fails the input check:
// readShipping("free");
// This stops us calculating with an invalid amount.// JavaScript: an amount that changes unnoticed
const price = 20;
const shippingInput = "5";
// A number + text joins the values together.
const wrongTotal = price + shippingInput;
console.log(wrongTotal);
// "205", although the customer expects 25 euros.
// Suppose the payment code reads this as euros:
const wrongPaymentRequest = {
amount: wrongTotal,
currency: "EUR",
};
console.log(wrongPaymentRequest.amount);
// Still "205". JavaScript reports no error.
// TypeScript: rules for the calculation
function calculateTotal(
price: number,
shipping: number,
): number {
const total = price + shipping;
return total;
}
const amountAsText = "5";
// TypeScript would reject this call:
// calculateTotal(20, amountAsText);
// Text (string) does not belong in a number field.
// With two numbers, addition works as intended.
const exampleTotal = calculateTotal(20, 5);
console.log(exampleTotal);
// 25
// Convert and check the input
function readShipping(input: string): number {
const amount = Number(input);
if (
input.trim() === "" ||
!Number.isFinite(amount) ||
amount < 0
) {
throw new Error("Enter a valid shipping cost.");
}
return amount;
}
const shipping = readShipping("5");
const correctTotal = calculateTotal(20, shipping);
const correctPaymentRequest = {
amount: correctTotal,
currency: "EUR",
};
console.log(correctPaymentRequest.amount);
// 25: the amount we expect.
// Input such as "free" fails the input check:
// readShipping("free");
// This stops us calculating with an invalid amount.A few milestones
From its first public release to our switch: how TypeScript became a regular part of our work.
2012
Microsoft introduces TypeScript on 1 October 2012. The aim: make JavaScript easier to use for larger applications, with static type checking and better development tools.
2014
TypeScript 1.0 arrives. Developers can use the language for production applications and build on existing JavaScript code.
2016
TypeScript 2.0 introduces strict null checks. Teams can check that they handle null and undefined before using a value.
2020
10KB switches from JavaScript to TypeScript for its projects. The type system's fast feedback and the shared web ecosystem make it our preferred language for a wide range of applications.
2022
TypeScript 4.9 adds satisfies, another way to check data against an agreed structure. The language continues to evolve, offering more help to catch mistakes while writing code.
TypeScript at other companies
In 2017, Slack described how its team gradually converted the desktop app from JavaScript to TypeScript. New features and bug fixes could continue in the meantime. A switch does not always need to mean a complete rewrite.
It is a familiar question for us when working on existing software: how do you improve the foundations while users need to keep working?

TypeScript at other companies
In 2020, Airbnb published ts-migrate, a tool for converting large amounts of JavaScript to TypeScript. The accompanying article described how TypeScript became the standard for its web frontend.
Automation was a starting point: the generated code still contained exceptions that developers needed to tighten up later. Passing the compiler does not automatically mean a file benefits from everything the type system offers.

TypeScript at other companies
In 2024, Figma described moving code in its Glossary · In briefprototypeA prototype is an early, simplified version of a product. It makes an idea visible or testable so you can learn before developing the complete product.Read more viewer from its own language, Skew, to TypeScript. Its custom language had made collaboration and integration with other code increasingly difficult.
The switch gave the team access to existing tools and libraries and made it easier for developers to get started. That is exactly why we look beyond syntax when choosing a language.




From a custom portal to an existing application: our cases explain the choices we made and why.
Ewout

TypeScript is often our starting point. Whether it is the best choice for your application depends on what you want to build, what is already there and who will be working with it. Talk it through with Ewout and we can help you choose a suitable language and approach.
CONTACT
Have a question or want to discuss your software? Leave your details and we will get back to you soon.