TypeScript vs JavaScript: Key Differences with Examples

TypeScript is JavaScript with a static type system added on top. Every JavaScript program is valid TypeScript syntax; TypeScript adds type annotations, a compiler that checks them before the code runs, and a build step that removes them again. At runtime there is only JavaScript, so the difference is entirely in what you find out before you ship.

type Product = { name: string; price: number };

function total(products: Product[]): number {
    return products.reduce((sum, p) => sum + p.price, 0);
}

const cart: Product[] = [
    { name: "Keyboard", price: 49 },
    { name: "Mouse", price: 25 },
];

console.log(total(cart)); // 74

In JavaScript the same function is the code minus type Product = ..., : Product[] and : number. The types add information for the compiler and the editor; they do not change what the program does.

TypeScript vs JavaScript at a Glance

The Same Code in Both Languages

Here is a function in JavaScript. Nothing in it says what user must look like:

function greeting(user) {
    return `Hello, ${user.firstName} ${user.lastName}`;
}

greeting({ firstname: "Ada", lastName: "Lovelace" });
// "Hello, undefined Lovelace", no error anywhere

The TypeScript version states the shape once, and the typo is reported before the code runs:

interface User {
    firstName: string;
    lastName: string;
}

function greeting(user: User): string {
    return `Hello, ${user.firstName} ${user.lastName}`;
}

greeting({ firstname: "Ada", lastName: "Lovelace" });
// error TS2561: Object literal may only specify known properties,
// but 'firstname' does not exist in type 'User'. Did you mean to write 'firstName'?

The annotations are the whole difference in syntax. TypeScript also adds a few declarations of its own (interface, type, enum, generics like Array<string>, access modifiers like private), but the statements, operators and built-in objects are JavaScript's.

What TypeScript Catches That JavaScript Does Not

JavaScript converts types silently. This bug is common with values that come from form fields, which are always strings. Run it to see what the compiler says:

// This does not compile: strings where numbers are expected.
function sum(values: number[]): number {
    return values.reduce((a, b) => a + b, 0);
}

const fromForm = ["10", "20", "5"];
console.log(sum(fromForm));

index.ts(7,17): error TS2345: Argument of type 'string[]' is not assignable to parameter of type 'number[]'.
  Type 'string' is not assignable to type 'number'.

In JavaScript this runs and prints 010205, because 0 + "10" is string concatenation. TypeScript refuses to compile until the strings are converted, for example with fromForm.map(Number).

The other big category is values that might be missing. Array.prototype.find returns undefined when nothing matches, and TypeScript makes you deal with it:

// This does not compile: find() can return undefined.
const users = [
    { id: 1, name: "Ada" },
    { id: 2, name: "Grace" },
];

const user = users.find((u) => u.id === 3);
console.log(user.name.toUpperCase());

index.ts(8,13): error TS18048: 'user' is possibly 'undefined'.

The plain JavaScript version crashes at runtime with TypeError: Cannot read properties of undefined (reading 'name'). The TypeScript fix is to handle the case the compiler pointed at:

const users = [
    { id: 1, name: "Ada" },
    { id: 2, name: "Grace" },
];

for (const id of [2, 3]) {
    const user = users.find((u) => u.id === id);
    if (user) {
        console.log(user.name.toUpperCase()); // user is narrowed to the object type here
    } else {
        console.log(`no user with id ${id}`);
    }
}

Output:

GRACE
no user with id 3

What TypeScript does not catch: logic errors (a wrong formula has the right type), and anything about data that enters the program at runtime. An API response typed as User is only as correct as the server that sent it, because the types are gone once the code runs. Check such data with runtime code.

Using JavaScript Libraries in TypeScript

Every npm package works from TypeScript, because the output is JavaScript anyway. The types for a package come from one of three places:

• The package ships its own .d.ts files. Most actively maintained packages do, and you install nothing extra.
• A separate @types package from the community DefinitelyTyped project: npm install --save-dev @types/lodash adds types for lodash.
• Nowhere. Then, with strict on, the import itself is an error:

