Why Stop Using TypeScript for Small Projects?

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

Well, not always.

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

---

1. The Setup Overhead Isn’t Worth It

Let’s be real—TypeScript requires setup.

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

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

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

A simple JavaScript file just works:

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

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

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

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

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

And that’s before setting up the build process.

---

2. TypeScript Slows Down Experimentation

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

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

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

In TypeScript? Now I need to define types:

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

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

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

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

---

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

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

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

Bad example:

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

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

---

4. The Extra Build Step Feels Unnecessary

With JavaScript, I can run my script instantly:

node script.js

With TypeScript, I have to compile it first:

tsc script.ts && node script.js

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

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

---

5. Not Every Dependency Plays Nice with TypeScript

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

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

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

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

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

---

When I Still Use TypeScript

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

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

✅ Projects with long-term maintenance in mind.

✅ Codebases that rely heavily on strict contracts between modules.

But for:

❌ Side projects

❌ Quick scripts

❌ MVPs and prototypes

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

---

TypeScript is a Tool, Not a Religion

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

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

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

Comments

[José Pablo Ramírez Vargas]

Huh? Clearly you don't understand TypeScript.

console.log('message');

The above is TypeScript. Your example:

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

Is just unneeded.

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

Hmmmm, maybe you do.

---

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

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

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

[Itamar Tati]

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

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

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

[José Pablo Ramírez Vargas]

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

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

[Itamar Tati]

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

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

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

[José Pablo Ramírez Vargas]

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

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

[Itamar Tati]

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

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

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

[José Pablo Ramírez Vargas]

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

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

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

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

The following type tells a story:

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

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

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

[Itamar Tati]

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

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

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

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

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

[Ben Sinclair]

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

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

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

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

[Itamar Tati]

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

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

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

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

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

[Eric B]

I agree with your sentiment, and just want to add this to everyone else reading:

Bun, deno and node with the --experimental-strip-types flag 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.

[Arnaud Gathy]

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

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

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

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

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

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

[Joshua Amaju]

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

[Rense Bakker]

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

[Joshua Amaju]

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

[Rense Bakker]

What point? That was my first response to you.

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

[Melroy van den Berg]

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.

[Rense Bakker]

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

Typescript is not Java.

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

Typescript is not Java.

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

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

[Melroy van den Berg]

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

[Rense Bakker]

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

[Joshua Amaju]

You've never heard of zod?

[Rense Bakker]

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

[Joshua Amaju]

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

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

[Rense Bakker]

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

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

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

[Melroy van den Berg]

The reason you still want runtime checking is because during runtime Javascript objects/parameter inputs can still change. (I have been there..). Meaning you might expect an integer while its a string or visa versa.

This can still lead to serious production issues! Like even crashes or undefined behavior or at best errors.

And in fact this is one of the reason I do not like TS that much anymore for a backend code, while I still have several projects in TS. So do not get me wrong.

[Rene Kootstra]

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

[The Jared Wilcurt]

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

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

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

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

[Daj Bry]

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.

[Rense Bakker]

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.

"The JSDoc tool will scan your source code and generate an HTML documentation website for you."

That's the exact definition of a compiler :B

[Peter Vivo]

If configured well the JSDoc then even don't need to use '// @ts-check' on top of file.

[Tertiumnon]

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.

[Melroy van den Berg]

Its call Transpilers not compilers..

Have a nice day.

[Rense Bakker]

Well JavaScript is the machine code in this case I guess, but yea, generally all compilers are transpilers, but not all transpilers are compilers 😛

[Himanshu Sorathiya]

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

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

[Paul]

[Andrew Bone]

You got a nasal exhale from me so take my like 😅

[David R.]

This is the way

[Cyan]

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

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

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

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

[Melroy van den Berg]

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.

[Itamar Tati]

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.

[Rense Bakker]

It's really not. The code examples are complete nonsense. Zero typescript developers in the history of typescript have written this:

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

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.

[Itamar Tati]

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.

[Rense Bakker]

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.

[Itamar Tati]

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:

const Directions = {
    N: { Right: "W", Left: "E" },
    E: { Right: "N", Left: "S" },
    S: { Right: "E", Left: "W" },
    W: { Right: "S", Left: "N" }
};

function turn(direction, move) {
    return Directions[direction][move]; 
}

// Works fine in JS, but TS will throw an error:
// "Element implicitly has an 'any' type because expression of type 'string' can't be used to index type"
console.log(turn("N", "Right"));

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.

[Eric B]

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:

const Directions = {
    N: { Right: "W", Left: "E" },
    E: { Right: "N", Left: "S" },
    S: { Right: "E", Left: "W" },
    W: { Right: "S", Left: "N" }
};

function turn(direction, move) {
    return Directions[direction][move]; 
}

