Why Stop Using TypeScript for Small Projects?

I used to be that developer who pushed TypeScript into every single project. Backend? TypeScript. Frontend? TypeScript. A five-minute script to automate file renaming? Yep, even that. It felt like the right move—after all, static typing makes everything better, right?

Well, not always.

After years of forcing TypeScript into every project, I’ve finally admitted something: for small projects, TypeScript is more of a hassle than a help. If I’m spinning up a quick MVP, personal project, or a simple API, I no longer reach for TypeScript by default. Here’s why.

---

1. The Setup Overhead Isn’t Worth It

Let’s be real—TypeScript requires setup.

• Configuring tsconfig.json
• Making sure dependencies work with TypeScript
• Installing and configuring type definitions (@types/whatever)
• Adjusting the build process

Yes, I know that modern frameworks like Vite, Next.js, or Nuxt make setup easier with zero-config templates. But when you’re starting from scratch or not using a full framework, that configuration still exists—and for quick hacks or scripts, it's friction I’d rather avoid.

For a large-scale project, this setup pays off. But for something small—like a quick API or a weekend side project—why am I spending 20 minutes wrestling with configs instead of actually writing code?

A simple JavaScript file just works:

// index.js
console.log("Hello, world!");

With TypeScript, even something this basic comes with extra ceremony:

const message: string = "Hello, world!";
console.log(message);

Let’s get this out of the way: no, you don’t need to explicitly annotate string here—TypeScript would infer the type just fine.

This example became a bit symbolic for me. It represents how even the simplest scripts start to feel more formal and verbose when TypeScript is involved. In a quick project where I just want to print a message or hit an API, that extra layer often feels like friction instead of help.

And that’s before setting up the build process.

---

2. TypeScript Slows Down Experimentation

One of JavaScript’s biggest strengths is its flexibility. Want to throw together a proof-of-concept? No problem. With TypeScript, that agility disappears.

Say I’m trying out a new API. In JavaScript, I’d just fetch some data and move on:

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error(err));

In TypeScript? Now I need to define types:

interface ApiResponse {
  id: number;
  name: string;
  email: string;
}

fetch("https://api.example.com/data")
  .then(res => res.json())
  .then((data: ApiResponse) => console.log(data))
  .catch(err => console.error(err));

Of course, TypeScript lets you use any or gradually introduce types. But that kind of defeats the purpose of using TS in the first place, right? My point is—when I’m in experiment mode, I don’t want to think about types at all. I want fast feedback and no friction.

Sure, it’s safer—but if I’m just playing around, why am I writing extra code before I even know if this API is useful?

---

3. TypeScript’s Benefits Aren’t That Useful in Small Projects

I get it—TypeScript helps prevent bugs. But in a small project, does it really matter?

Most of the time, the “bugs” TypeScript prevents in small projects are things I’d catch instantly anyway.

Bad example:

const age = "30";  
console.log(age * 2); // NaN

Okay, TypeScript would catch that. But is this the kind of bug that’s keeping me up at night? No. If my entire app is 500 lines of code, I don’t need a compiler to protect me—I can just read the code.

---

4. The Extra Build Step Feels Unnecessary

With JavaScript, I can run my script instantly:

node script.js

With TypeScript, I have to compile it first:

tsc script.ts && node script.js

For a massive project? No problem. But if I’m writing a quick utility script, this extra step kills momentum.

And yes, I know you can use ts-node to avoid manual compilation, but it still introduces unnecessary complexity.

---

5. Not Every Dependency Plays Nice with TypeScript

Ever installed a third-party package and immediately run into TypeScript errors?

Property 'xyz' does not exist on type 'SomeModule'.

Then you check the package’s GitHub repo and see no TypeScript support. Now you have three options:

• Find a DefinitelyTyped package (@types/xyz) (if it exists).
• Write your own type definitions (ugh).
• Use any and pretend TypeScript isn’t there.

If I’m working on a big project, I’ll take the time to figure this out. But for a small app, it’s just another headache.

---

When I Still Use TypeScript

I’m not saying TypeScript is bad—I still use it for the right projects.

