Should I learn TypeScript or stick with JavaScript for my next project?

General
1

I’m starting a new web app and I’m torn between using plain JavaScript or committing to TypeScript. I’ve mostly worked with JavaScript so far, but I keep hearing that TypeScript is better for large, scalable codebases and catching bugs early. I’m worried about the learning curve, setup overhead, and whether it’s really worth it for a small team. Can anyone explain the real-world pros and cons of TypeScript vs JavaScript for modern frontend and backend development, and share when you’d choose one over the other?

2

Go TypeScript for the new app, unless your deadline is on fire.

Short version:
• New project, greenfield: pick TS.
• Tiny throwaway script, quick PoC: JS is fine.

Some practical points:

  1. Learning curve
    If you know JS, TS feels weird for a week or two, then it clicks.
    You write the same JS, add types slowly.
    Start with:
  • ‘strict’: false
  • noImplicitAny: false
    Then turn strict stuff on later.
    Do not try to go full enterprise types on day one. You will hate it.
  1. Daily dev experience
    The wins are in your editor:
  • Auto complete is better.
  • You catch property name typos before run time.
  • You refactor without fear.

Example:

  • In JS, you rename a field and miss one spot, bug shows in prod.
  • In TS, the compiler screams at every place you forgot.
  1. Team and scale
    If this app will:
  • last more than a few months
  • have more than 1 or 2 devs
  • touch external APIs or a lot of shared utilities
    TS pays off.
    Types become living docs for your own code.
    New devs onboard faster, less “what does this function expect” guessing.
  1. Interop with JS
    You do not need to convert everything.
    You can:
  • Start with TS config.
  • Rename files from .js to .ts slowly.
  • Use any when you do not want to fight types.
  • Keep some files as .js if they are annoying to type.

  1. Libraries and ecosystem
    Most big libs already ship types.
    React, Vue, Node stuff, etc.
    For older libs, DefinitelyTyped has @types packages.
    You install:
    npm install -D typescript @types/node
    npm install -D @types/whatever-lib

  2. When I would stick to JS

  • Quick one page widget.
  • Script you write once and throw away.
  • Hackathon where setup time hurts more than runtime bugs.
  1. Migration tip if you go TS
  • Add TS and a basic tsconfig.
  • Set ‘allowJs’: true so JS still works.
  • Start new code in TS files.
  • Gradually type shared utils and core models.

My experience:
Every JS project that survived longer than 6 months ended up with “type comments” and defensive checks everywhere.
Every TS project had more up front friction, fewer random runtime errors, safer refactors.
If this web app matters to you beyond a quick test, pick TypeScript and ease into it.

3

If this app is anything more than a weekend toy, lean TS… but how you lean into it matters more than the yes/no decision.

@codecrafter already made the “TS is great for greenfield” case, so I’ll poke at the edges a bit instead of repeating it.

Where TS actually saves your butt

Not in “no bugs ever,” but in these spots:

  • Changing a data shape that’s used in 20 files
  • Calling backend APIs that sometimes return null or missing fields
  • Reusing complex objects between frontend & backend
  • Big refactors when you forgot what you wrote 3 months ago

In JS, all of those are “run it and pray.”
In TS, they turn into “compiler yells, you fix, then run.”

Where TS is overkill (yes, really)

Stuff I’d still do in plain JS:

  • A small internal dashboard only you touch
  • A single script that munges some data once
  • A prototype where the idea is uncertain and might be thrown away

People rarely admit it, but sometimes types are just ceremony that slows you down when the code will be deleted in 2 weeks.

One thing I disagree with a bit

@codecrafter suggested starting with strict: false. That works, but in practice I’ve seen that become “we’ll turn strict on later” which translates to “never.”

Alternative:

  • Keep strict: true
  • But aggressively use any or unknown where you don’t want to fight the compiler yet

That way you still get guardrails in the parts you do type, without pretending the whole codebase is safe.

How I’d decide for your specific web app

Ask yourself honestly:

  1. Will this live longer than 3 months?
  2. Will more than one person ever touch it?
  3. Will you have a real backend or lots of 3rd party APIs?
  4. Will you refactor it a few times as you learn what users actually want?

If you answer “yes” to at least 2 of those, TS is worth the initial friction.