console.log(turn("N", "Right"));

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:

Now, if your argument is “But this still runs in TypeScript”—then what’s the point of using TypeScript in the first place?

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:

const Directions = {
    N: { Right: "W", Left: "E" },
    E: { Right: "N", Left: "S" },
    S: { Right: "E", Left: "W" },
    W: { Right: "S", Left: "N" }
};

// A little sprinkle of optional TS 
function turn(direction: keyof typeof Directions, move) {
    return Directions[direction][move]; 
}

// Now my IDE autocompletes "N", "E", "S", "W".
console.log(turn("N", "Right"));

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.

[Itamar Tati]

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.”

const Directions = {
    N: { Right: "W", Left: "E" },
    E: { Right: "N", Left: "S" },
    S: { Right: "E", Left: "W" },
    W: { Right: "S", Left: "N" }
};

function turn(direction, move) {
    return Directions[direction][move]; 
}

console.log(turn("N", "Right"));

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.

[Rense Bakker]

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.

[Itamar Tati]

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.

[Eric B]

@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.

“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.

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 tsc does - 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.

“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

These are all examples of TypeScript being used incorrectly.

• The Setup Overhead Isn’t Worth It

There is no overhead unless you're doing a web project without a framework, which to that I'll ask why?

• TypeScript Slows Down Experimentation

How? You can write plain JS in a .ts file 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.

• TypeScript’s Benefits Aren’t That Useful in Small Projects

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.

• The Extra Build Step Feels Unnecessary

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 dev or bun index.ts.

• Not Every Dependency Plays Nice with TypeScript

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.

1. 90% of websites don’t need TypeScript.

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.

1. Adding complexity to a small project introduces a new point of failure with little to no benefit.

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.

[Rense Bakker]

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.

[Itamar Tati]

@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.

[Itamar Tati]

@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.

[Rense Bakker]

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.

[Rense Bakker]

No you disagree on facts. You make up your own.

[Eric B]

@brense I don't think you're discussing this constructively anymore and you've already closed out any argument @itamartati has to make. I haven't read your whole discussion, but if you feel the need to mock someone's misunderstanding, then I suggest you ignore them instead or point it out respectfully. Bundling and minifying is not required for small projects such as we're discussing. What others do is irrelevant too, if everyone is doing it for a reason that's not relevant to us (e.g. bundling and minifying large websites to reduce load times - small websites are already pretty much instantly loaded). I would still agree that bundling and minifying code is important and should be done in any project, but I @itamartati still raises a valid point on whether that (small) complexity trade-off is worth it for small projects. It depends on the goal of the project.

Anyway, going back to your points @itamartati :

“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.

I don't know the exact numbers, but I'm happy to assume that most of the internet doesn't use a modern framework and comprises of legacy code. But here as well, what others are doing is irrelevant - why they're doing it may be relevant. I think the why is mostly because of 1. lack of skills and comfortability in modern frameworks / the complexity it adds and 2. legacy code bases where the trade-off for upgrading to a framework is not worth it. These are both completely valid points, but irrelevant under the assumptions in this discussion. Also tooling has improved significantly, so the setup cost is just a single command: bun create <framework>.

I'm arguing that if you were to create a new website from scratch now, I don't see why you wouldn't use a web framework in almost all cases. I'm not even sure you can argue that working without a web framework is simpler, because you miss out on a lot of packages and plugins that enable a ton of features with extremely little setup compared to plain HTML/JS/CSS. Even just updating an element dynamically in legacy HTML would require you to inefficiently search and update the element in the DOM everywhere you use the variable.

Frameworks also enable out-of-the-box hot-reloading, an enormous ecosystem of packages and plugins (think of vue-use, shadcn, SEO handling), optimized and simplified handling of state (which is often used in websites) and even input sanitation to prevent injection attacks which have for a long time been one of the most common vulnerabilities in the web.

All these things add up to make it worth using a framework in my opinion. Do you agree that if you were to start a project today that required just a few pages and uses web requests, updates data in the DOM and has some user interactions, you would very likely benefit from at least some of these things that a framework provides?

“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.

I agree, it won't run. This is relevant for non-web projects, which still is very a valid use case for TypeScript even though node wasn't popular when it was developed.

“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.

You don't have to create them - my point is that you can deal with any types. Now you're at the same place as if you were using JavaScript where everything is of type any. If the library updates its types it will not break your implementation in unexpected ways. You can still run the transpiled files (or run them directly with deno, bun and node with --experimental-strip-types) - it will just tell you exactly which properties or types are now invalid and show you those errors in you IDE, in a build step if you have that, and if you invoke it manually. Now you have explicit highlighting telling you were the API changed and what types no longer exist. In JavaScript, you would have no indication that it doesn't work anymore and instead have to run it - see it fail - and then follow the stacktrace to which library it's coming from and then search up the changelog of that said library and find what specifically changed and then update your javascript code accordingly. I prefer to click ctrl+. or ctrl+space in my editor and get a list of all the updated correct properties and types of a library.