✅ Large-scale apps (especially with multiple developers).

✅ Projects with long-term maintenance in mind.

✅ Codebases that rely heavily on strict contracts between modules.

But for:

❌ Side projects

❌ Quick scripts

❌ MVPs and prototypes

I stick with JavaScript. It’s just faster, simpler, and more fun when you don’t have to fight the compiler.

---

TypeScript is a Tool, Not a Religion

Some developers treat TypeScript like the only way to write JavaScript in 2025. But that’s not true. TypeScript is great when used where it makes sense—but forcing it into every project? That’s just unnecessary friction.

If you love TypeScript, great—use it where it benefits you. But if you’re working on something small, and TypeScript feels like more trouble than it’s worth… maybe it is.

What’s your take? Do you still use TypeScript for everything, or have you started picking your battles? Let’s chat in the comments!

Comments

[José Pablo Ramírez Vargas]

Huh? Clearly you don't understand TypeScript.

console.log('message');

The above is TypeScript. Your example:

// index.ts
const message: string = "Hello, world!";
console.log(message);

Is just unneeded.

If my entire app is 500 lines of code, I don’t need a compiler to protect me—I can just read the code.

Hmmmm, maybe you do.

---

Generally speaking, yes, TS requires additional setup because it is more than JavaScript. No arguing that. You can, though, create a template project, do the setup once and pretty much use it to spin new projects up. Yes, still some little things here and there, I agree.

By the way, I don't disagree entirely with your point of view. Is just that your examples are just super bad.

P. S.: I always do my NPM packages in TS. It takes me 5 extra minutes to set it up. Is that the end of the world? Not at all. I think that your description fits the least amount of projects, not the majority. Most of the time you configure super quick and you're ready to work.

[Itamar Tati]

I don’t disagree that TypeScript is valuable, but how do you define "least amount of projects"? I’d argue that 90% of websites don’t actually need TypeScript (I’m making up that number, but if you look at most websites on the internet, you’ll see what I mean). Sure, when you're dealing with projects that have 15+ files or files with over 100 lines of JavaScript, the benefits become more apparent. But do most websites even reach that level of complexity?

TypeScript is great—I’ve been on teams where runtime errors made it to production for B2B clients, and we ended up begging management to adopt TypeScript. In those cases, it was absolutely the right choice.

However, if you're building a simple website or an MVP, TypeScript can slow you down. You'll likely find yourself adding @ts-ignore everywhere and using any just to move fast, which defeats the purpose. In those scenarios, skipping TypeScript might be the better option.

[José Pablo Ramírez Vargas]

Like I said, I don't disagree with the intent of the article. The examples are bad.

BTW, if it is a small project or POC, how many @ts-expect-error (because @ts-ignore is generally bad) do you think you'll need? It is, by definition, small. So maybe if you find yourself adding a lot of those, either the project is not small, or your choice of packages is on the old/vintage side.

[Itamar Tati]

I agree with 99.9% of what you're saying in your comment responding to the article. The only part I take issue with is the line: "I think that your description fits the least amount of projects, not the majority." I think most websites that you can find online do not need TypeScript.

Also small projects can still have complex data structures. For example, let's say I have an object where one of its keys must be an enum ("male" or "female"). The TypeScript compiler will complain if I don't explicitly define the full type, which might force me to add a bunch of @ts-expect-error or @ts-ignore comments if I don't want to fully type out the structure.

So maybe you're right—maybe if I'm running into these issues, the project isn't that small anymore. But my general approach is to start without TypeScript and introduce it when I feel like I need it, rather than enforcing it from the start. That way, I avoid unnecessary complexity early on and only add strict typing when it actually provides value.

[José Pablo Ramírez Vargas]

I think most websites that you can find online do not need TypeScript.

In order for us to logically argue about this one point, we would have to first define "to need TypeScript". Because technically, TypeScript is never needed. If you volunteer your definition, then we can start arguing.

[Itamar Tati]

This doesn’t have to be a debate—maybe we’re just operating on two different planes. When you go online and find a website for a plumber, a doctor's office, or a simple service page with basic functionality like booking or advertising, those sites make up the majority of the internet.

