Skip to content
BiliMind
Roadmap

How to learn TypeScript

This path assumes you can already write JavaScript that runs. It gets you to the point where you can read most TypeScript codebases, write types that survive contact with real APIs, and debug type errors without guessing.

Hours

70-90 hours

Calendar

about 12 weeks at 6 hours a week

Stages

6

Start from

You need working knowledge of JavaScript: functions, objects, arrays, promises, and modules. You do not need to have used classes, generics, or any other language with static types.

Why the usual order fails

Coming from JavaScript, the hard part of TypeScript is not the annotations. Writing `const x: number = 3` takes five minutes to learn. The hard part is that the type system is a language of its own, with its own syntax, its own control flow, and its own way of failing. Most roadmaps treat TypeScript as JavaScript plus some labels, so they start with basic annotations and move quickly to React or Node. That order fails because it hides the type system behind application code, and you end up fighting errors you cannot read.

This path inverts that order. In week one you write no application code at all. You write types, unions, and generics in a scratch file, and you read the errors until they make sense. Most plans have you annotating a to-do app by week two; here you are still working through conditional types and mapped types. The result is that when you do meet TypeScript in a real codebase, the errors are information rather than noise.

The path, in the order it has to be walked.

Each stage assumes the one above it and nothing below it. The check at the foot of each is the point — you are meant to fail it, go back, and try again before moving on.

  1. The type language

    weeks 1-2

    You learn the type system as a language before you use it on real code. This stage sits first because every later stage assumes you can read a type error and write a type from scratch.

    • type annotations vs type inference
    • primitive types: string, number, boolean, null, undefined
    • object types and optional properties
    • union types and literal types
    • type aliases
    • interfaces vs type aliases
    • the `unknown` and `never` types
    • type assertions and `as const`

    You can now: You can write a type for a function that accepts either a string or an array of strings, and explain why `unknown` is safer than `any`.

  2. Functions and generics

    weeks 3-4

    You learn how types flow through functions, and how generics let you write functions that work across types without losing information. This stage sits here because generics are the first place most people get stuck, and they need the type language from stage one.

    • function type expressions
    • parameter and return type annotations
    • optional and default parameters
    • rest parameters and tuple types
    • generic functions and type parameters
    • generic constraints with `extends`
    • overload signatures
    • `this` parameters

    You can now: You can write a generic `identity` function that preserves the input type, and a `first` function that returns the first element of an array or `undefined` without using `any`.

  3. Objects, classes, and structural typing

    weeks 5-6

    You learn how TypeScript models objects and classes, and why structural typing means two types can be compatible even if they have different names. This stage sits here because it builds on the function and generic work from stage two.

    • structural typing vs nominal typing
    • excess property checks
    • readonly properties and arrays
    • index signatures
    • classes: fields, constructors, methods
    • inheritance and `implements`
    • access modifiers: public, private, protected
    • abstract classes

    You can now: You can define two interfaces with the same shape but different names, and explain why a value of one type is assignable to the other.

  4. Advanced type manipulation

    weeks 7-8

    You learn the type-level operators that let you transform types the way you transform values. This stage sits here because these tools are only useful once you can already write basic types and generics fluently.

    • keyof operator
    • typeof operator
    • indexed access types
    • conditional types
    • infer keyword
    • mapped types
    • template literal types
    • utility types: Partial, Pick, Omit, Record, Readonly

    You can now: You can write a `MyPartial<T>` type that makes every property of `T` optional, without using the built-in `Partial`.

  5. Modules, declaration files, and configuration

    weeks 9-10

    You learn how TypeScript code is organised across files and how to describe code that was not written in TypeScript. This stage sits here because it requires the type manipulation skills from stage four to write useful declaration files.

    • ES modules and CommonJS interop
    • import and export type syntax
    • declaration files (.d.ts)
    • ambient declarations
    • module augmentation
    • tsconfig.json: strict, target, module, include
    • path mapping and baseUrl
    • triple-slash directives

    You can now: You can write a declaration file for a small JavaScript library that has no types, and configure a tsconfig that compiles it without errors.

  6. Real codebases and error debugging

    weeks 11-12

    You apply everything to real code: reading errors, narrowing types, and working with third-party libraries. This stage sits last because it is where the isolated skills from earlier stages get combined under time pressure.

    • type narrowing with typeof, instanceof, and in
    • discriminated unions
    • type predicates
    • assertion functions
    • working with DefinitelyTyped (@types)
    • common error messages and what they mean
    • strict mode and strictNullChecks
    • migrating a JavaScript file to TypeScript

    You can now: You can take a 200-line JavaScript file, add types to it, and fix every error without using `any` or `@ts-ignore`.

