TypeScript Is the Default Now, Not a Nice to Have

Every project I picked up this year already had TypeScript set up before I wrote a line. Nobody asked whether we should use it. That debate is over. It went from something you argue for in a kickoff meeting to something that is just there, like Git.

I work remote for an agency, mostly React and Next.js, for fintech, AI, and ecommerce clients. Different teams, same rule. If it ships to real users, it is typed. Plain JavaScript now feels like a rough draft, not a product.

Why it stopped being optional

It is less about the language and more about what teams expect from each other. Open a typed codebase and every function tells you what it wants and what it gives back, so you get moving in hours. Open an untyped one and you are reading the whole call stack, guessing. Job posts assume it. Libraries ship it. Fighting that current is just not worth it anymore.

It is more than adding types now

For years people wrote TypeScript like JavaScript with a few labels on top. any everywhere, loose settings, types that were close enough. That catches typos and not much else.

The teams doing it well turn strict on and let it do real work. The point is not to please the linter. It is to make the wrong code refuse to compile.

Three habits worth picking up

Brand your IDs so you cannot swap them

Your app has a bunch of string IDs. userId, orderId, and so on. To TypeScript they are all just string, so nothing stops you from passing the wrong one. On a fintech app, that is a bug you really do not want.

type UserId = string & { readonly tag: "UserId" };
type OrderId = string & { readonly tag: "OrderId" };

function getUser(id: UserId) { /* ... */ }

const orderId = "ord_123" as OrderId;
getUser(orderId); // error: an OrderId is not a UserId

At runtime it is still a normal string, so this costs nothing. But swapping two IDs is now a red squiggle in your editor instead of a late night incident.

Use satisfies to check a value without dumbing it down

satisfies checks that a value fits a type while keeping the exact value you wrote. Before it existed you had to pick one or the other.

type Route = { path: string; auth: boolean };

const routes = {
  home: { path: "/", auth: false },
  dashboard: { path: "/dashboard", auth: true },
} satisfies Record<string, Route>;

// a typo in any path is caught right here,
// and routes.home stays exact for autocomplete

You get the shape check and you keep full autocomplete on the real keys. Small feature, a lot fewer papercuts.

Turn on noUncheckedIndexedAccess

By default TypeScript trusts array access too much. arr[0] is typed as if it always exists, even when the array is empty. That is where a lot of undefined is not a function comes from.

// tsconfig: "noUncheckedIndexedAccess": true

const first = users[0]; // User | undefined, not User

if (first) {
  // safe to use here
}

Turn it on and the compiler makes you handle the empty case. Annoying for a day, then it just quietly saves you.

Why teams care

The solo wins are nice. The team wins are the real reason this took over. Types are documentation that cannot go out of date. The signature tells the next person what to pass, and it is checked on every build, so it never lies the way a stale comment does. Change one core type and the compiler lists every spot that breaks, which turns a scary refactor into a boring one.

Starting from plain JavaScript

Still on a JS codebase with no free weekend to convert it? You do not need one. Turn on allowJs so JS and TS files can live together. Convert the busiest files first. Move toward strict in steps, noImplicitAny before the rest. Every new file is TypeScript from today, and the old ones get converted whenever you happen to touch them. Give it a few months and the leftover JavaScript barely registers.

Where I land

TypeScript does not make you a better developer, and strict mode is not a personality. What it gives you is boring, and boring is the whole point. I would rather spend my head on the hard parts of a product than on wondering whether some variable might be undefined. The compiler is happy to hold that for me.

The real question in 2026 is not whether to use it. It is how strict you are willing to go. Every year I go a little stricter, and I have never missed the old way.