Earlier, I gave my definition of when TypeScript isn't necessary: if a project has fewer than 15 JavaScript files, each under 100 lines, I don’t see why you’d need TypeScript. And I believe that applies to 90% of websites.

Now, if you ask me to build Facebook without TypeScript or JSDoc, I will run away from you very fast. 😆

[José Pablo Ramírez Vargas]

Ok, I'll volunteer my thinking: Websites don't need TypeScript; the humans that build those websites need it. Typing helps humans to program. Decades ago, programming languages weren't typed. Did you know? The programmers needed to be perfect to calculate where one integer started and where it ended in RAM. By themselves. Typing in languages assists humans, not machines.

With this in mind, the answer is not as simple as "X source files with a maximum Y lines", because humans have different capacities: Human A may be more capable than Human B, so Human A might do better at no-TypeScript by merely being who he is.

In my opinion, "the need to use TypeScript" cannot be quantified in any way for the general programmer. It is an individual thing based on each person's capacity.

However, that's not all there is: There is "teamwork", and there is "the passage of time". Being considerate to your teammates, present and future, you should always use TypeScript. TypeScript not only helps you by providing types (which powers Intellisense), it helps you to document the code.

The following type tells a story:

export type User = {
  id: number;
  firstName: string;
  middleInitial?: string;
  lastName: string;
  isActive: boolean;
}

This software works with user objects that have an ID, first, middle and last names, and an active flag.

This helps even "future you", because we tend to forget things we don't use or see everyday.

[Itamar Tati]

The title of the article is "Why Stop Using TypeScript for Small Projects?" No one is advocating for abandoning TypeScript entirely.

I don’t disagree with any of your points. Your explanation of why TypeScript helps humans rather than machines is completely valid, and I agree that there’s no clear-cut rule for when a project needs TypeScript. But my argument was never that TypeScript shouldn't be used at all—just that most websites don’t need it.

I also agree that there’s no objective number that dictates when TypeScript becomes necessary. It depends on the individual programmer. But that decision should be mine to make, not something enforced from the start. My approach is to begin without TypeScript and introduce it when I feel like I need it, rather than making it mandatory upfront. This allows me to avoid unnecessary complexity early on and only add strict typing when it provides clear value.

Most websites on the internet are simple, with only a few JavaScript files—not enough to justify the overhead of TypeScript. As the title suggests, we should stop using it for small projects like plumbing websites, booking systems, and other basic service sites.

I feel like your arguments misrepresent my position. There’s nothing to debate here—we both agree that TypeScript is a valuable tool, and we both agree it’s useful in companies that employ full-time developers. The only real difference—which I think you’d agree with if pressed—is that the majority of websites don’t need TypeScript, and the overhead simply isn’t worth it to protect a small amount of JavaScript.

[Ben Sinclair]

I'm going to heave my oar into this thread a little late. I'm thinking about the example @itamartati gave about small brochureware sites for (e.g.) plumbers.

You're right. You don't need TypeScript for the website... but that's because you don't need JavaScript for the website. There's no good reason for such a site to have any script on it at all.

If the developer made the site through a static-site generator then that code itself could be written in anything, but if the SSG developer wanted to use JavaScript, then that would be the ideal place to use TypeScript, wouldn't it? A codebase that's going to be used multiple times by different people with different input data, perhaps in a pipeline somewhere. You want to keep that as error-free as you can.

Basically what I'm saying is that the "small amount of JavaScript" I'd tolerate is trivial, or is part of something a client wanted embedded and provided as-is.

[Itamar Tati]

Hey, I’m not sure if you’re actually reading my comments here, I am not sure what you guys are disagreeing with. I’m not arguing against TypeScript in scenarios where it shines—like codebases shared across teams, handling varied input data, or running in complex pipelines. Of course TypeScript’s useful there; it cuts down on errors and keeps things sane. No one’s disputing that.

