Explain runtime vs compile-time types.

Understanding the distinction between compile-time and runtime types is fundamental to grasping how TypeScript enhances JavaScript. TypeScript introduces a powerful type system that primarily operates during the compilation phase, leaving the runtime behavior largely to JavaScript's dynamic nature.

Compile-Time Types

Compile-time types are the type annotations and checks that TypeScript performs before your code is executed. When you write TypeScript code, you're essentially providing metadata about the expected shapes and types of your data, variables, and function parameters. The TypeScript compiler uses this information to analyze your code for type errors, ensure type safety, and provide features like autocompletion and refactoring during development.

The primary goal of compile-time typing is to catch potential bugs and inconsistencies *before* the application runs. If a type error is found, the TypeScript compiler will typically prevent compilation or issue warnings, guiding the developer to fix the issue.

interface User {
  name: string;
  age: number;
}

function greetUser(user: User) {
  console.log(`Hello, ${user.name}!`);
}

const validUser: User = { name: "Alice", age: 30 };
greetUser(validUser);

// This will cause a compile-time error:
// Property 'age' is missing in type '{ name: string; }' but required in type 'User'.
// const invalidUser = { name: "Bob" };
// greetUser(invalidUser);

Runtime Types

Runtime types refer to the types of values that actually exist and are used when your code is running in its execution environment (e.g., a browser or Node.js). After TypeScript code is compiled, it is transpiled into plain JavaScript. During this process, all TypeScript-specific type annotations are erased. This is known as 'type erasure'.

Consequently, at runtime, the JavaScript engine has no knowledge of the interfaces, type aliases, or explicit type annotations (: string, : number) that were present in the original TypeScript code. JavaScript itself is a dynamically typed language, meaning it determines the type of a value during execution based on the value's content, not from static declarations.

function logType(value) {
  console.log(`Value: ${value}, Runtime Type: ${typeof value}`);
}

logType(10);       // Value: 10, Runtime Type: number
logType("hello");  // Value: hello, Runtime Type: string
logType(true);     // Value: true, Runtime Type: boolean
logType({ a: 1 }); // Value: [object Object], Runtime Type: object
logType(null);     // Value: null, Runtime Type: object (a well-known JavaScript quirk)

Key Differences and Relationship

The core relationship is that TypeScript's compile-time types provide a safety net and development assistance by *predicting* what the runtime types *should* be, but they do not *enforce* those types once the code is running. The runtime environment only sees the underlying JavaScript.

• Purpose: Compile-time types ensure correctness and provide tooling benefits during development. Runtime types are about the actual data behavior during execution.
• Existence: TypeScript types exist only during compilation and are erased. JavaScript types exist dynamically during runtime.
• Enforcement: Compile-time errors prevent compilation or warn developers. Runtime errors occur when JavaScript encounters unexpected values or operations.
• Tools: TypeScript compiler (tsc) for compile-time checks. JavaScript engine (V8, SpiderMonkey, etc.) for runtime execution.

While TypeScript's types disappear at runtime, this doesn't mean they are useless. They are incredibly valuable for development, catching errors early, improving code quality, and making large codebases more maintainable. If runtime type checking is strictly required (e.g., for validating external API data), it must be implemented explicitly in JavaScript using constructs like typeof, instanceof, or custom validation libraries, as TypeScript's type system won't do it automatically.