TypeScript for People Who Just Learned JavaScript

JavaScript does not care what type a variable is. You can write let x = 5, then later write x = "hello", and JavaScript will not complain. That flexibility is nice when you are starting out, but it causes real problems in larger codebases. You pass a string to a function that expects a number, and instead of an error, you get a silent bug that produces wrong results.

TypeScript adds a type system. You tell the compiler what type each variable, function parameter, and return value should be. If you try to use them incorrectly, TypeScript highlights the error in your editor immediately, before you even run the code.

// JavaScript - no type checking
function greet(name) {
  return "Hello, " + name;
}
greet(42); // No error, but probably not what you wanted

// TypeScript - the error shows up instantly
function greet(name: string): string {
  return "Hello, " + name;
}
greet(42); // Error: Argument of type 'number' is not
           // assignable to parameter of type 'string'

That is the core idea. TypeScript does not change how JavaScript works at runtime. Your TypeScript code gets compiled down to regular JavaScript before it runs in the browser or on a server. The types are only for development. They help you write correct code, and then they disappear.

The practical effect is that your code editor becomes much smarter. Autocomplete suggestions become accurate because the editor knows what type each variable is. Function signatures show you exactly what arguments are expected. Refactoring becomes safer because the compiler tells you everywhere that needs to change. For a solo developer, these are nice conveniences. For a team, they are essential.

One thing that surprises beginners: TypeScript can also infer types without you writing them explicitly. If you write const age = 26, TypeScript knows age is a number. You only need to write type annotations where TypeScript cannot figure it out on its own, like function parameters. This means you are not drowning in type syntax everywhere. You add it where it matters and TypeScript handles the rest.

The answer depends on where you are with JavaScript. TypeScript adds a layer of abstraction on top of JavaScript, and if your JavaScript foundation is shaky, that extra layer creates confusion instead of clarity.

You are ready for TypeScript if you can comfortably:

• Declare and use variables, functions, and objects without looking up syntax
• Work with arrays and array methods (map, filter, find, reduce)
• Understand callbacks and promises
• Use async/await to make API calls
• Build a small project (to-do app, API integration) without following a tutorial step by step

Wait on TypeScript if:

• You are still learning what functions are and how to use them
• Async code feels completely mysterious
• You cannot build anything without copying from a tutorial
• You have not built at least one or two projects with plain JavaScript

For most learners, this means starting TypeScript after two to four months of active JavaScript practice. Not "I watched two months of tutorials" but "I spent two months writing JavaScript code and building things." The distinction matters because TypeScript solves problems you have not experienced yet if you have not written enough JavaScript to encounter them.

The frustrating-but-true reality is that you need to have been bitten by JavaScript's looseness before TypeScript's strictness feels helpful. If you have never had a bug caused by passing the wrong type to a function, you will wonder why TypeScript is making you write extra syntax. If you have spent 45 minutes debugging a Cannot read property of undefined error that TypeScript would have caught in 2 seconds, you will welcome the extra syntax.

That said, you do not need to master JavaScript before learning TypeScript. You do not need to know every array method, understand prototypal inheritance deeply, or be an expert in closures. You need a solid working knowledge. If you can build a React app that fetches data from an API and displays it, you are ready.

TypeScript has many types, but a small handful covers the vast majority of real-world code. Here are the ones you will use from day one, with plain explanations.

Primitive types (the building blocks):

let name: string = "Kiptoo";     // text
let age: number = 26;            // any number (integer or decimal)
let isActive: boolean = true;    // true or false, nothing else

These three cover most variables you will ever declare. String for text, number for numbers (TypeScript does not distinguish between integers and decimals like some languages), boolean for yes/no values.

Arrays (lists of things):

let scores: number[] = [85, 92, 78];
let names: string[] = ["Amara", "Emeka", "Kiptoo"];
let flags: boolean[] = [true, false, true];

Put the type followed by []. A number[] is a list that can only contain numbers. Try to push a string into it and TypeScript will stop you.

