Ask HN: Is TypeScript worth it?

> If it is your side project or if you are like 2 people working on a project then I would say it's probably not worth it.

I have several frontend side projects and they all use TypeScript. The static types makes it way easier to write & refactor even if you're working alone. I have also more confidence in my code and spend less time following JS trails to track stupid runtime bugs. Older projects are easier to pick up again.

Any project that goes beyond a few trivial files will benefit from Typescript.

I think stuff like this really comes down to getting used to and accepting.

I had the same views on code prettiers. I thought, aligning your code by hand makes you think about the structure. That you'd invest more time in making your code readable and thus it would be more readable.

When I first got to use prettier on a team and accepted it's value, the benefits I perceived were so vast, that my arguments seemed irrelevant in comparison.

Let's think about what happens on a team: If a single person goes and reads the source code to learn how the public API works instead of simply using the exported types, that's a wasted thirty minutes instead of two - okay, fine, whatever. If all of my engineers have to do this, suddenly each of them is spending that amount individually; and just like that, we've wasted an entire man-day, for nothing.

As you declared in your own comment, TypeScript is great for reading, hard for writing. I don't know about you, but my code is read several times more often, and by different people, than written. TypeScript is a no-brainer, time-saving wise.

How big is the team that you work with ? The benefit really shines in a large project with lots of devs.

Yes, in all cases except proof of concepts only demoed once. And even then probably still.

i) You can wait years to update TypeScript itself. I've never run into incompatibilities before.

ii) That's the libraries' fault. Without types, you can pass in total garbage and it doesn't work. With types you can only pass in some garbage and it doesn't work. All the Javascript examples work in TypeScript except now you will be warned that your code won't work before you try to find edge cases to test.

I've had the pleasure to use Frida a while back. It allows you to instrument running native applications using hooks written in various languages, though the live debugger usually uses Javascript. The documentation of many functions is scarce, to say it nicely. Without the TypeScript bindings, I would've never gotten most of these functions to work. You can find example code online but half the time that example code will be buggy and not do what it appears to do exactly because there is no type check on the plain JS API.

iii) I disagree, they're verbose but not that difficult to read. "You specified this but the type doesn't exist" or "you didn't specify this thing the type needs" is almost always the problem, it's just a little over eager to tell you where you're missing something.

iv) Okay this is definitely a downside. If you're not using Babel or another transpiler/minifier/obfuscator already, you'll add an extra build step. A minor one, in my opinion, but a build step nonetheless.

In my experience, TypeScript isn't making progress slow. It's making you fix your bugs and broken promises before the customer calls that your code doesn't work anymore. If you're passing strings instead of numbers you're going to break your code eventually, only now you'll have to get your code to working order beforehand.

Working on a codebase that's a few years old and added typescript retroactively, my experience is that renaming JS files to TS will instantly show you three to five bugs in every single JS file you come across. Import errors all throughout the code base, because it turns out components got reused wrong and what seemed like an optional label that didn't have any contents was actually broken for five years.

TypeScript gets even better with a nice and strict set of linter rules. Not just the builtin ones, also extra stuff like "don't use any everywhere to avoid typing things" and "specify what you're returning when you're returning something". With the stricter guarantees the language can deliver because of types, the code quality analysis can be a lot better as well!