3 Topics
Chapter•35 Minutes

Introduction: Why TypeScript Exists

Understand TypeScript's purpose, its relationship with JavaScript, the compiler workflow, and how to approach the course.

What Is TypeScript?

TypeScript is a statically checked superset of JavaScript. It adds a type system, interfaces, generics, and developer tooling while retaining JavaScript's runtime model. TypeScript source is normally compiled (or transpiled) into JavaScript, which is what browsers and Node.js execute.

The type system helps catch mistakes before a program runs: passing a string where a number is expected, accessing a property that may not exist, or forgetting to handle a variant in a union. It also improves editor autocomplete, navigation, and refactoring.

Types do not automatically validate external data at runtime. A value received from an API is still untrusted until your program checks it. TypeScript's guarantees are strongest when the codebase uses strict settings and avoids unnecessary any assertions.

Note

Think of TypeScript as a development-time safety net, not a replacement runtime or a substitute for validating untrusted input.

Diagram
A typed function
function formatPrice(amount: number, currency: string): string {
  return `${currency} ${amount.toFixed(2)}`;
}

formatPrice(12.5, "INR");
// formatPrice("12.5", "INR"); // Compile-time error
💡 The parameter annotations constrain calls to the function, and the return annotation documents and checks the result. The annotation is erased from emitted JavaScript; toFixed is a JavaScript runtime method.
Key Takeaways
  • TypeScript adds static analysis to JavaScript.
  • Type annotations are removed during compilation.
  • Types alone do not validate network or user input at runtime.
Knowledge Check

What executes in a standard browser after TypeScript compilation?

TypeScript vs JavaScript

JavaScript is the language runtime executes. TypeScript builds on JavaScript with syntax and analysis that help describe intended data shapes. Valid JavaScript is generally valid TypeScript, but a JavaScript project may still need configuration and dependency declarations to get the best type checking.

TypeScript is especially valuable in larger applications, shared libraries, APIs, and teams where data contracts evolve. It does add build configuration and requires developers to understand type errors. It does not make code automatically correct: incorrect declarations, unsafe casts, any, and unvalidated external data can undermine safety.

Note

Use TypeScript to make intended contracts explicit, then validate data that enters from outside your program.

JavaScript with a TypeScript contract
type User = {
  id: string;
  displayName: string;
};

function greet(user: User) {
  return `Hello, ${user.displayName}`;
}

const currentUser: User = {
  id: "u-101",
  displayName: "Asha"
};

console.log(greet(currentUser));
💡 The User type describes the shape expected by greet. It does not create a runtime User class or verify that an arbitrary JSON object has this shape.
Key Takeaways
  • JavaScript remains the runtime language.
  • TypeScript helps describe contracts and catch mismatches early.
  • The value of TypeScript depends on accurate types and disciplined boundaries.
Knowledge Check

Which statement is most accurate?

The TypeScript Toolchain

A typical project uses the TypeScript compiler (tsc) to type-check and emit JavaScript, while a bundler or framework may handle transformation as part of its build. These are related but distinct jobs: type checking verifies compatibility with the type system; bundling resolves modules and packages assets; runtime execution runs JavaScript.

Some tools transpile TypeScript quickly without performing full type checking. In those setups, run tsc --noEmit or an equivalent type-check step in CI. Keep the compiler version and project configuration consistent across local development and deployment.

Diagram
Typical package scripts
{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "build": "tsc",
    "start": "node dist/index.js"
  }
}
💡 typecheck checks the project without writing JavaScript. build emits output according to tsconfig.json. These commands are examples; a frontend framework may use its own build command while keeping a separate type-check script.
Key Takeaways
  • Type checking and bundling are different responsibilities.
  • tsc --noEmit is useful when another tool handles transpilation.
  • CI should run type checking so editor-only feedback is not the sole protection.
Knowledge Check

A transpiler strips TypeScript syntax but does not type-check the whole project. What should CI run to catch type errors?