What survives compilation to JavaScript in Typescript - Time & Space Complexity
When TypeScript code is turned into JavaScript, some parts stay and some parts disappear.
We want to know which parts keep running and affect how long the program takes.
Analyze the time complexity of the following TypeScript code after compilation.
interface User {
id: number;
name: string;
}
function greet(user: User) {
console.log(`Hello, ${user.name}`);
}
const user = { id: 1, name: "Alice" };
greet(user);
This code defines a type, a function using that type, and calls the function.
Look for loops or repeated steps that run many times.
- Primary operation: The function call and console output.
- How many times: Called once here, but could be many times if used in a loop.
Since the type information disappears, only the function and its calls affect time.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 function calls and prints |
| 100 | 100 function calls and prints |
| 1000 | 1000 function calls and prints |
Pattern observation: The work grows directly with how many times the function runs, not with type checks.
Time Complexity: O(n)
This means the program's running time depends on how many times the function is called, not on the TypeScript types.
[X] Wrong: "TypeScript types slow down the program because they add extra work at runtime."
[OK] Correct: TypeScript types are removed during compilation and do not exist in the JavaScript that runs, so they do not affect runtime speed.
Knowing what stays after compilation helps you understand what really affects your program's speed and what is just for helping you write better code.
"What if we added a loop inside the function that runs n times? How would the time complexity change?"
Practice
TypeScript elements does NOT survive compilation to JavaScript?Solution
Step 1: Understand TypeScript compilation
TypeScript removes type-only constructs like interfaces during compilation.Step 2: Identify which elements remain
Functions, classes, and variables are actual code and remain in JavaScript output.Final Answer:
Interfaces -> Option AQuick Check:
Interfaces are erased in JS output [OK]
- Thinking interfaces generate JavaScript code
- Confusing types with variables
- Assuming classes disappear
Solution
Step 1: Identify code vs type declarations
Types and interfaces are erased; only executable code remains.Step 2: Check each option
Only the functiongreetproduces JavaScript code.Final Answer:
function greet() { console.log('Hi'); } -> Option BQuick Check:
Functions compile to JS code [OK]
- Assuming type aliases produce JS code
- Confusing interfaces with functions
- Thinking all declarations compile to JS
interface Person { name: string; age: number; }
const user: Person = { name: 'Alice', age: 30 };
console.log(user.name);Solution
Step 1: Remove type-only declarations
Theinterface Personis removed during compilation.Step 2: Remove type annotations
The variableuserloses its: Personannotation.Final Answer:
const user = { name: 'Alice', age: 30 }; console.log(user.name); -> Option AQuick Check:
Types/interfaces removed, code remains [OK]
- Leaving interface in output
- Keeping type annotations in JS
- Expecting syntax errors for interfaces
interface Data { id: number; }
function printId(data: Data) {
console.log(data.id);
}
printId({ id: 5 });Solution
Step 1: Understand interface removal
Interfaces are erased and do not cause runtime errors.Step 2: Check function and parameter
Type annotations are removed but the function and its logic remain intact.Final Answer:
There is no error; the code compiles to valid JavaScript. -> Option DQuick Check:
Interfaces vanish, functions remain [OK]
- Thinking interfaces cause runtime errors
- Believing type annotations remain in JS
- Assuming functions get removed
type Status = 'success' | 'error';
class Response {
constructor(public status: Status) {}
print() {
console.log(`Status: ${this.status}`);
}
}
const res = new Response('success');
res.print();Solution
Step 1: Remove type alias
Thetype Statusis erased during compilation.Step 2: Remove parameter type annotation
The constructor'spublic status: Statusbecomesstatuswithout type.Step 3: Keep class and method code
The class and method remain unchanged except for type removal.Final Answer:
class Response { constructor(status) { this.status = status; } print() { console.log(`Status: ${this.status}`); } } const res = new Response('success'); res.print(); -> Option CQuick Check:
Types removed, class code remains [OK]
- Expecting type aliases in JS output
- Thinking constructor parameters keep types
- Assuming class code is removed
Ready to prove it?
Pass the test and this pattern moves unknown
