Learn TypeScript - Why TypeScript and Its Benefits

#Introduction

The first question that comes up when learning TypeScript is: why bother adding types when JavaScript already works? Episode 1 answers this question by breaking down the problems a static type system actually solves, not just stylistic arguments.

TypeScript was launched by Microsoft in 2012, and by 2026 it has become one of the fastest-growing languages — used by major frameworks like Angular and NestJS, and the foundation of tooling in nearly every modern codebase. This popularity isn't a coincidence: there are clear technical reasons behind it.

In this episode you'll see a concrete JavaScript vs TypeScript comparison, understand how types benefit productivity and collaboration, and learn when TypeScript is actually the wrong tool.

#The Problem with Untyped JavaScript

#Errors Only Appear at Runtime

JavaScript is a dynamically typed language: a value's type is determined at execution time. As a result, many errors go undetected until the app is run — sometimes until a user stumbles into them. A classic example:

function hitungTotal(keranjang, kupon) {
    return keranjang.harga * keranjang.jumlah - kupon.diskon;
}
 
const hasil = hitungTotal({ harga: 50000, jumlah: 3 }, undefined);
console.log(hasil);

The function above will throw a Cannot read properties of undefined error simply because kupon wasn't passed in. In JavaScript, this error only surfaces when that line executes — most likely in production, not while writing the code.

TypeScript catches this case earlier. With the right types, calling hitungTotal without kupon becomes a compile-time error instead of a runtime one. Errors like this can be prevented before the code ever reaches your users.

error TS2554: Expected 2 arguments, but got 1.

#Invisible Contracts Between Functions

The bigger a project gets, the more functions call each other. Without types, you have to remember the shape of every parameter. A small change like adding a field to an object can ripple into bugs in unexpected places. This is what makes JavaScript hard to refactor safely.

#What TypeScript Adds

#A Static Type System and Compiler

TypeScript adds a static type system: types are checked at compile time, before the code runs. The tsc compiler analyzes the entire program and reports type mismatches as errors. Here's the TypeScript version of the earlier example:

type Keranjang = {
    harga: number;
    jumlah: number;
};
 
type Kupon = {
    diskon: number;
};
 
function hitungTotal(keranjang: Keranjang, kupon: Kupon): number {
    return keranjang.harga * keranjang.jumlah - kupon.diskon;
}
 
hitungTotal({ harga: 50000, jumlah: 3 }, { diskon: 10000 });

The declaration hitungTotal(keranjang: Keranjang, kupon: Kupon): number tells the compiler the shape of the parameters and the return type. If there's a wrong call, the error shows up in the editor before the app even runs.

#Editor Intelligence

Types aren't just about safety — they also inform the editor. Features like autocomplete, go to definition, and find references work far more accurately because the editor knows the shape of every value. This is why many developers report a real productivity boost after switching to TypeScript.

#Benefits for Teams and Scale

In a project worked on by many people, types act as documentation that's always in sync with the code. Interfaces describe the contract between modules without anyone having to read the entire implementation. Code review focuses on logic, not on guessing data shapes.

With types, moving between modules becomes faster too. The editor suggests the correct data shape before you type, and the compiler rejects incorrect shapes. Time that used to be spent tracing function definitions can be redirected to more important things.

Refactoring also becomes safer. Renaming a property or splitting a function will immediately surface every affected location. In episode 19 we'll discuss strategies for designing types to maximize this benefit.

#When TypeScript Is Less Appropriate

TypeScript isn't the answer to every situation. For throwaway prototypes, small scripts under 100 lines, or projects entirely dependent on dynamic data, the cost of writing types can outweigh the benefits. Plain JavaScript remains a legitimate choice.

Once a codebase starts having many interdependent files worked on by many people, this threshold is quickly crossed. That's the point where TypeScript pays back its entire investment.

#The TypeScript Ecosystem in 2026

The TypeScript ecosystem is very mature today: type definitions for almost every library are available through @types, the compiler is optimized with a much faster native version, and major frameworks treat TypeScript as a first-class citizen. Many new codebases start with TypeScript directly, without a JavaScript phase at all.

npm install --save-dev typescript
npx tsc --init

#Closing

Episode 1 explained TypeScript's fundamental rationale: catching errors earlier, making code easier to understand and refactor, and empowering the editor. You also learned when TypeScript is the right choice — and when it isn't.

Key takeaways:

• JavaScript is dynamically typed: many errors only appear at runtime.
• TypeScript adds a static type system checked at compile time.
• Types provide visible contracts between functions and modules.
• Autocomplete and safe refactoring are bonuses of having types.
• TypeScript is less suitable for small, short-lived prototypes.
• The 2026 ecosystem makes TypeScript the default choice for serious projects.

In the next episode 2 we'll discuss installation, tsconfig.json configuration, and basic tooling — every important compiler option like target, module, strict, outDir, and rootDir, complete with best practices for new projects. Get your terminal ready, because from this episode onward we'll be tweaking configuration often!