Objects (using interfaces):

interface User {
  name: string;
  email: string;
  age: number;
  isAdmin?: boolean; // the ? means this property is optional
}

const user: User = {
  name: "Amara",
  email: "amara@email.com",
  age: 29,
};
// isAdmin is optional, so leaving it out is fine

Interfaces are how you describe the shape of an object. Once you define a User interface, any object claiming to be a User must have exactly those properties with exactly those types. This is where TypeScript really shines. In a large codebase, interfaces are the contract that keeps everyone on the same page about what data looks like.

Function parameters and return types:

function add(a: number, b: number): number {
  return a + b;
}

function greet(name: string): void {
  console.log("Hello, " + name);
  // void means the function does not return anything
}

// Arrow function syntax works the same way
const multiply = (x: number, y: number): number => x * y;

Union types (a value that can be more than one type):

let id: string | number = "abc123";
id = 42; // also valid

function formatPrice(price: number | string): string {
  if (typeof price === "number") {
    return "KES " + price.toFixed(2);
  }
  return price; // already a string
}

The pipe character (|) means "or." A string | number can be either a string or a number. TypeScript will require you to check which type it is before using type-specific methods. This is called type narrowing, and it makes your code safer.

These five patterns (primitives, arrays, interfaces, function types, and unions) will carry you through the first several months of TypeScript. There are more advanced features, but you will learn those naturally as your projects demand them.

If you learned React with JavaScript, adding TypeScript changes a few things in your daily code. The biggest one is typing your component props.

Before (plain JavaScript React):

function UserCard({ name, age, isOnline }) {
  return (
    <div>
      <h2>{name}</h2>
      <p>Age: {age}</p>
      {isOnline && <span>Online</span>}
    </div>
  );
}

After (TypeScript React):

interface UserCardProps {
  name: string;
  age: number;
  isOnline?: boolean;
}

function UserCard({ name, age, isOnline }: UserCardProps) {
  return (
    <div>
      <h2>{name}</h2>
      <p>Age: {age}</p>
      {isOnline && <span>Online</span>}
    </div>
  );
}

The component logic is identical. The only addition is the UserCardProps interface that describes what props the component accepts. Now if you use <UserCard name={42} /> somewhere, TypeScript will immediately tell you that name should be a string, not a number. And it will tell you that age is missing.

Typing useState:

const [count, setCount] = useState(0);
// TypeScript infers count is a number

const [user, setUser] = useState<User | null>(null);
// Explicitly tell TypeScript: user is either a User object or null

When the initial value makes the type obvious (like 0 for a number), TypeScript figures it out. When the initial value is null but you know it will eventually hold a User object, you use the angle bracket syntax to specify the type explicitly.

Typing event handlers:

function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
  console.log(e.target.value);
}

function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
  e.preventDefault();
  // handle form submission
}

Event types look intimidating at first. The good news is that VS Code will tell you the correct type if you hover over the event parameter. You do not need to memorize them. You learn the common ones (ChangeEvent, FormEvent, MouseEvent) through repetition.

If TypeScript is "just JavaScript with extra syntax," why do companies care so much? The answer comes down to scale and collaboration.

When you are working on a solo project with 500 lines of code, JavaScript is fine. You wrote all the code. You know what every variable is. You know what every function expects. But when you are on a team of five developers working on a codebase with 50,000 lines, nobody knows what every variable is. TypeScript becomes the shared contract that keeps everyone aligned.

When you write a function with TypeScript, the type signature tells every other developer exactly what the function expects and what it returns. They do not need to read the implementation. They do not need to ask you on Slack. The types document the code automatically. This saves an enormous amount of time in code reviews, onboarding new team members, and refactoring.

Companies also care about TypeScript because it prevents entire categories of bugs from reaching production. A TypeError that would crash your app in front of users gets caught in the editor during development. Over time, this adds up to fewer bugs, less time spent debugging, and more reliable software. That translates directly into money saved.

