TypeScript for JavaScript Developers: Why Every Job Post Wants It Now

What just happened? Why is every job post suddenly screaming TypeScript?#

Open any job portal right now and search 'frontend developer' or 'Node developer'. Almost every listing from a Bangalore startup to a Chennai product company has one line buried in the requirements: 'Experience with TypeScript preferred.' Meanwhile most freshers walking out of college know JavaScript, maybe a bit of React, and that's it. TypeScript feels like one more thing to learn before you even get an interview call.

Here's the actual reason teams insist on it. JavaScript lets you pass anything anywhere — a string where a number was expected, undefined where an object should be. The app doesn't complain until a user clicks something in production and it crashes. TypeScript catches that mistake while you're still typing, in your editor, before it ever ships.

So what is TypeScript actually doing to your JS?#

TypeScript is not a new language that replaces JavaScript. Think of it as JavaScript wearing a seatbelt. You write mostly normal JS syntax, add type annotations where it helps, and a compiler called tsc converts your .ts files into plain .js files that run in any browser or Node server.

Nobody ships .ts files to production. The browser has never heard of TypeScript. It only ever sees the JavaScript that comes out the other end.

How do you even set up tsc and tsconfig?#

You don't need any fancy framework to try this. Three commands and you're compiling TypeScript on your own laptop.

// terminal commands, not TS code
// 1. start a project
npm init -y

// 2. add TypeScript as a dev dependency
npm install --save-dev typescript

// 3. generate a tsconfig.json
npx tsc --init

That last command drops a tsconfig.json full of commented-out options. You mostly need a handful of them. Here's a clean, current, strict config that works for a plain Node or browser project:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "outDir": "dist",
    "rootDir": "src",
    "esModuleInterop": true
  },
  "include": ["src"]
}

Run npx tsc and it reads every file under src, checks the types, and writes plain JavaScript into dist. Keep strict: true on. Turning it off feels easier on day one and costs you a lot more on day ninety.

Basic types and inference — do you really have to label everything?#

No. This is the part freshers overdo the most. TypeScript can often figure out the type on its own, which is called inference. You only add a type when TypeScript can't guess or when you want to be extra clear for whoever reads the code next.

let username: string = "Kavya";
let age = 24; // inferred as number automatically
let isPremium: boolean = false;

function addGST(price: number, rate: number): number {
  return price + (price * rate) / 100;
}

console.log(addGST(999, 18)); // works out the price with GST added

Notice age has no annotation. TypeScript sees 24 and already knows it's a number — try assigning age = "twenty-four" later and it'll shout at you in red before you even save the file.

Interface vs type alias — which one do you actually pick?#

This is the classic interview trick question. Both describe the shape of an object, and for most everyday use they're interchangeable. The differences only matter in specific cases.

interface User {
  id: number;
  name: string;
  email?: string; // the ? means this field is optional
}

type Admin = {
  id: number;
  name: string;
  role: "admin";
};

function greetUser(user: User): string {
  return `Hello, ${user.name}`;
}

const a1: Admin = { id: 1, name: "Ravi", role: "admin" };
console.log(greetUser(a1));

An interface can be extended with another interface, and the same interface name can be declared twice and TypeScript merges them — handy when extending library types. A type alias can describe unions, tuples and primitives that an interface simply cannot. Most teams pick interface for object shapes and type for everything else, including the union types in the next section.

Union types and literal types — what's the actual use case?#

This is where TypeScript stops feeling like extra homework and starts feeling genuinely useful. A union type says 'this value can only ever be one of these exact options' — nothing else is allowed.

type OrderStatus = "pending" | "shipped" | "delivered" | "cancelled";

function trackOrder(status: OrderStatus): string {
  if (status === "delivered") {
    return "Your order has reached you.";
  }
  return `Order is currently: ${status}`;
}

let paymentMode: "UPI" | "CARD" | "COD" = "UPI";
// paymentMode = "CASH"; // TypeScript will reject this instantly

Picture an e-commerce checkout screen choosing between UPI, card and cash on delivery. Without a union type, someone could accidentally pass "upi" lowercase, or "NETBANKING" that the backend never expected, and it would slip through until a real customer hit it. The union type closes that door at compile time.

How do you migrate one JS file without setting the whole project on fire?#

You don't need to convert everything in one sitting. Pick the one file that breaks the most, usually something like cart or checkout logic, and start there.

// before: cart.js — plain JavaScript, no safety net
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

// after: cart.ts — same logic, now typed
interface CartItem {
  name: string;
  price: number;
  quantity: number;
}

function calculateTotal(items: Array<CartItem>): number {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

Just rename cart.js to cart.ts, let tsc complain, and fix the red squiggles one by one. For a bigger codebase, turn on allowJs: true and checkJs: true in tsconfig so plain .js files get loosely type-checked while you migrate file by file over weeks, not in one risky deploy.

Where does this actually show up in Indian companies and interviews?#

Product companies like Zoho, Freshworks and the engineering teams inside Flipkart and Swiggy run large React and Node codebases, and almost all of them have moved to TypeScript for anything customer-facing. Service companies like TCS, Infosys and Wipro now staff Angular projects — which has used TypeScript from day one — for banking and insurance clients abroad. In interviews, expect 'what's the difference between interface and type', 'what does strict mode catch that plain JS doesn't', and a small live-coding round where they hand you an untyped function and ask you to type it correctly.

What mistakes do most beginners make with this?#

Typing everything as any just to make the red lines disappear — that defeats the entire purpose, you've just written JavaScript with extra keystrokes. Turning off strict mode in tsconfig because it feels noisy at first. Confusing an interface's optional ? field with a required one and wondering why production breaks when the field is missing. And trying to convert an entire 200-file project to TypeScript in one go instead of one file at a time.

What should you do now?#

Install TypeScript locally today, run npx tsc --init, and take one small .js file from an old project of yours. Add an interface for its main data shape, add a union type for any status or mode variable, and compile it. That's the exact muscle memory interviewers are testing for.

Practice task: take a plain JavaScript function that processes a list of student marks (name, subject, score) and rewrite it in TypeScript with a proper interface for a student record and a union type for a grade field restricted to "A" | "B" | "C" | "F". Make it compile with zero errors under strict mode.