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
Displaying a subset of the total comments. Please sign in to view all comments on this post.
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. 😆
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.
You think jsdoc doesn't compile your code and jsdoc comments? How would it know what your comments mean if it doesn't compile them? It's time people start using their brains and realize what it actually means to add dependencies to a project.
That's the exact definition of a compiler :B
Dunning–Kruger effect is off the charts with this guy.
github.com/jsdoc/jsdoc/tree/main/p...
github.com/jsdoc/jsdoc/tree/main/p...
What do you think tsc does differently? It parses your source code and extracts type information, then it generates js code in the same way that jsdoc generates html from your code comments...
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.
Yes exactly. And we all know how it turns out right. We first start small.. Hacky the hack in JS. And suddenly you wish you have use TS or Go and a better framework.
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.
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.
Its call Transpilers not compilers..
Have a nice day.
Well JavaScript is the machine code in this case I guess, but yea, generally all compilers are transpilers, but not all transpilers are compilers 😛
You got a nasal exhale from me so take my like 😅
This is the way
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.
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 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.
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.
Today you can even use Node.js with Typescript code out of the box. Its not as good as Deno.. but we slowly getting there lol.
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 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.
thehackernews.com/2025/03/critical...
I created an account just to comment.
While I can agree with the sentiment, the arguments / reasoning leave a lot unsaid.
Use
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.
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.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
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!
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.
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.
I don't think you understand typescript man
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.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!
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.
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:
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.
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.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.
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.
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 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 strongly disagree.
It's not much of an overwhelming chain of tasks anymore.
Now that NodeJS supports transpilation of TS out-of-the-box without the overhead of building a pipeline.
We even have packages likes
tsxthat clearly makes it 0-config available in seconds.To be fair, I kinda agree, it can get a bit weird if your dependencies do not expose properly structured Typescript projects. However worst case is you can make the compiler ignore it by wrapping/casting with
any. I see no difference between wrapping everything withany | unknown | neverand using vanilla JS to depend on your IDE infer whatever it can to give insight. So worst case, you get benefits from wherever you can, and move on with JS where you can't. Remember, TS is a superset of JS anyways.You hinted on small-scale projects. Valid especially when you want to use one-off things, so you can make that decision.
At its core, TS is supposed to make JS feel like a core Programming language with error inferences and static type checking, as others do. So yes, it can be an extra hassle to set up, but I will still stick with TS, regardless of project scale cos... After the initials, it is basically ready set, go.
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.
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).
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.
Online Quran classes with Tajweed for kids and adults provide a convenient and effective way to learn the correct pronunciation and recitation of the Holy Quran from anywhere in the world. These classes are designed to cater to all age groups, ensuring that both beginners and advanced learners can improve their Quranic reading skills with proper Tajweed rules. online quran classes with tajweed for kids & adults
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.
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
Great insights, totally relate to the time-saving perks of skipping TypeScript for quick projects!
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?
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 🫤.
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! 💪
Clearance renewal Philippines also plays a key role in streamlining public and private sector operations. Many institutions—such as banks, schools, real estate agencies, and government offices—require updated clearances to process transactions involving trust and accountability. Whether applying for a loan, securing a business permit, enrolling in a university program, or bidding for government contracts, individuals are often asked to present valid and current documents that prove their legal standing. This requirement helps create a culture of transparency and ensures that everyone involved in formal processes is held to the same standards
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?
Yes it is. Debugging nowadays is great in vscode. You debug directly on the running javascript code, nothing in between can cause hickups. ESM makes it possible to stucture Javascript code great for big projects. Typescript is developed by Anders Heijlsberg, the static guy, he wants everything static. Funny is another guy at Microsoft went the other way. In C# you can use "dynamic" to create Javascript like objects. Its compile vs runtime. In Visual Studio C# you develop at compile time and can find errors then. With javascript you run and then find errors. The magic happens with NodeJS, much faster as Visual Studio running a program. I can much faster develop because iterations are faster in NodeJs.
But there is a catch. I happen to be a 40+ years experienced developer. I dont need the static thing of Typescript. So everything goes smoothly my way. Inexperienced developers are guided by the static nature of Typescript.
But remember if you compile a program and that runs it still can create errors. A badly designed program is not helped with Typescript.
I don't even...
Its just a tool! Got tired of articles like : Why you should/shouldn’t use _______ and You should stop/start using ______.
Use whatever the project requirements require! You know - that tool that will do the job and is a best fit for the use case!
Those are tools folks, learn it or reject it, either is fine, no need to rant about it in the form of articles!
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 🙂
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! 💖
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.
Project scale isn't the deciding factor. Think long-term. For throwaway code, CommonJS works. However, if you foresee needing to understand or build upon this code later, TypeScript's static typing offers significant advantages in terms of clarity and maintainability, essentially self-documenting your work.
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...
Typescript for large scale projects? Its compiler is slow asf, everytime you run some tests or the Nest dev server it takes century… if you wanna write some typed code why not Golang or Rust? On the React side, the components are types themselves, why would one need typescript for react logics… i wish one day the dev world should wake up and see what we (you?) done… A typed language that compiles to JS lol…
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
No, it's a religion.
Feels awfully click bait lol. Even the tsc and etc when you can just ts node or bun.
Not to start a war - but sounds like the right time to use Python.
Typescript is bloat.
You can also use swc compiler. It has no type checking. But very fast transpiled ideal during development!
I Built A $1M App In 5 Hours
But this story hit your argument hard.
He uses typescript.
You are right actually. I've never thought about it earlier
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.
Better use TS in a multi-dev project.
And, for me, never join a frontend team.
PURE skill issues lmao
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
Use deno.
Amen brother, preach!
I don't use typescript for anything honestly. I've been writing my own JavaScript since late '90s.
Big L Take, if you know what you are doing, none of the things listed take time.
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.
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.
Can I not write console.log("hello world") in typescript?