But that’s not the reality for most of the internet. The vast majority of websites—like 90% of them—are simple, basic stuff. Think small business pages, personal blogs, or brochureware sites with minimal interactivity. These sites either barely use JavaScript or skip it entirely. That’s my whole point. I mentioned sites with, say, fewer than 15 JavaScript files, each under 100 lines. That’s not some edge case—that’s the norm for most of the web. For those, TypeScript isn’t just overkill; it’s unnecessary overhead when you’re dealing with such lightweight needs.

Now, about that line: "There’s no good reason for such a site to have any script on it at all." I’ve got to push back on that. It’s not a great take. Even the simplest sites often need some scripting. We’re talking tiny, practical stuff—like grabbing the current date and displaying it, or toggling a mobile menu, or adding a basic form validation. These are small files, often just a handful of lines, and they’ve been JavaScript’s bread and butter since the beginning. That’s literally why JS was created: to sprinkle lightweight enhancements onto HTML and CSS. Saying “no script at all” ignores how the web actually works for most people building these things.

And yeah, modern CSS has taken over a lot of what we used to lean on JavaScript for—hover effects, animations, even some layout tricks. That’s awesome, and it’s shrinking JavaScript’s footprint even more. But there’s still a role for those tiny scripts on small sites. My argument isn’t that TypeScript’s bad—it’s that you don’t need it for these cases. If the JavaScript is that minimal, why bolt on a type system? For small projects and MVPs, where speed and simplicity matter most, TypeScript’s just extra baggage.

So, to sum it up: I’m not saying ditch TypeScript for big, collaborative projects—keep it there, it’s great. But for the little stuff—the majority of the web—it’s not needed. You don’t need types for “TypeScript for Small Projects” because you barely need JavaScript to begin with.

[Arnaud Gathy]

You have no idea what you are talking about and it shows.

The setup process is automatically provided by any bundler like vite, or framework like Next, no one has to write a tsconfig file from scratch.

This example is laughable, because you have no idea what type inference is, and that's why you think writing TS code is complicated.

// index.ts
const message: string = "Hello, world!";
console.log(message);

All the overhead you mention are so small compared to the time it can save you from debugging / fixing, even in small projects.

Basically you are saying "just don't create bugs, read the code you write", duh why didn't I think of that before ...

[Joshua Amaju]

It's strange to respond to a complaint about complex setup mentioning vite, next etc 😂

[Rense Bakker]

Really? You find it too complicated to run: npm create vite@latest my-new-app -- --template react-ts?

[Joshua Amaju]

I think at this point you're intentionally missing the point

[Rense Bakker]

What point? That was my first response to you.

I'm honestly trying to understand what you find complicated about using vite to setup a project. Or did you just randomly drag vite into this, even though it completely undermines whatever point you were trying to make? If so, let me know. I will ignore that you mentioned vite and try to understand your original point. Or, please give explicit examples of what makes vite complicated.

[Melroy van den Berg]

Well actually...

[Rense Bakker]

Why do people keep pretending that typescript forces you to explicitly declare types for everything?

Typescript is not Java.

Let's repeat that to let it sink in once and for all.

Typescript is not Java.

All the javascript code you used as example, you can use in a .ts file without any modification. How do I know this? Because typescript is a superset of javascript. This means any javascript code is valid typescript by definition. Therefor you told factual lies in your article. Please don't do that.

Whether people use typescript in their personal projects is fully up to them, but if you need to tell factual lies to yourself, to justify not using typescript... Maybe you should use typescript...

[Melroy van den Berg]

Typescript is fake. During runtime there is no type checking anymore.

[Rense Bakker]

What would be the purpose of runtime type checking? 😂 You want to catch error before runtime...

[Joshua Amaju]

You've never heard of zod?

[Rense Bakker]

I think you're confusing type checking and input validation/sanitation. Yes I use zod for that, no it's not the same as type checking and you still don't want to catch type errors at runtime because that means you've written broken code.

[Joshua Amaju]

They're functionally the same thing given you mentioned at runtime. Input validation is runtime type checking.

If typescript were to be added natively to JavaScript that's basically the same thing.

[Rense Bakker]

No, there's a very real and important difference between input validation and type checking of the code constructs that you as a developer create in the source code.

You don't want to ship code that contains a bug, regardless of user input. For example, you don't want to use an object property in you code that doesn't exist anymore, because you or another developer removed it at some point. If you catch that bug at runtime, you're too late. One or more of your users has to have hit that bug in order for you to receive the runtime bug report. With type checking, you can prevent that bug from appearing at runtime.

Input validation is used most frequently to sanitize user input, so you can safely use the inputs in your program.

[Rene Kootstra]

Exactly, building web components in typescript and using those components in pure javascript and html is a source of errors.

[Robin Schambach]

Why on earth would someone write this unless they are beginners?

const message: string = "Hello, world!";

You know there is type interference?

I used to think the same as you but sooner or later inherited really bad scripts by coworkers. After I enforced typescript for each and every website everything became much better. Plot twist: it doesn't really increase development time as there is zero configuration required (using boilerplates that are required for larger projects anyway) and it will make our work much easier when coming back to simple websites after a few years to include more features.

Due to generics and type interference you don't need to include as much ts as you might think. Not sure if you are experienced ts developer but judging by your examples it doesn't seem so to be honest.
Maybe it would have been a good idea to provide better examples.

[Chris Carr]

It's not interference. It's inference.

[The Jared Wilcurt]

There are only two types of projects, those that are too small to justify adding linting to, and those that need linting. No project needs TS. Maybe you want the TS engine to validate things for you (glorified linter), but you don't need to use the TS language for that. Just use ESLint-Plugin-JSDocs. It has all the benefits you are trying to get from TS, plus more (actually documents your code adding context and intention), and it has none of the TS drawbacks:

• Complex tooling - It's just a lint plugin
• Segregated ecosystem - It's just JavaScript
• Hard to read hover text (TS is bad at hovertext)
• Slow compiles - There is no compile, it's just JS
• Debugging complexity
• etc.

There is nothing TS can do that JSDocs can't, even stupid shit like tuples and enums. It is fully compatible with the TS engine and tsc, and officially recommended by the TS maintainers. Just add a // @ts-check to the top of a file and the TS Engine in your editor will use the JSDocs types EXACTLY the same way it would use TS Types.

Everyone says "Webdev is too complex these days, I wish we could go back to when it was simpler". You can, start by killing your darling TS, it is time for it to go.

[Himanshu Sorathiya]

I'm not saying you're wrong, I can relate that ts for small projects is not worth cause ot takes extra set up time and we don't like wasting time.
But example you took are so poor. It looks like you didn't even worked to get those plain examples.

As a person who loves ts, no matter what's project size, id love to use ts. Now even my hands practiced that whenever after a var declaration, arguments of funcs, return types my hand will auto press ":" 😅

[Cyan]

That's what Deno and Bun for, you can run TypeScript code out of box, with Deno, it have built-in LSP for TypeScript.

For most code, typing helps you, remembering what the code does, what things can you pass to a functions.

Most time your definition is inferred from the usage, for functions, you typed it so you could use it correctly and knowing what can the functions do.

Without TypeScript, you could misspell a word and break at runtime, which might hard to debug, even on small projects.

[Peter Vivo]

You totally right! I am moving a bit forward: even if I would like to help my development with type safe, I use JSdoc instead TS. My details: dev.to/pengeszikra/jsdoc-evangelis...
JSdoc have similar capability as TS and don't need to compile your code, keep your code can copy paste any where. Also great for legacy codbase where no option to use TS.

[Anthony Dreessen]

I think all of your complaints have solutions

tsx will let you execute typescript directly

GenAI will easily gen you up a scripty bit whatever shape you want

Remember, types are basically just unit tests you get for free.

[kurokaze zx]

I created an account just to comment.
While I can agree with the sentiment, the arguments / reasoning leave a lot unsaid.

Use

• bun, most of your setup troubles go away.
• If you need to prototype/test/experiment something framework based, just use Vite's documentation codesandbox links to scaffold a project online, or create a vite project locally, and it will get you pretty much all the way there, seeing as you aren't looking to perfect the configs, and just get something running.
• Now if even these are too, yep just use javascript, honestly half the time I'm using chrome's console to test super small functions or scripts. Just use the minimal thing that feels good enough, that's fine.