I used to be that developer who pushed TypeScript into every single project. Backend? TypeScript. Frontend? TypeScript. A five-minute script to aut...
For further actions, you may consider blocking this person and/or reporting abuse
Huh? Clearly you don't understand TypeScript.
The above is TypeScript. Your example:
Is just unneeded.
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.
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-ignoreeverywhere and usinganyjust to move fast, which defeats the purpose. In those scenarios, skipping TypeScript might be the better option.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-ignoreis 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.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-erroror@ts-ignorecomments 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.
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.
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. 😆
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:
This helps even "future you", because we tend to forget things we don't use or see everyday.
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.
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.
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.
I agree with your sentiment, and just want to add this to everyone else reading:
Bun, deno and node with the
--experimental-strip-typesflag strip away all types and run typescript files without transpilation or config required. Your IDE can still support TypeScript functionality because it uses an LSP.The only downsides are that some things that will result in a runtime error are highlighted in your editor (oh no:( but you can still run it if you don't believe it!), and variables that you define can only be used for 1 thing, otherwise they will be highlighted too. If you're using the same variable for 2 different things though, you're doing something confusing even if it was in JavaScript, and I bet your variable name sucks.
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.
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 ...
It's strange to respond to a complaint about complex setup mentioning vite, next etc 😂
Really? You find it too complicated to run:
npm create vite@latest my-new-app -- --template react-ts?I think at this point you're intentionally missing the point
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.
Well actually...
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:
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-checkto 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.
I'm the vanilla js guy. I know everyone lives their plugins, add-ons,and supersets but sometimes it just feels like everyone doing the same thing functionally just differently in the syntax. It's so js at the end of the day. I get the need for using things in teams etc.. But damn. So I agree with you.
If configured well the JSDoc then even don't need to use '// @ts-check' on top of file.
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...
Typescript is fake. During runtime there is no type checking anymore.
What would be the purpose of runtime type checking? 😂 You want to catch error before runtime...
You've never heard of zod?
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.
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.
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.
Exactly, building web components in typescript and using those components in pure javascript and html is a source of errors.
You don't need compilers if you use Bun or Deno. Or you can use ts-node that is production ready solution. Have a nice day.
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 ":" 😅
You got a nasal exhale from me so take my like 😅
This is the way
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.
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.
I think all of your complaints have solutions
tsxwill let you execute typescript directlyGenAI will easily gen you up a scripty bit whatever shape you want
Remember, types are basically just unit tests you get for free.
Feels like most people didn't actually read the Article. Good job it's well put and well structured with very few minor mistakes with the code examples but nothing that we can't understand. But like any religion, by calling it out you now have to deal with its followers who refuse to engage with the points you're actually making.
It's really not. The code examples are complete nonsense. Zero typescript developers in the history of typescript have written this:
That's just completely fabricated nonsense and so are the rest of the "examples".
You have to deal with people who call you out on telling factual lies. I'd call you out if you said python doesn't use indenting to define code blocks, or if you said that PHP stands for Professional Help Program. The language is irrelevant, the message stays the same: "Do not spread lies". The only one who is religious here is you. You're religiously anti-typescript.
What exactly is the lie?
also I read the other comment you left:
“Typescript is not Java. All the JavaScript code you used as examples, 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. Therefore, you told factual lies in your article. Please don’t do that.”
Mate, TypeScript was literally created by Microsoft to bring the safety features of languages like Java and C# to JavaScript. That’s its entire purpose.
And what do you mean by “any JavaScript code is valid TypeScript?” TypeScript has a compiler that enforces type safety and prevents certain JavaScript from running. It’s a compiled language—it doesn’t run in the browser; it transpiles down to JavaScript first. If TypeScript was just JavaScript, there wouldn’t be a need for a compiler at all.
I’m not being dishonest. TypeScript is a great tool—one I wouldn’t want to work in enterprise without. But pretending it has no drawbacks? That’s what’s religious. Honestly, even religious people acknowledge flaws in their beliefs more than some TypeScript defenders do.
Yes typescript will prevent you from running broken JavaScript code. Why exactly do you want to run broken JavaScript code? I will clarify for you. Any VALID JavaScript code is also valid in Typescript. I'm not kidding when I say typescript is a superset of JavaScript. I'm not making that up either, it's in the official documentation. Unlike the claims you're making.
Typescript brings type safety to JavaScript yes and the syntax is inspired by c# and Java, but if you have worked with either, you would know that the type system works completely different from those languages. For example, TypeScript relies heavily on type inference, while in Java you must explicitly declare types for everything.
You're claiming that you have to declare types for everything in Typescript as well, which is a factual lie (see the official documentation). I cannot explain this to you in any other way.
Hiding behind the word “superset” doesn’t change the fact that TypeScript has a compile step. Sometimes you don’t need type checking for small files, and that’s why I believe 90% of projects don’t need TypeScript—because most websites have very small JS files.
For example, take this JavaScript code:
Now, if your argument is “But this still runs in TypeScript”—then what’s the point of using TypeScript in the first place? The reason it might still run is that TypeScript, when strict mode is off, will implicitly assign Directions an any type. But that completely undermines TypeScript’s supposed benefits. If you’re just going to allow implicit any or slap @ts-ignore everywhere to suppress errors, then all you’ve done is add an unnecessary build step without gaining any real type safety.
And let’s be real—people who don’t see this as a problem usually aren’t writing their own servers. They don’t have to deal with build complexity because they rely heavily on framework teams (Vue, React, Node) to configure TypeScript and handle the build steps for them. It’s easy to say TypeScript has no downsides when someone else is managing the headaches. But if you’ve ever had to debug a TypeScript build failure on your own infrastructure, you’d realize how much unnecessary complexity it adds, especially when the supposed “safety” can be bypassed so easily.
Additionally, it doesn’t matter if you don’t have to explicitly declare types for everything in TypeScript. Nowhere in my original post do I say that declaring types is the issue—what I’m pointing out is the unnecessary complexity that TypeScript introduces. To get TypeScript’s full benefit, you should declare types to fully leverage its safety features. But the issues I outlined are not about being forced to declare types; they’re about the overhead introduced by the compile step and the fact that, for many projects (especially smaller ones), the safety and complexity TypeScript offers are not necessary. The author of the original article listed five specific issues they have with TypeScript, none of which were related to being forced to type explicitly.
And this “go see the documentation” argument is essentially the same as when someone challenges a Christian’s belief in the global flood, asking how it’s possible when scientists say there isn’t enough liquid in the world for a flood of that scale. Instead of engaging with the point or acknowledging any flaws in their belief, the response is simply, “Go read the Bible.” Similarly, you’re sending me off to the documentation, as if that’s the final word on the matter, without actually addressing the concerns or flaws I’ve raised. It’s a way of avoiding the discussion and not acknowledging that TypeScript’s limitations might not work for every project.
The reason why I'm so passionate about discussing TypeScript like this is because I've seen how people use TypeScript, and if you use it wrong it increases the development time significantly (I once took over a project where the same API response was explicitly typed 14 times!!! in different files and each were different). For this reason alone, I'm really hesitant to introduce TypeScript into projects with others. However, when discussing the pros and cons of using TypeScript when used correctly, I don't think any argument holds.
Your example is a great example:
Save this in a .ts file and run it with deno, bun or node (with
--experimental-strip-types) and it works just like a plain js file.You say:
The point is that now you can use TS other places, if you want, or add to it as much or as little as you want. Take this tiny addition for example, which will give you auto-complete for which directions exist:
This code runs identically to a js file with zero config and only adds autocomplete + gives you an error if you ever try pass it something that will 100% of the time fail.
Even if you're developing something small that changes a lot of the time, I agree that you will rarely declare any types, but it's nice to have the possibility to add tiny type hints here and there.
Worst case scenario, you have a .ts file with just plain .js in it. Best case scenario, you have auto completion and error highlighting.
Thank you for responding to my comment without calling me a liar or implying that I don’t understand the technology. Your points are well-structured and delivered well, but they don’t address what I’ve been saying or what the author of the original post argued.
You say:
“When discussing the pros and cons of using TypeScript when used correctly, I don’t think any argument holds.”
But the original post outlined several arguments against TypeScript:
• The Setup Overhead Isn’t Worth It
• TypeScript Slows Down Experimentation
• TypeScript’s Benefits Aren’t That Useful in Small Projects
• The Extra Build Step Feels Unnecessary
• Not Every Dependency Plays Nice with TypeScript
And here are two of my own:
1. 90% of websites don’t need TypeScript.
2. Adding complexity to a small project introduces a new point of failure with little to no benefit.
None of which have been addressed by anyone who has commented
You say:
“Save this in a .ts file and run it with deno, bun or node (with –experimental-strip-types) and it works just like a plain js file.”
I think you might be arguing against yourself here. If TypeScript is just JavaScript and all I do is change the file extension, then what is the point of the compile step? Why would you introduce a new point of failure if you're just going to run JavaScript without any type checking. TypeScript doesn’t run in the browser—it gets converted back to JavaScript. And, as I said:
“The reason it might still run is that TypeScript, when strict mode is off, will implicitly assign Directions an any type. But that completely undermines TypeScript’s supposed benefits. If you’re just going to allow implicit any or slap @ts-ignore everywhere to suppress errors, then all you’ve done is add an unnecessary build step without gaining any real type safety.”
Then you add some type checking, but that kind of misses the point. I’m talking about a small website where I just need a simple script to rotate a compass. The work is already done in plain JavaScript. If I introduce TypeScript, I now have to deal with an extra build step for what? Type safety on 15 lines of code? That might make sense in a large organization where others need to read and maintain the file months later, but for a small project, the tradeoff isn’t worth it. And that’s how most websites operate, they are small, they don't need TypeScript.
You also say:
“This code runs identically to a JS file with zero config.”
How? TypeScript requires compilation. Do you manually convert every file from .ts to .js on the command line? Probably not—you likely have a build process, and that process needs configuration.
You say:
“Even if you’re developing something small that changes a lot of the time, I agree that you will rarely declare any types, but it’s nice to have the possibility to add tiny type hints here and there.”
That’s not what TypeScript is. Many people think TypeScript is just a linter—it’s not. It’s a compiled language that won’t compile if your code doesn’t meet its type standards.
Finally, you say:
“Worst case scenario, you have a .ts file with just plain .js in it. Best case scenario, you have auto-completion and error highlighting.”
But again—TypeScript doesn’t run in the browser. At some point, someone has to convert it to a JavaScript file. That’s the extra step I’m talking about, and for a lot of projects, it’s just not worth it.
You contradict yourself like 10 times in one paragraph mate and you fail to properly read or understand any of the commentors who have tried to explain to you that you indeed don't need a compilation step to run typescript because yes, you can just use the strip types flag and voila, your ts code runs in node without any compilation.
Why would you say I contradict myself but not actually point out the contradictions? If I do, just tell me—I’m only human. I make mistakes, and it’s perfectly fine. Just point them out, and I’ll see if I can clarify or correct them.
No commenter has explained anything of substance. It’s the same drivel: “You should just do type checking.” But that was never my issue with TypeScript.
When you say:
“You indeed don’t need a compilation step to run TypeScript because yes, you can just use the strip types flag and voilà, your TS code runs in Node without any compilation.”
I’m not sure if you’re not reading my arguments, if you’re being dishonest, or if you just don’t understand. Either way, I’m happy to explain with the hope that it’s the third one.
Node.js and the browser are two different runtimes that have nothing to do with each other. Just because you can run TypeScript on Node.js doesn’t mean anything for the browser. You still need to convert your TS files into JS files because browsers do not and will not ever support TypeScript.
You can test this yourself:
• Create a blank HTML page.
• Link a .ts file instead of a .js file.
• Try console.log("Hello, world!") inside it.
The browser will ignore it because it’s not JavaScript.
Now, if you’re making a backend with Node, it’s still your job to figure out what to do with TS files for the browser. If you don’t convert them, they will not run—and that’s the part you don’t seem to understand.
Just because TypeScript can run on Node doesn’t mean anything for the browser. Node and browsers are completely different environments. And even if Node could somehow magically hack into the browser to make it understand TypeScript files, what about all the other languages that run server code?
Would they also need to do this “magic hacking” just so they can run directly in the browser? No. Because browsers have a single, standard language: JavaScript. If your language isn’t JavaScript, you have to compile it—it’s that simple. So there is always a build step needed and if you say there isn't you're just wrong.
And this is my whole point: TypeScript adds unnecessary overhead that most of the internet doesn’t need.
Most projects can do without it. It’s useful for large enterprise applications with big teams, but for smaller projects, it’s just not needed.
@itamartati Perhaps we're talking about different use cases. I agree that you will have to transpile the typescript files to javascript if you are running it in the browser. Browsers don't run TS, they run JS. Running TS files without transpilation is only possible for non-web projects.
There is no build process and it doesn't require configuration. Bun and deno have builtin transpilers that strip away type information. It doesn't check type errors like
tscdoes - it just strips the types away so it runs identically to JS without any config or build. Check this out:I'll give you that if you're wanting to create a small project in just basic HTML/CSS/JS with no frameworks AND the project is not heavy on scripting, then yes, typescript will just be an overhead to setup. In any case, you can introduce TypeScript when the no-framework project becomes more heavy on scripting - which I think is your sentiment too. I was just under the assumption that you'll almost always be using a web framework when making anything for the web - even small projects - as it's super simple to setup and gets everything working for you out of the box.
These are all examples of TypeScript being used incorrectly.
There is no overhead unless you're doing a web project without a framework, which to that I'll ask why?
How? You can write plain JS in a
.tsfile and never even touch TypeScript - and yes you won't get any benefits, but you won't get any downsides either. Then whenever you want, or wherever you want, you could add types later with 0 setup cost. It doesn't slow you down, when used as it's supposed to.You're probably right - it depends on the amount of scripting and the logic you'll need. But that's the nice thing about TS. You can incrementally introduce it where you need it when you need it and forget it exists otherwise.
With web frameworks it's identical to running JS. With deno and bun it's also identical to running JS. There is no build step or adjusted workflow that you must invoke manually to get it running. Just
bun run devorbun index.ts.TypeScript only adds to JavaScript, and you choose how much you want to add. If a library doesn't have TypeScript types, then you're at exactly the same place as if you were to use JavaScript. If you're "lucky" to find types for that package (which 99% of popular packages do), then you've gotten type safety for free.
It depends on how you define need. I could potentially agree with this, but I would not agree that 90% of websites should be created without using a framework, and if you're using a web framework in the first place, then it requires so extremely little effort to add typescript, that I don't see why you would go out of your way to not use it. Even after adding TS, again, you add whatever you want, and probably in 90% of the websites you will barely use any TypeScript features.
I just disagree that it's a point of failure if you know how to use TypeScript. For this point, I just want to reiterate that I'm arguing that TypeScript is not what is the limiting factor here, but the developer. Very basic TS is really not hard, but if you use it wrong it can make things harder for yourself. All the code examples that the original post included are examples of making things harder for yourself.
And we're back to square one, which proves you don't read.
Nobody runs plain JavaScript in the browser. There's always a compilation step, if only for bundling and that bundler can also strip your types, without any additional config.
Yes, if for some obscure reason you insist on sending unbundled unminified JavaScript to your end users, Typescript is probably not for you.
@eric_b_67cb420d1a0eddc900
Listen mate, I’m glad we can at least agree that TypeScript isn’t needed for small projects and simple websites. But it’s unfortunate that you don’t seem to realize that the majority of websites on the internet are small and built without modern frameworks. If you had read my original comments—which is fine, I wouldn’t expect you to—you’d see that my entire argument was that TypeScript is overkill and unnecessary in these cases.
The funniest part of this whole debate is how people keep bringing up non-frontend projects as justification for TypeScript. Let’s be real: TypeScript was created for the web, not for servers. When it was introduced, Node.js wasn’t even that popular. If Microsoft truly wanted a type-safe, compiled language for backend development, they would’ve just used C# or Java. The whole point of TypeScript was to bring type safety to frontend development, and any suggestion otherwise is missing the mark. If you want a strongly typed language that prioritizes safety over rapid experimentation for backend work, just use C# or Java.
Now, let’s go through some of your counterpoints:
“There’s no overhead unless you’re doing a web project without a framework, which to that I’ll ask why?”
Because more than 95% of the internet doesn’t use a modern framework like React, Angular, or Vue. That’s why.
“You can write plain JS in a .ts file and never even touch TypeScript—no downsides, and you can add types later.”
That file won’t run. If I have 10 minutes to set up a simple calculator script, I’m not using TypeScript because that file won’t execute unless I configure a build step, manually convert it, or change the extension.
“You can incrementally introduce TypeScript where you need it.”
This, I 100% agree with.
“TypeScript only adds to JavaScript, and you choose how much you want to add. If a library doesn’t have TypeScript types, then you’re in the same place as if you were using JavaScript.”
Not exactly. If TypeScript doesn’t have type definitions for a dependency, you now have to manually create them or deal with any types, which kind of defeats the point of using TypeScript in the first place. Worse, if the library later updates its types, it could break your implementation in unexpected ways.
“Most websites should be built with a framework, so adding TypeScript is trivial.”
Nothing screams “no room for experimentation” more than downloading someone else’s framework—built by developers who have never seen your project, have no clue about the problem you’re solving—and then being told you must solve the problem this way. Like I said, 95% of websites do not use React, Angular, or Vue. It’s a serious problem if you think they should. These frameworks aren’t perfect, nor are they meant for every situation. For small projects, it’s often better to just write a small script instead of bringing in an entire ecosystem.
“TypeScript is not a point of failure if you know how to use it.”
I’ve spent hours configuring TypeScript, so no, I disagree. Getting it to work is hard unless you rely on someone else to do it for you—like the React team.
Anyways there's no point in continuing this, we pretty much agree on most things, like you shouldn't use typescript in small projects, all we disagree with is how do we define a small project, I can respect your opinion and if better evidence comes along I can change my opinion.
@brense
“And we’re back to square one, which proves you don’t read.”
Mate, you’re the one making sweeping statements without considering the reality of most websites.
Nobody runs plain JavaScript in the browser. There’s always a compilation step, if only for bundling and that bundler can also strip your types, without any additional config.
This is just factually wrong. Plenty of websites run plain JavaScript in the browser. No bundler, no build step, just script tags. Go inspect the source of millions of small business sites, personal blogs, landing pages, internal tools—none of them are shipping Webpack or Vite builds.
Yes, if for some obscure reason you insist on sending unbundled unminified JavaScript to your end users, TypeScript is probably not for you.
Obscure reason? Simplicity is an obscure reason now? You do realize that not every project is an enterprise-level React app, right? Some of us just want to add a script file and get on with our day. If the benefits of TypeScript don’t outweigh the overhead for a given project, then it’s unnecessary—it’s really that simple.
Anyways I don't think we will ever come to a reasonable agreement. I wish everyone success. But apparently I stand on one side and you stand on the other.
Yeah, we just made up bundling and minifying for fun. No benefit to it at all.
I'm sorry I should have clarified: no developer who lives in the 21st century ships unminified code to the end user.
You're making up this really weird niche that shouldn't exist anymore, you blow it out of proportion and then you're using it to make some kind of strange argument against typescript. Sorry I can't help you with that.
Oh and I don't hear you anymore about any of your previous arguments about how JavaScript code was not valid in Typescript or something 😂 So I guess you did learn the meaning of "superset". That's something at least.
Sorry mate but you really ask for the sarcasm.
No you disagree on facts. You make up your own.
Again bad comparison 😕
I created a template once (
nextjs tailwind ts), studied the basic stuff in configuration and that was it.I've built over 20 small projects and my portfolio using TypeScript. Most of them were smaller projects, so it really depends on the developer and their approach.
I also make sure not to add anything just to bypass the type definitions (otherwise what's the purpose)... it's really not that hard.
I think the problem is more that the TypeScript ecosystem isn't mature enough to make developing in TypeScript a breeze. It doesn't take much time to write most types that you would need to write and the benefits down the road outweigh the upfront cost in most cases.
Sure, if you are doing a side project that is a prototype/demo and you are sure you are going to throw it away or never iterate, then JS is a perfectly reasonable choice. However, if you have other ideas for your project and it gains some traction, you'll probably want to convert to TS for all the benefits it offers.
Node now has experimental support for stripping types, which is a huge step forward.
I created an account just to comment.
While I can agree with the sentiment, the arguments / reasoning leave a lot unsaid.
Use
As a senior full-stack web developer with five years of experience, I completely agree. But in the end, the community decides.
- Knowledge is knowing that tomatoes are fruits, not vegetables.- Wisdom is following the community and not putting them in the fruit bowl.Nice article, some sensible advice here. 😀 Use whatever you want. It is more important to understand the project's goal, budget constraints, developers' skills, and so on...
TypeScript helps with large teams and more complex applications to standardize and prevent silly bugs due to JavaScript's "wishy-washy" typing.
Context matters, for example, if you are a SaaS founder and just need to ship something. Just use whatever as long as you don't have security issues or create too big of a technical debt. 90% of SaaS apps fail anyway, so are you gonna waste an extra 2-3 weeks writing typed code?
But when your app scales, then you should implement good typing. Silly-type bugs can be costly, so it all depends on context.
I completely agree! TypeScript is great for large projects, but for quick scripts or small projects, it often feels like more hassle than it's worth. Sometimes, speed and simplicity matter more than strict typing!
Half of the complaints can easily be solved with one or two prompt to chat GPT though.
I actually rather like and enjoy typescript.. now I don't like using it for back in stuff I prefer C sharp for that but that only matters if I'm doing something complex that needs a database which is not often if I'm just reading files I don't need C sharp I can do it with no JS and typescript. And by the way the comment about who cares about bugs in a small project. I do for one. Secondly that kind of attitude I expect from developers who actually aren't competent at which makes me wonder why I'm reading your article to begin with to be honest
To be honest, most of your downsides boil down to setup and transpiling. If that's a concern to you, try out bun which can run typescript natively and also makes it very easy to setup a project. Very handy for small projects in particular.
Why on earth would someone write this unless they are beginners?
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.
It's not interference. It's inference.
Just use Deno instead of Node and then half the stuff you're complaining about is no longer a problem
Signed into my Dev.to account for the first time in forever just to say how misinformed this post is.
The examples are terrible, and the perfect example of the Dunning-Kruger effect.
Regarding 1:
All that is not necessary for simple scripts. Just run
npx tsx yourfile.tsand you're done. Don't overcomplicateAlso, your code example is just wrong and overcomplicated for the sake of trying to prove your point. There's no need to lie like that.
console.log("text")is valid typescriptRegarding 2:
You're saying you're experimenting, and then complaining you need to define response types? Then just don't? You can just slap an
as anyon there and all your complaints go away. Sure, it's not best practise, but you still have that "agility" you wanted for your experiment.Regarding 3:
I guess?
Regarding 4:
See 1
Regarding 5:
Valid point, though it's rare to run into dependencies that don't have at least community types, especially in small projects and scripts like what your post is about
Glad you're here to tell him about tsx, how stupid of the author, they should have known what you know 😂.
It's ironic you mention a tool that was created because of the problem mentioned in the article.
The author is not stupid for not knowing these things. It's just stupid to blame the tool when you are the one creating problems for yourself. The author frames their whole article as if it's limitations within TypeScript that make it bad for small projects, when in reality they're just using it wrong.
It would be like me complaining about how JavaScript is a bad language because I can do this:
In this analogy,
constistsx, and JS is TS.I don't think you understand typescript man
I wonder if I'm really the first to point out that your example what TS would catch is wrong:
"30" * 2will result in 60, not in NaN.While you should question if the efforts outweigh the advantage for your tools, the advantages of TS is similar to the one of unit tests: to help you make changes with the confidence that they won't break (in this case, type soundness, with unit tests it would be specified behavior). So it is not merely a question of project size, but about how hard it is to get things wrong.
If it is easy to get things wrong and not too hard to constrain the types in a way that prevents this, use TS, otherwise don't.
I respectfully disagree with the take that TypeScript isn’t worth it for small projects. In my experience, many of the issues cited are really about the learning curve rather than inherent flaws in TypeScript. Here are a few points and examples:
1. Setup Overhead
Modern tools (e.g.,
tsc --init, Vite, or scaffolds likenpx create-react-app my-app --template typescript) make initial configuration a one-time effort. Once you’ve set up a project, you hardly feel the weight of that overhead.2. Slower Experimentation
During rapid prototyping, you can adjust TypeScript’s strictness or use tools like
ts-nodefor immediate feedback. For example, you can temporarily disable strict checks in yourtsconfig.json:This lets you experiment quickly while still benefiting from improved IDE autocomplete and error detection.
3. Benefits in Small Codebases
Type safety isn’t only for large projects—it helps catch bugs early even in small scripts. Compare these two functions:
4. Additional Build Steps
Modern bundlers like Vite or esbuild integrate TypeScript seamlessly, making the compile step nearly unnoticeable. With tools like SWC, the extra step hardly impacts the feedback loop during development.
5. Library Compatibility
The robust DefinitelyTyped ecosystem covers most libraries. In rare cases where types are missing, a quick ambient declaration or using any temporarily is a small price to pay for the overall benefits.
In short, many of the challenges are just part of getting comfortable with TypeScript’s ecosystem. With the right tools and experience, its benefits shine through—regardless of project size.
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!
Or, for beginners like me, you can absolutely just paste your simple JavaScript code into an AI tool like ChatGPT, Gemini or DeepSeek to help discover type annotation errors or even generate JSDoc comments automatically (without any installations ;) ). AI tools are particularly useful for:
Identifying Type Errors:
Generating JSDoc Comments:
@param,@returns, and@typeannotations.Providing Type Suggestions:
Improving Code Quality:
Even a small app or an MVP, I'd use TypeScript, even if just so I've defined all the data structures important for the architecture. TS gives me a way of visualising how it all fits together. Given TS takes minimal effort to setup, I personally don't see any reason to not use it. But hey, if someone doesn't want to use it, fine. To me it's very desirable addition to any project, and thus a necessity.
I just experienced everything you said. I have been debugging my Typescript application more than I've been writing features and it's just a small project. The problems are had where almost all TS issues which has really delayed me.
I think a big message in this is using the right structure for the project at hand.
I very frequently use this single page Vue html template for creating small sites. It has everything I need and just gets the job done. Having a solid foundation of the web + where Vue saves a lot of upfront time, I can prototype and get something deployed with this template in minutes and migrate to another solution seamlessly if needed.
I go back and forth on TypeScript directly. I am a big fan of
denoand use it all the time for scripting and other small programs, but even then unless the code is to be "communicated" or shared with other developers, I often opt for JavaScript-first TypeScript. I am usually thinking through a solution and haven't isolated and core data structures or interfaces yet. I may add interfaces for API responses or structuring data, but it all depends.I agree with the core tenet.
I am going to argue with all of this.
First of all, there is always a small chance of a weekend project turning into a massive enterprise solution (ask me how I know). But, if structured correctly rebooting even huge projects is not exactly hard. So.
1. Setup overhead
A good majority of us has multiple boilerplates already set up which we religiously update yearly. There is nothing quite as fast as forking one of our projects and installing maybe a couple of packages. From the ground up, using the good 'ol tried and tested webpack, you can get to first builds going in about an hour with testing and custom instrumentation.
2. Experimentation
There is a reason why all of my boilerplates have every TS restriction removed and has full JS interop.
3. Usefulness for small projects
Using typescript as a glorified intellisense tool actually does benefit small projects quite allot.
4. Extra build step
We are talking about small projects, build time is irrelevant. And .. well, tsx is all the rage nowadays.. which is almost 2 letters less than "node"
5. Dependencies
TS does not limit you to write only .ts modules. You can do your thing in any of the two dialects. If you run into some type issues with one of your dependencies, first, you should probably not use it because it is/becomes irrelevant, or you can type up your facade of that lib.
That being said, I sometimes don't touch TS for a single file project. As soon as I import anything, the glorified intellisense feature is already worth it.
However, here is the elephant. If you do your weekend noodling, you use whatever you want and nobody will be able to stop you. So my arguments are purely based on my experience. Your experience is most certainly different. If it works for you do it. But don't write an entire article around it. You aggravate both the religious people and the ones with divergent experience... which is .. at least 140% of us.
For commercial products, while you may go with JS alone do keep track of dev-ex and type related bugs, and transition when the time is right.
I give you 1 more, it is easier to type up a JS file than to JS up a TS file.
This feels like ragebait, but I'll take the bait. The examples you came up with are unfair comparisons, and really you're just reiterating two points:
anyeverywhereAddressing number 1. it's a config file. Even the config itself is typed so you get a list of all properties and autocompletion, so it's really not difficult to setup. The default config also works fine. If even that is too bothersome, then you can just omit it completely and run programs with Deno, Bun or even Node with the
--experimental-strip-typesflag. Then at least you will still get IDE type hints and it requires genuinely 0 config apart from renaming the file from.jsto.ts.as anyeverywhere you're either ignoring types returned by library code, meaning you're literally doing something that will not work during runtime, or you're re-using variables you define for different use-cases, which is probably really confusing even in JS.I agree that typing out everything is pointless in small projects though. That's why I always create ts files, but then only use types where I feel like it's helpful and then use deno or bun. Deno, bun and the node
--experimental-strip-typesSTRIPS types away, meaning it will run regardless of type errors, but your IDE probably uses an LSP which can still provide type hints while coding and highlight these errors. 0 config required; add typescript where you want; and ignore whatever errors you dont care about.Yeah, call me a cynic but TypeScript feels a lot more like training wheLls for you bicycle, or like you're riding a tricycles and waving at everyone who passes. I'm an old-school javascript hack who just woke up from 1,000 years of sLumber and i'm liKe, WTF. Just ride the biKe. i Know, it's noT saFe, yoU mighT sCrAp youR knEes, or bang YoUr heAd. 🧠 BrainS, mmmm. NoW i'm hunGry.
Downloading Minecraft for PC allows players to experience the iconic sandbox game on a larger screen with enhanced controls and graphics. You can download the official version from the Minecraft website (minecraft.net) or through platforms like Microsoft Store and Steam (for specific editions).
Worst advise ever. Chatgpt and Claude can setup a fully functional TypeScript project using Vite with websockets in 1 minute. Tell it you want darkmode and specify the layout. Skip all babel b.s. and linters because a compiler is 100% better.
I don't get why some people in the comments decide to take the worst meaning out of this blog post.
It's that simple. If I were helping a friend set up something to automate some of his tasks, I wouldn't use typescript. Just plain js.
But if I were building a website for production or at least something with a respectable amount of complexity, I most certainly would.
I don't always need to actually use ts for many small projects. IDEs and code editors provide enough intellisense to get you through, and since it's a small project, you don't have much to wrap your head around, unlike a huge project with tens or hundreds of files and data models.
It's that simple. This is not a "ts vs js argument" article. It's a "save some time by using vanilla JS instead of TS in relatively small projects" article.
Thank you for sharing! I agree with you. As with any other tool, the focus should be on the environment and goals rather than the technology itself.
As they say, the right tool for the right job...
However, too often technology is treated not just as a tool but as a quality certificate, which is absurd—no different from a high-fashion brand 🫤.
The TS config is fine, but I think each project has its own goal. Personally, I've had issues dealing with, for example, a BFF that needs to receive data from the backend. For every extra piece of metadata or data I want to pass to the frontend, I have to refactor the BFF as well and maintain two sources with models. In that scenario, I try to generalize the models as objects or arrays of objects to ensure they meet the necessary requirements
Yeah, I’ve had the same realization. I used to default to TypeScript for everything, but for quick projects, it just slows things down. If I’m building a small script or testing an idea, plain JavaScript is just faster and easier. TypeScript makes sense for bigger, long-term projects, but forcing it into every little thing is overkill.
TypeScript can slow you down if you're not familiar with it, especially if this is one of your first projects. However, JavaScript can also slow you down if you're inexperienced. Also, for an MVP, you don't really need fast coding; you're more focused on your product and how to implement it.
Your argument suggests that every type-safe language, tool, or framework is a hassle for an MVP.
Additionally, an MVP or prototype will become the large-scale software when it's successful—you don't rewrite it.
Great insights, totally relate to the time-saving perks of skipping TypeScript for quick projects!
I think for the most part, "in the field" this is a moot point because when you're working with teams, especially external teams for a client, you work with what you've got. When a project is due yesterday, you're not going to have time (or even care) to get on a soapbox to advocate TS or JS.
For what it's worth, if you're creating a new project with collaborators, it's good practice to use TS. For your personal projects, do whatever floats your boat 🙂
You don't want to use TS for side project, standalone scripts, MVP or Prototypes? Sure and I am happy this works for you.
Where TS works for me is when I comeback to my side project or standalone script to iterate on it after months, I get that instant feedback what my data/function signatures are.
Yes, JSDoc does it the same but it's verbosity is not something I have time for.
But again, whatever works for you, mah man! 💪
With my experience i would say this is totally misleading or wrong as per my opinion. No one has a Hello World program as small project, how small project would be typescript is needed. Also if u pick up nestjs for backend it gives ts template out of the box and u dont need to spend any time on setting up typescript. Moreover all frontend project generators support ts out of the box. Lets use ts for every project to make sure less errors during runtime...
Such a valuable post! I really appreciate it! 💖
Solid take on ditching TypeScript for small projects! I totally get the setup hassle and experimentation drag—JavaScript’s looseness is a blessing for quick hacks. That extra build step and dependency woes? Yeah, they’re overkill for a 500-line MVP. I’m with you: TS shines in big, team-driven stuff, but for solo sprints or scripts, plain JS wins. Curious—do you ever miss the safety net, or is it all freedom now?
I do Javascript for more then 20 years. I write native Javascript for big projects. No transpiling needed. Javascript with ESM is mature enough right now for big projects.
I would love to know more, I was working on a project that was a huge SAAS website, we didn't use TypeScript but I always saw this as a mistake because one day someone on the team caused a bug where if you clicked a button it would crash the site with a runtime error and let's say for example users couldn't make payments because that's where the bug happen. And ever since that happen I have had the believe that Typescript should be used in big projects.
Is your experience different?
There are a few more reasons why not everyone is a fan of typescript.
Here is a post I just wrote a few days back on this:
dev.to/javascriptwizzard/why-dougl...
No matter what's the need. Don't just use plain JS in 99% of the case. Typescript is built for a reason and I completely agree with @webjose
Ah, seems like it is a religion then...
Well, bun simplifies everything while using typescript
Interesting to read
I think this what are you prefer to, for me this is not problem, with AI editor (AI suggestion), JS or TS is not a problem for tiny or small project anymore.
You can also use swc compiler. It has no type checking. But very fast transpiled ideal during development!
Use deno.
Typescript is bloat.
PURE skill issues lmao
Better use TS in a multi-dev project.
And, for me, never join a frontend team.
Big L Take, if you know what you are doing, none of the things listed take time.
Not to start a war - but sounds like the right time to use Python.
The TypeScript examples you provided are very poor. You seem to have a limited understanding of it
all the points are pretty much wrong.. says a lot about the author
Can I not write console.log("hello world") in typescript?
By the way, Node is running typescript natively from V23.6.
That obviously might take some of the hassle away.
I did not know that! Neat.
I was on a team that wrote a very large project in TypeScript. It was TypeScript 0.8, so it was quite a while ago. The experience convinced me that TypeScript was a better JavaScript.
I had wanted to use CoffeeScript, or GorillaScript. But I came around to appreciating the benefits and the approach of TypeScript. (Some of those benefits from 0.8 are moot today. Now were at TypeScript 5.8, and it has provided an abundance of new feature benefits since 0.8.)
Yes, for sure It has come along way.
Also, most packages now offer first class support for types and you don't need to install their types separately.
Amen brother, preach!
I don't use typescript for anything honestly. I've been writing my own JavaScript since late '90s.
You are right actually. I've never thought about it earlier
Deno anyone? Do I need to say more? Just get in, do your project and get out. Once you get used to Deno, TS doesn't become a problem, but a much needed tool that JS should have implemented already.
Feels awfully click bait lol. Even the tsc and etc when you can just ts node or bun.
Yeah! This is the point! Love it!
Judging from this code, it seems like you might benefit from Typescript man.
Nice
Reading through this made me want to die
Are you still writing hello world by yourself in the era of generative AI
Good suggestion man👌
You can use Vite to setup a TS which makes the configuration of seamless.
Just setup with Vite and you're ready to go.
Best Programming Codes to Sell
Get the best programming codes — 5000+ codes to buy or download for free!
tinyurl.com/mubnxzwt
What project do you call "small"? For me 500 lines of code is not small enough. Maybe up to 50-100.