Should I stick with JavaScript or switch my project to TypeScript?

General
1

I’m rebuilding a medium‑sized web app that started in plain JavaScript, and the codebase is getting hard to maintain as new features and devs are added. I’m considering migrating to TypeScript for better type safety and tooling, but I’m worried about the learning curve, migration effort, and build complexity. Can anyone share real‑world pros and cons, performance impacts, and whether a gradual migration strategy from JavaScript to TypeScript is worth it for long‑term maintainability and team productivity?

2

Short answer for a medium sized app with multiple devs: move to TypeScript, but do it gradually and with a plan.

Some practical points:

  1. Why switch
  • Types catch bugs early. In big JS apps, a lot of time goes into “why is this undefined” or “what shape is this object”. TS pushes those mistakes into compile time.
  • On teams, types serve as living docs. A function signature in TS tells new devs what to pass and what they get back.
  • Refactors get safer. Rename or change a return type and the compiler tells you every broken spot.
  1. Cost and tradeoffs
  • There is an upfront learning curve, especially with generics and strict mode. Your team might resist at first.
  • Build step gets slower, though with proper config and incremental builds it stays fine for most medium apps.
  • Some libraries have weak or outdated type defs. You sometimes end up writing your own d.ts or using any as an escape hatch.
  1. Migration strategy that usually works
    Do not rewrite everything.

  • Step 1: Add TypeScript tooling

    • Install TypeScript, ts-node (if needed), and ts-jest or similar if you use Jest.
    • Add a tsconfig.json with relaxed settings first. Example flags to start:
      ‘strict’: false
      ‘allowJs’: true
      ‘checkJs’: true
      ‘noImplicitAny’: false

  • Step 2: Gradual adoption

    • Keep your current JS working.
    • Start by adding JSDoc types in existing JS files. TS understands those when checkJs is true. That gives some type checking without renaming files yet.
    • Convert files one by one to .ts or .tsx as you touch them for new features or bug fixes.
    • Focus first on core domain logic, shared utils, API clients, and data models. These give most benefit.

  • Step 3: Tighten types over time

    • Once a good chunk of the app uses TS, turn on stricter options in tsconfig:
      ‘strict’: true
      ‘noImplicitAny’: true
      ‘strictNullChecks’: true
    • Fix warnings slowly, file by file, PR by PR.
  1. Tooling choices
  • Use ESLint with typescript-eslint so style and types stay aligned.
  • Use an editor with strong TS support like VS Code. Devs get autocomplete and fast feedback, which offsets the “TS feels slow” complaint.
  1. When JS might be fine
  • If your app were tiny or had only one dev, plain JS with some JSDoc and ESLint would be enough.
  • If your team hates types and never writes them, TS turns into anyScript, and you lose most of the benefit. So it helps if at least one dev champions patterns and reviews.
  1. Rough ROI
    From personal experience on teams of 3 to 8 devs, TS reduces runtime type errors noticeably once you cover the main code paths. You trade some time up front for fewer bugs and easier refactors later. The payoff shows when you start adding bigger features or changing core models without fear.

Given your app is already “hard to maintain” and more devs keep joining, staying on plain JS will keep raising maintenance cost. A staged TS migration, starting with tooling and JSDoc, then selective .ts conversions, is a safe move that improves the situation without a risky rewrite.

3

Switch. For your situation, JS is just going to keep hurting more over time.

I agree with most of what @viajeroceleste said about gradual migration, but I’d add a few angles they didn’t focus on as much:

  1. Think in terms of risk areas, not just “files”
    Instead of converting stuff you “happen to touch,” identify the places where bugs are most expensive:

    • Data models / DTOs between frontend and backend
    • State management (Redux, Zustand, whatever)
    • Shared utilities used across the app

    Type those first, even if they are slightly annoying to convert. That’s where TypeScript pays rent fastest.

  2. Define your external boundaries early
    One big TS win is correctly typing:

    • API responses (generate types from OpenAPI / Swagger if you have it)
    • Env variables
    • Feature flags and config objects

    Once those edges are typed, your internal code gets way more reliable. I’d honestly prioritize this over sprinkling types all over tiny helper functions.

  3. Be opinionated about how types are used
    This is where I slightly disagree with the “just start loose and tighten later” idea. If you stay too lax for too long:

    • People keep adding any
    • The codebase becomes an inconsistent mess of typed and untyped zones
    • Everyone says “TypeScript didn’t help that much”

    I’d still start with allowJs: true, but:

    • Ban plain any in new or migrated code through ESLint
    • Have a convention: // TODO: tighten types comments with a ticket if you must use any
    • Require types for function boundaries in newly created TS files, even if internals are still sloppy

  4. Plan for your future hires
    With multiple devs and a growing app, TS becomes a communication tool as much as a safety net:

    • New devs will understand your domain model from types instead of reverse engineering objects
    • Senior devs can encode invariants in the type system so junior devs do not accidentally break stuff

    Plain JS plus docs cannot really compete there long term. People forget to update docs, the compiler never forgets.

  5. Decide how strict your “DX tax” can be
    There is a real cost:

    • Slightly slower builds and test runs
    • More friction when “just hacking something real quick”
    • Occasional rabbit holes with generics and libs with bad types

    The tradeoff is:

    • Fewer “why is this undefined” Slack threads
    • Less fear around refactors
    • Autocomplete that actually helps instead of guessing

    For a medium sized app with multiple devs, that trade is usually very positive, assuming at least one person on the team is willing to own the TS conventions.

  6. When not to go all in
    Sticking with JS might still be reasonable if:

    • You are doing a full rewrite soon anyway and this codebase is temporary
    • Most of your complexity lives in the backend and the frontend is basically a thin UI shell
    • Your team is already using very disciplined JSDoc typing plus strong ESLint rules and they actually follow them

    But given you said “hard to maintain as new features and devs are added,” that sounds like exactly the scenario where JS entropy accelerates.