error TS7016: Could not find a declaration file for module 'lodash'. '/project/node_modules/lodash/lodash.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/lodash` if it exists or add a new declaration (.d.ts) file containing `declare module 'lodash';`

The fix is to install the @types package if one exists, or to describe the module yourself in a .d.ts file; the declaration files page shows how.

The Build Step

Browsers and Node.js do not type-check, so TypeScript needs a step between your source and the code that runs. There are three common setups:

• tsc compiles everything. It type-checks and writes .js files, usually into a dist folder. Simple, and the standard for libraries.
• A bundler or dev server removes the types, and tsc --noEmit checks them. Vite and esbuild strip types without checking, which keeps reloads fast; the editor and a CI step run the type checker.
• The runtime removes the types. Current Node.js versions, Deno and Bun run .ts files directly. None of them type-checks while running, so tsc --noEmit (or deno check) is still how you find type errors.

JavaScript needs none of this, which is its biggest practical advantage for small scripts. The cost of the TypeScript step is mostly setup, a tsconfig.json and a typescript dev dependency, and compile time; TypeScript 7's native compiler cut that time by about ten times on large projects.

Learning Curve

Everything you know about JavaScript carries over, because TypeScript's runtime is JavaScript. The new material is the type system, and it comes in layers:

1. Annotations on variables, parameters and return values (: string, : number[]).
2. Object types with interface and type, optional properties, unions like string | number.
3. Narrowing: checking a value with typeof, in or === so the compiler knows which case you are in.
4. Generics, utility types such as Partial<T> and Pick<T, K>, and advanced types for library authors.

The first two layers cover most application code. Much of the typing is inferred, so a lot of TypeScript looks like JavaScript with annotations only on function signatures.

When to Choose TypeScript or JavaScript

Is TypeScript better than JavaScript? For code that several people maintain or that lives for years, usually yes, and the industry has moved that way: by GitHub's count of monthly contributors, TypeScript overtook both JavaScript and Python in August 2025 to become the most used language on GitHub. For small scripts, plain JavaScript is often the better tool.

Choose TypeScript when:

• More than one person works on the code, or it will be maintained for months or years.
• The codebase is large enough that you cannot keep every function signature in your head.
• You refactor often: renaming a property updates every use, and the compiler lists anything left over.
• You publish a library: the .d.ts files give its users autocompletion and checks.
• The framework expects it. Angular apps are written in TypeScript, Next.js and Astro scaffold new projects in TypeScript by default, and Vite's React, Vue and Svelte templates each come in a TypeScript variant.

Choose JavaScript when:

• The program is a short script, a one-off experiment, or a code snippet in a browser console.
• You are learning programming for the first time and want fewer concepts at once.
• There is no build step and you do not want one. Even then, // @ts-check with JSDoc gives you some checking in a plain .js file.

Migrating a JavaScript Project to TypeScript

A migration does not have to happen at once. The compiler accepts JavaScript next to TypeScript:

{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": false,
        "outDir": "dist",
        "rootDir": "src"
    },
    "include": ["src"]
}

With allowJs, .js files compile and can import from .ts files and the other way around. Then convert gradually:

1. Rename one file from .js to .ts and fix the errors the compiler reports in it.
2. Start with the leaves (utility modules with few imports), then work inward.
3. Turn on checkJs, or add // @ts-check at the top of individual .js files, to type-check files you have not renamed yet.

In checked JavaScript files, JSDoc comments supply the types:

// @ts-check

/**
 * @param {number} price
 * @param {number} qty
 * @returns {number}
 */
function lineTotal(price, qty) {
    return price * qty;
}

lineTotal("3", 2);
// error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

Some teams stop there: JavaScript files with JSDoc types, checked by tsc, and no build step for the code itself. Others go all the way to .ts. If you turn on strict in an existing project, expect many errors at first; the strict mode page lists what each flag checks so you can enable them one at a time.