From a practical job-search perspective, look at any job listing for a frontend or full-stack developer role. The majority now list TypeScript as either required or strongly preferred. Some companies have migrated their entire codebase from JavaScript to TypeScript. Others start every new project in TypeScript by default. Not knowing TypeScript limits your options significantly.

This does not mean JavaScript skills are useless. TypeScript is JavaScript. Everything you learned in JavaScript applies directly. But the job market has clearly moved toward TypeScript as the expected standard for professional development. The question is no longer "should I learn TypeScript?" It is "when should I learn TypeScript?" And the answer is: as soon as your JavaScript is solid enough.

You do not need a complex setup to start using TypeScript. Here are the fastest paths, from easiest to most involved.

Option 1: The TypeScript Playground (zero setup). Go to typescriptlang.org/play. It is an online editor where you can write TypeScript, see the compiled JavaScript output, and experiment without installing anything. This is great for learning syntax and testing concepts quickly. Start here if you want to try TypeScript in the next 30 seconds.

Option 2: Create a new Vite project with TypeScript. If you are using Vite (which is the modern way to start a React project), TypeScript support is built in. Run:

npm create vite@latest my-app -- --template react-ts

This creates a React project with TypeScript already configured. Your files use .tsx instead of .jsx, and TypeScript just works. No extra setup.

Option 3: Add TypeScript to an existing project.

npm install --save-dev typescript
npx tsc --init

This creates a tsconfig.json file. Rename your .js files to .ts (or .jsx to .tsx) one at a time and start adding types. You do not need to convert your entire project at once. TypeScript is designed to be adopted gradually.

The best learning approach: Take a small project you already built in JavaScript and convert it to TypeScript. You understand the code already, so you can focus entirely on learning the type syntax. Start with the simplest files first. Add type annotations to function parameters. Create interfaces for your data shapes. Let the TypeScript compiler guide you. The errors it shows you are educational: each one teaches you something about how types work.

VS Code has excellent TypeScript support built in. You get type errors highlighted in red as you type, autocomplete based on your type definitions, and hover-over documentation for every function and variable. The editor experience alone makes TypeScript worth learning.

Every TypeScript beginner hits the same walls. Knowing they are coming makes them less discouraging.

"I am fighting the type system more than writing code." This is normal for the first week or two. You are used to JavaScript's flexibility, and TypeScript keeps telling you "no." The frustration is real, but it fades quickly. Once you internalize the common patterns (typing function parameters, defining interfaces for objects, handling nullable values), the type system starts feeling helpful instead of restrictive. Push through the first week. It gets dramatically better.

"I do not understand generics." Do not worry about generics yet. You will use them eventually (they are what make functions like Array.map and useState work with any type), but you do not need to write your own generics for months. Use the built-in generic types, understand them at a surface level, and save the deep dive for later.

"TypeScript errors are long and confusing." They can be. When you get a type error that spans five lines, focus on the first line. It usually contains the core message. The rest is context about which types were expected versus what was provided. With practice, you learn to read these quickly. Some VS Code extensions also simplify TypeScript error messages into more readable formats.

"The any type keeps tempting me." any disables type checking for a value. It is the escape hatch when you do not know what type to use. Using it sparingly is fine, especially when you are learning. But relying on it heavily defeats the purpose of TypeScript. When you catch yourself reaching for any, try to figure out the actual type first. If you genuinely cannot, use any and come back to fix it later. That is better than being stuck for an hour.

"I do not know whether to use type or interface." For objects, use interface. For everything else (unions, primitives, function types), use type. This is a simplification, and experienced developers will have more nuanced opinions, but it is a perfectly good rule for your first year of TypeScript.

If you want a structured path that integrates TypeScript with real project building, the McTaba Full-Stack Software & AI Engineering program (KES 120,000) teaches TypeScript as part of the full-stack curriculum. You learn it in context, building real applications, which is faster than studying types in isolation. Or start with a free McTaba Academy account to preview the material.