If you want a simple decision rule:

  • Medium sized app
  • Multiple devs
  • Maintenance pain already visible

That is pretty much the perfect use case for TypeScript, as long as you treat it as a long term investment and not a one sprint “migration project.”

4

Short version: yes, move to TypeScript, but the how matters more than the yes/no.

Let me focus on angles that @byteguru and @viajeroceleste only brushed:

1. Decide what “success” with TypeScript means for your team

Before adding configs and flags, answer these concretely:

  • Do you want:
    • Fewer runtime type bugs?
    • Faster onboarding for new devs?
    • Safer refactors?
    • Better editor support and autocomplete?

Pick 1 or 2 as primary goals.
If the goal is “no more mystery undefined crashes,” then:

  • Prioritize typing:
    • API boundaries
    • State
    • Shared utilities

If the goal is “new devs ramp faster,” then:

  • Prioritize typing:
    • Domain models
    • Public component props
    • Service layers

This affects what you type first more than whether you switch at all.

2. One thing I slightly disagree on: how “gradual” to be

Both replies emphasized very gentle, loose configs early. I think that works only if you also have strong guardrails.

If you stay too loose:

  • any spreads everywhere
  • People treat TS as “JS with extra steps”
  • Migration stalls at 40% typed and never really pays off

My tweak:

  • Use allowJs: true so you can keep JS around.
  • But from day one in new .ts files:
    • No implicit any on public function parameters and returns.
    • ESLint rule to forbid bare any, allow unknown instead when you must.
    • Disallow // @ts-ignore in new code except with an associated ticket.

That way the “old world” can stay messy, but the “new world” is cleaner from the start.

3. Architectural opportunity: use TS to enforce boundaries, not just types

Do not treat this as “same architecture, more types.” You can fix structural problems while you migrate.

Examples:

  • Define clear modules:

    • domain/ for core business logic and types
    • api/ for typed clients and DTOs
    • ui/ for components

  • Use types to prevent layering violations:

    • Components only talk to domain and api via exported types.
    • Avoid “reach across the app” imports.

Over time, TypeScript helps you see bad dependencies because imports and types become more explicit.

4. Cultural shift: TS only works if reviews enforce it

Tooling is not enough; code review rules are huge:

  • In PRs, reviewers should:
    • Ask “can this any be narrower?”
    • Request types for new public APIs (functions, components, hooks).
    • Reject new @ts-ignore unless there is a clear reason and a follow up issue.

If you skip this, you can end up in the situation where people say “we have TS but it doesn’t catch much,” which is usually a process problem, not a language one.

5. Onboarding and hiring benefits that JS can’t match

This gets overlooked:

  • New dev joins:
    • With JS: they grep through usage to figure out what shape of object is expected.
    • With TS: they hover a function and see User, Order, CartItem type definitions.

That alone saves weeks across multiple hires.

Your medium sized app with multiple devs is exactly where this pays off. JS plus JSDoc can help a bit, but without a strict compiler you rely entirely on discipline, which usually decays under deadline pressure.

6. When sticking to JavaScript is actually rational

A rare but real case where I would not bother with TS:

  • The app is:
    • UI-thin (just forms and some light display), and
    • Talking to a well typed backend where most complexity lives, and
    • You have strict ESLint + JSDoc that the team really follows.

Or:

  • This codebase is going to be replaced in the near term and you are avoiding all non critical investment.

Your description of “hard to maintain as new features and devs are added” sounds like the opposite of that though.

7. Pros & cons in your situation

Pros of moving:

  • Catches common bugs before they hit production.
  • Safer refactors as the app grows.
  • Better dev experience: autocomplete, inline docs.
  • Clearer domain language expressed in types.
  • Easier onboarding for new team members.

Cons of moving:

  • Initial productivity dip as people learn TS concepts.
  • Extra build step and configuration to maintain.
  • Occasional fights with library type definitions.
  • Risk of half typed, inconsistent code if the migration is not owned properly.

8. How this complements what is already said

Where I diverge a bit: I would start a bit stricter within new TS files than they suggest, so you do not accumulate another layer of technical debt in TypeScript itself.

If you treat TypeScript as an architectural and cultural upgrade, not just “JS with annotations,” the migration cost pays off quite fast for a medium sized, multi dev app like yours.