TypeScript vs JavaScript: what is the difference?

In this article

1. Before you start
2. Why interviewers ask this
3. What each one is
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

A neighbouring topic is coding interview questions. This page assumes only that you have read a few lines of code.

Why interviewers ask this

The question is a quick way to see whether a candidate separates three things: when code is checked, what code actually runs, and what a build step is for. A weak answer says "TypeScript is JavaScript with types, so it is safer" and stops. A strong answer says that the checking happens before the program runs, that the types are removed afterwards, and that a type error therefore cannot be caught by the types at runtime.

The follow-ups usually probe that model: does the browser run TypeScript, does Node need a compiler, what does a type annotation cost at runtime. A Staff-level answer also names where TypeScript does not help, such as data that arrives from outside the program. If you are preparing for a role that uses either language, the JavaScript interview questions and the full stack developer interview questions pages cover the neighbouring ground.

What each one is

JavaScript

JavaScript is a dynamically typed programming language, whose behaviour is defined by the ECMAScript specification, that runs in browsers and in runtimes such as Node.js and decides what each operation does by looking at the actual value when the code runs.

TypeScript

TypeScript is a programming language that adds a static type checker to JavaScript: you describe the shapes of your values, and the checker reports mistakes before the program runs.

Static type checking

Static type checking is the analysis of a program's types without running it, so that code which would call a missing function or use a missing property is flagged before it executes.

Type erasure

Type erasure is the removal of TypeScript's static type annotations when it is turned into JavaScript, so the running program has only JavaScript's ordinary runtime value types and no checks from the annotations.

JavaScript in plain words

JavaScript is the language browsers and Node.js execute, and it works out what to do with a value only at the moment the value is used. The TypeScript Handbook describes JavaScript as offering only dynamic typing, which means you run the code to see what happens (The Basics, New Handbook). The runtime therefore meets a type mistake only when it reaches the line that uses the value. If a variable holds text and your code calls it like a function, nothing complains until that line runs, and then the runtime throws a TypeError.

In one precise sentence, JavaScript attaches types to values, not to variables, and checks them as each operation runs. That is flexible for small scripts and means the only way to learn what a function does with a given value is to call it, as the handbook explains.

TypeScript in plain words

TypeScript works like a spell-checker for code: it reads your program before you publish it, underlines mistakes, and leaves no trace of itself in what is published. The TypeScript Handbook describes the idea as a static type system that predicts what code will do before it runs.

The analogy breaks in one place. A spell-checker knows words, but TypeScript knows only the rules you write down or that it can infer, so it checks your description of the code, not the world the code meets. In one precise sentence, TypeScript is JavaScript you describe with types, checked by a tool (the compiler, called tsc) that then removes the descriptions. The handbook also notes that the checker flags code that is valid JavaScript but looks wrong, such as reading a property that does not exist on an object.

Worked example

One small function shows the difference. The function is illustrative, and its four calls cover one correct use and three mistakes. In TypeScript the function is written with three annotations:

function greet(person: string, date: Date): string {
  return "Hello " + person + ", today is " + date.toDateString() + "!";
}

After compiling, the annotations are gone and plain JavaScript remains:

function greet(person, date) {
  return "Hello " + person + ", today is " + date.toDateString() + "!";
}

The TypeScript version is 127 characters and the emitted JavaScript is 105, so erasure removes 22 characters, the three annotations.¹ Nothing else changes: the function that runs is the same either way.

Now call it four ways. In JavaScript, one call works, one returns a silently wrong greeting, and two throw a TypeError. TypeScript rejects three of the four before the program starts.¹

The third row is the costliest. A crash is loud and gets fixed; a greeting for "42" travels on into the rest of the program. This is the kind of mistake, a wrong type that is still valid JavaScript, that a static checker exists to catch.

The diagram shows the usual order of events. A TypeScript file is checked first, then the types are erased, and then plain JavaScript runs.

1 · Write2 · Check3 · Erase4 · RunReplay

Step-by-step description

1. A TypeScript file carries type annotations.
2. The checker reports errors before running.
3. The types are removed from the output.
4. Plain JavaScript runs with no annotations.

• A TypeScript file is checked first.
• The types are erased, and then plain JavaScript runs.

The handbook's "Erased Types" section shows undefined producing output without the annotations, so the annotations cannot catch a type error once the program is running. By default tsc still writes the JavaScript when it finds type errors (the noEmitOnError option stops that; see "Emitting with Errors" in the handbook), and Node's type stripping erases without checking at all, so checking and erasing are separate steps.

Trade-offs and edge cases

Which one wins on each question?

Neither language wins on every row: they differ in when types are checked, and that choice shifts cost between writing time and failure time.

Text description of the diagram

• JavaScript checks types as the code runs.
• TypeScript checks types before the code runs.
• TypeScript annotations are erased, so the running program has only JavaScript's runtime value types.

TypeScript costs a checking step and the work of writing and maintaining annotations. In return it moves a class of mistakes from run time to before-run time. The handbook documents strictness settings, among them noImplicitAny and strictNullChecks, and how much TypeScript catches depends on which are turned on, so "we use TypeScript" says little until you know the settings.

Does TypeScript always need a build step?

Node.js can run a TypeScript file directly, but only by removing the types, not by checking them. The Node.js documentation says: "If you are using v22.18.0 or later and your source code contains only erasable TypeScript syntax, you can execute TypeScript code without any flags." Versions 22.6.0 to 22.17 needed the --experimental-strip-types flag, and earlier versions cannot run TypeScript directly (Node.js application programming interface (API), TypeScript). The same page states that Node does not type check, and suggests running npx tsc --noEmit separately, for example in a continuous integration (CI) job.

Type stripping is the removal of type-only syntax without generating new code, and it handles type annotations, interfaces, type aliases and import type. It does not handle syntax that needs generated JavaScript, such as enum, parameter properties, namespaces with runtime code and import aliases; those need a runner or a separate transpilation step, per the Node.js page. So "TypeScript always needs a build step" is out of date, and "Node checks my types" is wrong.

Which one should you pick?

Pick TypeScript when others will read and change the code for months, and plain JavaScript when the code is small, short-lived or a prototype. That is advice, not a measured rule: the cost of annotations is paid every day, while the benefit shows when someone changes code they did not write.

Text description of the diagram

• Choose TypeScript when others will maintain the code for months.
• Choose plain JavaScript for small, short-lived code.

Two cautions apply. TypeScript checks the types you describe, so data that arrives from outside the program, such as a network response, is only as safe as the description you wrote for it. And usage shares change yearly; see the technology section of the latest Stack Overflow Developer Survey. For framework rounds the choice is often made for you, so see the Angular interview questions; if you come from a statically typed language, the Java and C# pages show the habit TypeScript borrows.

How to answer it in an interview

The spoken structure: say when each language finds errors, say that types are erased, then give the trade-off and when you would choose each.

Common mistakes

• "TypeScript replaces JavaScript." (wrong) The output is JavaScript and the types are erased. (right) "TypeScript is checked first, then compiled to JavaScript, which is what runs."
• "TypeScript checks types at runtime." (wrong) Checking happens before the program runs. (right) "The checker runs ahead of time; at runtime only JavaScript's own value types remain."
• "TypeScript always needs a build step." (wrong) Recent Node.js versions can strip types and run a file directly. (right) "Node can run erasable TypeScript, but it does not check types, and some syntax still needs compiling."
• "If it compiles, the data is valid." (wrong) Types describe your code, not what arrives from a network call. (right) "I validate outside data at the boundary and use types for everything inside."

Follow-up questions

Does TypeScript check types at runtime?

No. The checking is static, done before the program runs, and the types are erased from the output, so the running program is plain JavaScript with only its ordinary runtime value types, such as those typeof reports.

Can Node run TypeScript without compiling it first?

Yes for erasable syntax from version 22.18.0, and Node strips the types without checking them; the build-step section above has the limits.

Can a browser run TypeScript?

No. A browser runs JavaScript, so TypeScript is compiled or stripped to JavaScript first.

Is TypeScript better than JavaScript?

It is better for some jobs and worse for others. TypeScript moves mistakes earlier at the cost of tooling and annotations, so it suits shared, long-lived code, while a small script may not repay that cost.

Should I learn JavaScript before TypeScript?

Learning JavaScript first is sensible, because the handbook's types describe the behaviours of JavaScript values. Practising with the JavaScript interview questions builds that base before you add types.

Does TypeScript make code run faster or slower?

Annotations are erased and do not change how the program behaves at runtime, so its speed is that of the emitted JavaScript (The Basics). The costs are compile and check time. When the compile target is an older ECMAScript version, the handbook's "Downleveling" section explains that newer syntax is rewritten, so that output can differ from hand-written modern JavaScript.

Sources

1. TypeScript Handbook: The Basics — Microsoft, typescriptlang.org (accessed 2026-10-26), 26 Oct 2026
2. Running TypeScript Natively — Node.js Learn, OpenJS Foundation (accessed 2026-10-26), 26 Oct 2026
3. Node.js API: Modules: TypeScript — Node.js documentation, OpenJS Foundation (accessed 2026-10-26), 26 Oct 2026
4. TypeScript Basics (TypeScript New Handbook) — Microsoft, TypeScript team (accessed 2026-10-26), 26 Oct 2026