Bird
Raised Fist0
Typescriptprogramming~5 mins

What survives compilation to JavaScript in Typescript - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: What survives compilation to JavaScript
O(n)
Understanding Time 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.

Scenario Under Consideration

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.

Identify Repeating Operations

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.
How Execution Grows With Input

Since the type information disappears, only the function and its calls affect time.

Input Size (n)Approx. Operations
1010 function calls and prints
100100 function calls and prints
10001000 function calls and prints

Pattern observation: The work grows directly with how many times the function runs, not with type checks.

Final Time Complexity

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.

Common Mistake

[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.

Interview Connect

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.

Self-Check

"What if we added a loop inside the function that runs n times? How would the time complexity change?"

Practice

(1/5)
1. Which of the following TypeScript elements does NOT survive compilation to JavaScript?
easy
A. Interfaces
B. Functions
C. Classes
D. Variables

Solution

  1. Step 1: Understand TypeScript compilation

    TypeScript removes type-only constructs like interfaces during compilation.
  2. Step 2: Identify which elements remain

    Functions, classes, and variables are actual code and remain in JavaScript output.
  3. Final Answer:

    Interfaces -> Option A
  4. Quick Check:

    Interfaces are erased in JS output [OK]
Hint: Remember: types/interfaces vanish, code stays [OK]
Common Mistakes:
  • Thinking interfaces generate JavaScript code
  • Confusing types with variables
  • Assuming classes disappear
2. Which of these TypeScript code snippets will produce JavaScript code after compilation?
easy
A. type User = { name: string };
B. function greet() { console.log('Hi'); }
C. type ID = number | string;
D. interface User { name: string }

Solution

  1. Step 1: Identify code vs type declarations

    Types and interfaces are erased; only executable code remains.
  2. Step 2: Check each option

    Only the function greet produces JavaScript code.
  3. Final Answer:

    function greet() { console.log('Hi'); } -> Option B
  4. Quick Check:

    Functions compile to JS code [OK]
Hint: Only executable code survives compilation [OK]
Common Mistakes:
  • Assuming type aliases produce JS code
  • Confusing interfaces with functions
  • Thinking all declarations compile to JS
3. What will be the output JavaScript code after compiling this TypeScript snippet?
interface Person { name: string; age: number; }
const user: Person = { name: 'Alice', age: 30 };
console.log(user.name);
medium
A. const user = { name: 'Alice', age: 30 }; console.log(user.name);
B. interface Person { name: string; age: number; } const user = { name: 'Alice', age: 30 }; console.log(user.name);
C. const user: Person = { name: 'Alice', age: 30 }; console.log(user.name);
D. SyntaxError: interface not allowed in JS

Solution

  1. Step 1: Remove type-only declarations

    The interface Person is removed during compilation.
  2. Step 2: Remove type annotations

    The variable user loses its : Person annotation.
  3. Final Answer:

    const user = { name: 'Alice', age: 30 }; console.log(user.name); -> Option A
  4. Quick Check:

    Types/interfaces removed, code remains [OK]
Hint: Types vanish, only code stays in JS output [OK]
Common Mistakes:
  • Leaving interface in output
  • Keeping type annotations in JS
  • Expecting syntax errors for interfaces
4. Identify the error in this TypeScript code that prevents correct JavaScript output:
interface Data { id: number; }
function printId(data: Data) {
  console.log(data.id);
}
printId({ id: 5 });
medium
A. The interface Data causes a runtime error in JavaScript.
B. The type annotation data: Data is removed, so data.id is undefined.
C. The function printId is removed during compilation.
D. There is no error; the code compiles to valid JavaScript.

Solution

  1. Step 1: Understand interface removal

    Interfaces are erased and do not cause runtime errors.
  2. Step 2: Check function and parameter

    Type annotations are removed but the function and its logic remain intact.
  3. Final Answer:

    There is no error; the code compiles to valid JavaScript. -> Option D
  4. Quick Check:

    Interfaces vanish, functions remain [OK]
Hint: Interfaces don't cause runtime errors [OK]
Common Mistakes:
  • Thinking interfaces cause runtime errors
  • Believing type annotations remain in JS
  • Assuming functions get removed
5. Given this TypeScript code, what will the compiled JavaScript output be?
type Status = 'success' | 'error';
class Response {
  constructor(public status: Status) {}
  print() {
    console.log(`Status: ${this.status}`);
  }
}
const res = new Response('success');
res.print();
hard
A. SyntaxError: Type aliases not allowed in JavaScript
B. type Status = 'success' | 'error'; class Response { constructor(public status: Status) {} print() { console.log(`Status: ${this.status}`); } } const res = new Response('success'); res.print();
C. class Response { constructor(status) { this.status = status; } print() { console.log(`Status: ${this.status}`); } } const res = new Response('success'); res.print();
D. class Response { constructor() {} print() { console.log('Status unknown'); } } const res = new Response(); res.print();

Solution

  1. Step 1: Remove type alias

    The type Status is erased during compilation.
  2. Step 2: Remove parameter type annotation

    The constructor's public status: Status becomes status without type.
  3. Step 3: Keep class and method code

    The class and method remain unchanged except for type removal.
  4. Final Answer:

    class Response { constructor(status) { this.status = status; } print() { console.log(`Status: ${this.status}`); } } const res = new Response('success'); res.print(); -> Option C
  5. Quick Check:

    Types removed, class code remains [OK]
Hint: Types vanish, classes and methods stay intact [OK]
Common Mistakes:
  • Expecting type aliases in JS output
  • Thinking constructor parameters keep types
  • Assuming class code is removed
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard