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
anyand 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!
Great post – I’m with you that TypeScript isn’t the go-to for every little script or MVP. That said, I think the overhead isn’t as big a deal these days. With a well-crafted starter template that sets up tsconfig, build scripts, and even sensible defaults, you can avoid the “blank folder of despair” every time. Plus, you never have to force yourself into writing all the types; you can just opt-out of the strictness when you want. And with Node soon supporting TS out-of-the-box (plus ts-node being a pretty decent workaround in the meantime), the friction is even less of a hurdle. It’s really about choosing the right tool for the job rather than blindly rejecting TypeScript for small projects. Cheers to keeping it flexible!