If you answer “no” to most of those, just ship it in JS, maybe with JSDoc types and a good linter. That actually gets you like 40–60% of the day to day benefit without a “TypeScript project” at all.

Concrete path that isn’t painful

Minimal TS setup that doesn’t turn into a yak shave:

  1. Keep your bundler / framework defaults (Vite, Next, etc. all like TS anyway).
  2. Start only new code in .ts / .tsx. Old code can stay JS forever if you want.
  3. Type:
    • Data models
    • API responses/requests
    • Utility functions used everywhere

Leave UI glue and trivial stuff loosely typed or with any at first.

Brutal summary

  • If this app matters, is client facing, or you want to grow it: go TypeScript.
  • If it’s a quick experiment or internal one off: stick with JavaScript and don’t feel guilty.
  • If you like learning and want your future self to suffer less: TS.
  • If you’re on a scary deadline and fighting build tools sounds like hell: JS for now.

Whichever you choose, committing and shipping something matters way more than picking the “perfect” language flavor.

4

If this is a real web app you’ll maintain, I’d lean TypeScript, but I’d frame the decision differently from @espritlibre and @codecrafter: focus on how stable your domain is rather than just project size or lifespan.

Think in terms of “domain churn”

Ask yourself:

  • Is your data model fairly clear already (users, projects, invoices, whatever) and unlikely to radically change every week?
    • If yes, TypeScript will shine because those models become a strong backbone.
  • Are you still in the “I don’t even know what the app is yet” phase where data shapes, flows and boundaries change daily?
    • In that case, strict typing can feel like concrete that has not set in the right shape yet.

So:

  • Stable or soon-to-be-stable domain: TS is a strong win.
  • Very exploratory, idea might pivot hard: Start JS, maybe with JSDoc types, and add TS later.

Where I partially disagree with them

Both highlighted “greenfield ⇒ choose TS,” which is often right, but greenfield plus high uncertainty can be painful with types. If your core question is “does this product idea even make sense,” optimizing for refactors and long term safety is less important than raw iteration speed.

In those first 1–2 weeks, I sometimes:

  • Start in JS with a good linter and JSDoc annotations for key functions.
  • Once the main flows feel real, introduce TypeScript and formalize the models you already discovered.

This avoids burning time typing things you will delete.

How to make TypeScript specifically pay off in a web app

If you do choose TS, spend your effort in places with real leverage rather than typing everything:

  1. API contracts

    • Define request/response types for your backend.
    • Reuse them on both client and server if possible.
    • This cuts a ton of “undefined is not a function” style bugs.

  2. Core entities

    • User, Project, Invoice, whatever your app revolves around.
    • Give those strong types, and let leaf UI components be sloppier at first.

  3. Shared utilities

    • Date helpers, formatting, validation, permissions checks.
    • Typed utils pay you back every single time you reuse them.

Leave:

  • Small UI event handlers
  • One-off glue code

with loose typing or any early on. Over-typing these just adds ceremony.

When JS is actually the better pick

Situations where I would consciously avoid TS even for a “web app”:

  • You have a brutal deadline in days, not weeks, and no TS experience.
  • The app is essentially a complex form that hits one or two APIs and will not grow.
  • You are using a framework config that makes TS setup nontrivial and you do not have time to fight tooling today.

In those cases, JS + ESLint + maybe JSDoc types gives you a decent safety net without workflow shock.

About @espritlibre and @codecrafter’s angles

  • @codecrafter’s “TS for greenfield” is solid, especially with modern stacks that auto-configure TS.
  • @espritlibre’s emphasis on where TS saves you (refactors, shared models, API contracts) is exactly where it shines.

Where I’d sharpen it:

  • Instead of toggling strict globally (on or off), decide per layer of the app how strict you want to be. You can keep strict mode on, but isolate uncertainty in a few “unsafe” modules and keep the rest tight.

If you are still torn

A very practical compromise:

  • Start the repo as a TypeScript project from day one.
  • Use .ts / .tsx for files that touch your data models or APIs.
  • Allow some .js files for quick experiment code, prototypes and UI glue.
  • Gradually convert the JS bits that prove stable.

That way you are not choosing “TS or JS forever,” you are choosing where strong typing matters most in this particular app.