Why I Stopped 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 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 becomes annoying: // index.ts const message: string = "Hello, world!"; console.log(message); 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)); 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!

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

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

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

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));

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

node script.js

tsc script.ts && node script.js

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

Related Posts

Wan 2.1: The AI Video Revolution That's Out of This Wor...

Mar 3, 2025  0

Hoppscotch Self-Host: The Open-Source Postman Alternati...

Mar 18, 2025  0

Frontend Disscussion

Mar 5, 2025  0