“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.

I just disagree with this. I've never felt limited by a web framework in terms of experimenting, and because of all the previously mentioned benefits, I've always used a framework unless it's for testing a single bug, feature etc.

“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.

I can't say I'm a professional at all, nor do I have a wide variety experience using TypeScript, but I have never experienced TypeScript configuration being such a big problem. So I can't really say anything on that experience.

Lastly, I appreciate your willingness to discuss this topic in a mature manner. It's definitely got me thinking and understanding why I use the tools I do, and think back to how I work.

[Rense Bakker]

Thank you for repeating all the points that me and others already tried to make to this person, in a very lengthy discussion, that gave them ample of opportunities to be constructive. I'm a big fan of constructive discussions, but this person has done nothing except making up "facts" and numbers and tell factual lies, that can be disproven easily by reading documentation, which they refuses to do. Everytime their "arguments" are disproven, they just move the goalposts and make up another lie.

[Itamar Tati]

@eric_b_67cb420d1a0eddc900 , want to start with saying thank you and that I agree, engaging in these debates helps me further understand TypeScript. There are a lot of things that I have learned that I didn't know, like that you do not need to compile TS into JS on server code anymore or how little you are trading to use TS. So thank you, I have also learned from the more anti-TS crowd, so thank them too.

"I'm arguing that if you were to create a new website from scratch now, I don't see why you wouldn't use a web framework in almost all cases."

While frameworks offer convenience, they often come with significant limitations for creative projects. As I experienced with my card game project, Angular forced me into a specific component architecture that complicated what should have been simple interactions between cards. This rigidity limited my freedom to experiment with alternative approaches. Frameworks are built for common use cases, not for unique or experimental projects that require unconventional DOM manipulation or data flow.

"I'm not even sure you can argue that working without a web framework is simpler, because you miss out on a lot of packages and plugins that enable a ton of features with extremely little setup compared to plain HTML/JS/CSS."

The simplicity of plain HTML/JS/CSS is precisely that you don't need these additional packages and plugins, which each add complexity and learning curves. When building small projects, direct DOM manipulation gives you complete control without needing to understand framework-specific abstractions. There's value in understanding the fundamentals before adding layers of abstraction.

"I've never felt limited by a web framework in terms of experimenting, and because of all the previously mentioned benefits, I've always used a framework unless it's for testing a single bug, feature etc."

Your experience differs from mine. When I tried to build my card game, the framework's constraints became evident. Components that couldn't directly communicate forced me to implement complex state management solutions for what should have been straightforward interactions. This added unnecessary complexity to my experimental project. What works for enterprise applications doesn't always work for creative endeavors or small projects with unique requirements.

"I have never experienced TypeScript configuration being such a big problem."

Your experience with TypeScript configuration may differ from others'. The fact that frameworks now commonly handle TypeScript setup for us acknowledges that this was previously a significant barrier. Outside of established frameworks, TypeScript still requires considerable setup that can distract from the actual development of small projects.

I appreciate this discussion as it's helping me understand both sides better. I'm not arguing that frameworks and TypeScript are bad - they're excellent for many use cases, particularly enterprise applications. My point is that they aren't universally the best choice for every project, especially for small, experimental, or unique applications where their constraints can outweigh their benefits.

Can I ask why you use TS over something like C# for server development? Just curious.

[Eric B]

I'm not really that experienced, so I can't reasonably give any good reasons for why/when I would use TS over another language. I'm just personally a fan of Typescript's type system, since it doesn't feel like a hardware implementation (e.g. thinking of variables as 4-byte signed integers vs an 8-byte unsigned integer or whatever), but more as a logical "what data am I working with" type system.

For example in languages that enforce static types, you sometimes need to be aware of the actual "hardware" type for it to be compatible with others without losing precision, or you can't sum two numbers of different byte-lengths. In a way, TS follows a more mathematical notation and allows you to use union types, partial types etc. to logically describe what the data is, while I think statically typed languages expose the hardware representation of data in bytes of memory and allow more control and awareness of what's actually happening to the memory. I just find TS faster to develop with and the performance is actually not too bad, but I'm also most experienced in it.

I'm not sure any of this is to any value though, because I'm really not that experienced, and I would love to try a lot more languages and learn their "quirks" and understand their philosophies before I say one thing is better than the other. The only thing I feel fairly confident on is that TypeScript used well is way way nicer to work with than JavaScript (although I agree that everything is a trade-off between complexity (which decreases efficiency) and increased productivity (which obviously increases efficiency)).

[Saikat Dutta]

Again bad comparison 😕

[Levi V]

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.