DEV Community

RamKashyap
RamKashyap

Posted on

TypeScript in 15 Minutes for JavaScript Developers Who Hate TypeScript

TypeScript isn’t a “new JavaScript.”
It’s JavaScript with intent, discipline, and receipts.

At its core, TypeScript is just JavaScript plus types and generics — nothing more, nothing magical. It doesn’t add new runtime behavior. It just makes sure you don’t lie to yourself (or your teammates) while writing code.

If you already know JavaScript, this is the fastest way to understand what actually matters in TypeScript.

JavaScript vs TypeScript: The Truth About Types

Let’s get this out of the way first:

TypeScript does NOT introduce new primitive data types.

Everything you already know still exists:

  • string
  • number
  • boolean
  • null
  • undefined
  • symbol
  • bigint

TypeScript’s job is not invention — it’s enforcement.

JavaScript says:

“You’ll figure it out at runtime.”

TypeScript says:

“Prove it before you run it.”

Methods Are the Same — Safety Is Not

All your familiar methods still exist:

  • Strings → concat, slice, charAt
  • Arrays → map, filter, reduce, find

The difference is TypeScript knows what you’re allowed to call.

let nums: number[] = [1, 2, 3];
nums.map(n => n * 2);      // Executes well
nums.map(n => n.toUpperCase()); // caught immediately
Enter fullscreen mode Exit fullscreen mode

JavaScript would let that fail at runtime.
TypeScript kills it at compile time.

That’s the entire value proposition.

Type Annotations vs Type Inference

Yes, you can write this:

let name: string = "Ram";

But TypeScript is smarter than that.

let name = "Ram"; // inferred as string

TypeScript tracks types automatically.
This is called type inference, and it’s why declaring variables in one place and mutating them elsewhere is usually a bad idea.

The Any Trap (Don’t Do This)

A lot of people use any to “escape” TypeScript.

That defeats the purpose.

let value: any = 10;
value.toUpperCase(); // TS allows it, runtime explodes
Enter fullscreen mode Exit fullscreen mode

That’s why noImplicitAny exists in tsconfig.json.

If you’re using any everywhere, you’re just writing JavaScript with extra steps.

Functions: Parameters AND Returns Matter

TypeScript isn’t just about inputs — outputs matter too.

function addTwo(num: number): number {
  return num + 2;
}
Enter fullscreen mode Exit fullscreen mode

Without the return type, this would still compile:

return "hello";

Enter fullscreen mode Exit fullscreen mode

TypeScript lets you lock both sides of the contract.

Special cases:

  • void → function performs side effects
  • never → function never returns (throws or crashes)
function handleError(msg: string): void {
  console.log(msg);
}

function crash(msg: string): never {
  throw new Error(msg);
}

Enter fullscreen mode Exit fullscreen mode

Why Return Types Matter in Teams

This function tells a story without reading the body:

function getCourse(): { title: string; price: number } {
  return { title: "TypeScript Mastery", price: 499 };
}


Enter fullscreen mode Exit fullscreen mode

Anyone can tell:

  • What it returns
  • The exact structure
  • What’s mandatory

That’s not syntax.
That’s team communication.

Type Aliases: Naming Shapes

Type aliases let you name intent.

type User = {
  name: string;
  email: string;
  isActive: boolean;
};

Enter fullscreen mode Exit fullscreen mode

JavaScript says “trust me.”
TypeScript says “prove it.”

Readonly, Optional, and Unions

Readonly
readonly _id: string;

You can read it. You can’t mutate it.

Optional
creditCard?: number;

Might exist. Might not. TS forces you to check.

Unions
let id: number | string;

Used heavily in:

  • RBAC
  • APIs
  • Conditional flows ## Tuples: Controlled Chaos

Tuples are ordered, typed arrays:

let user: [string, number, boolean];

They exist only in TypeScript — compiled JS doesn’t care.

Yes, push() still works.
Yes, it’s weird.
Use them only when order truly matters.

Enums: Named Constants

const enum SeatChoice {
  aisle = 10,
  middle,
  window
}

Enter fullscreen mode Exit fullscreen mode

Readable. Predictable. Zero runtime ambiguity.

Interfaces vs Types (Short Version)

Interfaces:

  • Are extendable
  • Work beautifully with classes
  • Enforce OOP contracts
interface IUser {
  email: string;
  startTrial(): string;
}

Enter fullscreen mode Exit fullscreen mode

Interfaces can be reopened. Types cannot.

Classes, Constructors, and Access Modifiers

TypeScript makes OOP less painful.

class User {
  constructor(
    public email: string,
    public name: string,
    private userId: string
  ) {}
}
Enter fullscreen mode Exit fullscreen mode

Access modifiers:

  • public → everywhere
  • private → class only
  • protected → class + children

This is how you stop access chaos in real systems.

Interfaces + Classes = Structural Integrity

Interfaces define what must exist.

interface TakePhoto {
  cameraMode: string;
  filter: string;
}

Enter fullscreen mode Exit fullscreen mode

Classes implement behavior.

This pattern scales incredibly well in backend systems.

Abstract Classes: Intent Without Instantiation

Abstract classes define what must happen, not how.

abstract class TakePhoto {
  abstract getSepia(): void;
}


Enter fullscreen mode Exit fullscreen mode

You can’t create instances.
You must implement required behavior.

Generics: The Real Power Move

Generics let you write logic once — safely.

function identity<T>(val: T): T {
  return val;
}

Enter fullscreen mode Exit fullscreen mode

Used everywhere in:

  • APIs
  • Repositories
  • Response wrappers

They’re not OOP replacement — they’re evolution.

Type Narrowing: Runtime Safety

TypeScript doesn’t guess — you narrow types explicitly.

  • typeof
  • instanceof
  • in operator

This is how TS stays correct at runtime without reflection.

Discriminated unions


Discriminated Unions (Cleanest Pattern)
interface CreditCard {
  paymentType: "card";
}

interface PayPal {
  paymentType: "paypal";
}

Enter fullscreen mode Exit fullscreen mode

One field.
Zero ambiguity.
Perfect switch logic.

Conclusion

TypeScript doesn’t slow you down.

Unclear code does.
TypeScript just makes ambiguity illegal.

Top comments (0)