Unpopular Opinion: TypeScript is Overrated (Or Is It?)

I wish there would be a strongly typed version of JavaScript. At least the damned numbers! I hated TypeScript even more than I hated flow, but adopted it for the reasons OP described.

I hate dealing with JS bundlers and compilers, so I use Deno for my side projects and push through with Vite and such elsewhere.

I’d say it’s a “love/hate” relationship for me because I need types (but hate writing them) and I love flexibility JavaScript gives me.

function add(a: number, b: number): number {
    return a + b;
}

The return type specification is not needed here. The following yields the exact same result:

function add(a: number, b: number) {
    return a + b;
}

Is it verbose? Yes.
Is it strictly necessary to avoid havoc? Yes.

The sole fact of having the compiler and the type checker yelling at you while coding is pure gold. Without it, you can use millions of misnamed or simply undefined stuff or even slightly out of type variables in JS and only find out at runtime, or even never. Or maybe a user doing an edge case will find out.

The only real pain of TS is setting it up in Node.js. That is generally so bad that using a boilerplate religiously is your only option.

The strength of typescript is in the type inference. Because of type inference you don't have to (should not) provide specific typings for a lot of things:

const foobar = 'hello' // it's a string in typescript 

function add(a: number, b: number){
  return a + b // it returns a number no need to specify return type
}

This reason I prefer the JSDoc, I also use for small POC app, because so much nicer : JSDoc vs. TS

I once worked on a project where TypeScript was used so wrong that it in fact made development harder (wrong/misleading types so runtime objects differed from what TS was saying). It's a shame, because I really think that TypeScript used right is super helpful. It doesn't have to be verbose either. You only need to type the arguments that cannot be determined automatically. For example, in the example you provided you don't need to type the return type - it's automatically inferred and will show you the type. Some people argue that you can use jsdoc instead, but that's just even more verbose...

My take; Use only as much TypeScript as you are comfortable with - it's modular by design, so you can use as much or as little as you want - and only type function parameters, or external data responses. Almost never use as, and ESPECIALLY never use as any. If you're using as any, you are basically saying "idc about this bug, let's pray it doesn't happen". as is also dangerous because you're saying that the type is actually something else than what TS is saying. That only happens if 1. There's a bug in TS, 2. You have written as ... somewhere else and it was actually wrong, or 3. You have received external data which cannot automatically be validated.

1. Is very unlikely
2. You can avoid by rarely using as ...
3. You should only use after validating the object manually. (e.g. if (typeof obj.name === string) obj as { name: string } else handleMalformedData(obj))

Typescript is a tool. Like any tool it can be used wrong. People who agree with the cons listed have mismatched expectations or misunderstand what Typescript is for. The people who expect the language to fix all bugs or prevent them from writing bad code are severely misguided.

I would advocate for the use of Typescript in all of the skip scenarios. The setup and use only appears convoluted to the Typescript newbie.

One criticism I have:

"TypeScript can turn a few lines of JavaScript into a sprawling mess of declarations" is followed by a contrived example even though it's true. What you've shown with the number types is just point of Typescript. It's hard to come up with a good (bad) example but we'd all know it if we saw it.

For me, switching from JS to TS was a total game-changer and sped up development massively. Especially when working in a multi-repo situation where there is code shared across frontend and backend, being able to define interfaces ensures the backend and frontend stay in sync. There is definitely a learning curve and troubleshooting compiler errors can be painful but I'd pick that over plain Javascript any day.

JS + TS = C++ ?

It is a common misunderstanding that static type are the only thing that distinguishes languages like C++ from Javascript. A compiler does far more checks than the Just-in-time compiler a JS-engines provides. It can find dead code, does tree shaking, finds errors in code that is not often visited, finds unused variables etc..

Using static types in JS gives you some kind of checks. But in some way it also limits you. Often JS allows to write elegant code that would be much more verbose in other languages.

I´m not sure which one is better. I have beed using compiled languages for a long time, but the reason my JS code crashes is - in most cases - not caused by the missing type annotation. Dynamic types surely enforce a different style and some additional type checks. But TS is not a silver bullet to write error free code.

No offence to anyone, but at least for the frontend/browser environment:
ts = bs
imho.
90% of it is bs.
Simple types: that's good, but that's 10% of ts.
ts was just a utility, now it's a language? i don't think so.

You find yourself needing more than just the simple types from ts? I would take a step back and evaluate. You're making it way way too complicated. Adding layers and abstractions which are totally unnecessary. Think small. (Think component.) Especially in a React app you should lean on React and principles of component based programming to keep your apps simple and safe and maintainable.

Frontend/browser: is a very different environment than the backend/server.
There are very good reasons why js is different than cs.
-- Wouldn't it be nice if we pumped cs into js, and call it ts?
And keep pumping until it starts looking like Perl.
Great. Love it all you can ;o)
To me it's just a tool, 10% of it "is" useful.
Add simple types to js, and ts would be redundant.
Me thinks.