The hours are fixed. The calendar is yours.

The same path at three speeds, and what actually goes wrong at each.

3 hours a week

This pace takes about 24-30 weeks to finish. The main risk is that the type language from weeks 1-2 fades before you reach advanced type manipulation, so you will need to redo early exercises. Progress feels slow because each session starts with re-warming up.

8 hours a week

This pace takes about 9-12 weeks. It is sustainable if you split the time into two or three sessions, because type-level thinking needs sleep between sessions to consolidate. The main risk is skipping the scratch-file exercises in favour of building something, which leaves gaps that show up in stage six.

20 hours a week

This pace takes about 4-5 weeks. It works only if you already have strong JavaScript and some experience with another typed language. The main risk is burnout from the density of type-level concepts, and the fact that error messages start to blur together without rest days.

What goes wrong

Four ways people lose a year on this.

Each of these is appealing for a real reason, which is why they are common. What they cost is the part nobody mentions.

  • Learning TypeScript by building a React app from day one

    People do this because it feels productive and matches how they learned JavaScript. But React's types are complex, and you end up fighting JSX generics and hook typings before you can read a basic union type. The cost is that you learn to copy error messages into Google rather than understanding them, and you never build a mental model of the type system.

  • Using `any` as a temporary escape hatch that becomes permanent

    People do this because `any` silences the compiler and lets them keep moving. It is appealing because it feels like JavaScript with extra steps. The cost is that `any` disables type checking for everything it touches, so the errors you do get are in code you did not write, and you lose the ability to trust the types at all.

  • Treating interfaces and type aliases as interchangeable

    People do this because both can describe object shapes and the differences are subtle. But interfaces can be merged and extended, while type aliases can express unions and mapped types. The cost is that you write types that work in one file but break when you try to extend or compose them, and you cannot explain why.

  • Skipping the error messages and going straight to Stack Overflow

    People do this because TypeScript errors are long and full of type jargon. It is appealing because a search often returns a fix in seconds. The cost is that you never learn to read the structure of an error: which type is expected, which was provided, and where the mismatch originates. You stay dependent on other people's fixes.

How to know it worked.

Not a syllabus you tick off — six things to attempt. If one of them is still hard, the stage it belongs to is the one to go back to.

  1. Write a type for a function that accepts a string or a number and returns a string.
  2. Write a generic function that returns the first element of an array without using any.
  3. Define two interfaces with the same shape and explain why they are assignable.
  4. Write a mapped type that makes all properties of a given type readonly.
  5. Write a declaration file for a small JavaScript function that has no types.
  6. Take a 100-line JavaScript file, add types, and fix every error without any or ts-ignore.
Questions

Questions about learning TypeScript.

The five we hear most. The intro film answers most of them in a minute and a half.

how long does it take to learn typescript

For a JavaScript developer, 70-90 hours of focused practice gets you to genuine working competence: reading most codebases, writing types that survive real APIs, and debugging errors without guessing. That is about 12 weeks at 6 hours a week. If you already know another statically typed language, you can cut that to 40-50 hours.

is typescript worth learning in 2025

Yes, if you work in JavaScript. TypeScript is the default in most new frontend and Node projects, and the type system catches a class of bugs that tests do not. The cost is real: you will spend time fighting the compiler, especially in the first month. But the alternative is discovering type mismatches in production.

do i need to know javascript before typescript

Yes. TypeScript is a superset of JavaScript, and every TypeScript file is also a JavaScript file with extra syntax. If you do not know how functions, objects, and modules work in JavaScript, you will be learning two languages at once. Get comfortable writing JavaScript that runs first, then add types.

is typescript harder than javascript

The first two weeks are harder, because you are learning a second language: the type system. After that, TypeScript is often easier than JavaScript for large codebases, because the compiler catches mistakes before you run the code. The hard part is not the annotations; it is learning to think in types.

can i learn typescript without knowing any other programming language

You can, but it is a bad idea. TypeScript's type system borrows concepts from languages like Java, C#, and Haskell: generics, structural typing, and union types. Without JavaScript first, you will be learning three things at once: programming, JavaScript, and the type system. Learn JavaScript first, then come back.

A path is not a course.

This is the shape of TypeScript, not the teaching of it. Hand the same path to BiliMind and it writes the lessons onto it — in the form each one calls for, with practice that gets marked and a schedule that bends when your week does. Mapping a course is free and unlimited.

This roadmap was drafted on 18 September 2026 by the same engine that builds BiliMind courses, and reviewed before publishing. Hours are honest estimates for working competence, not for a demo — treat them as a starting point and adjust them against your own first fortnight.

The intro · 1:25