TypeScript is now officially 10 years old

I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.

>At the moment vscode only checks files that are currently open

While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality.

>I think type checking should only be done when building to some sort of production or realtime in your editor.

Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't.

>Templates like "create react app"

...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.

Many bugs are trivial until they slip into production.

>You’re right on the first

Strictly speaking, it takes exactly one such behavior (that you cannot even disable) for TS to stop being a superset of JS.

>although classes are out of fashion, so this is low impact

Looking at the TSC codebase, so are keyword arguments. The "in" thing is just to write very very long lines of multiple verbosely named positional arguments instead.

That said, "clases are out of fashion" is a complete non-argument. I'm of the functional persuasion, yet I've found that classes are the ony way to write TypeScript that fits on your screen at all.

Especially now that classes are being introduced in JavaScript proper, and of course TypeScript does them only slightly differently (handling of default property values and "definedness" differs).

>On the second, doesn’t this work?: ‘function foo({ bar = 3 }: { bar?: number })’

You also need a `= {}` there, otherwise you'll need to call `foo({})` - it won't let you call `foo()`. This is also in JS though, so a bad example of TS breaking things (`function foo ({ bar })` still won't work though). There are probably better ones that people encounter, work around, and forget about, because nobody's listening anyway. "The code making sense is not important, what's important is helping the user" lol.

Now imagine how the above looks with 5-10 kwargs (because keeping context in the class instance is "out of fashion", so it's either a ton of args per function or a "context" record which is effectively reimplementing classes but with a worse experience), and an aggressive formatter insisting every individual thing has to be in its own line.

Here's another: failing to infer the type of `this.constructor`.

Sure, the constructor signature may change in a subclass (why not disallow incompatible constructor overrides, given incompatible property/method signatures are already disallowed?); then what about static methods accessed via `this.constructor`?

So you end up defining an interface type for the constructor and using `(this.constructor as MyConstructorType).staticMethod` or whatever. Which is just visual noise where the fucking intent of the code was previously clear as day, so clear that TSC should've been able to infer it (yeah the type inference also sucks).

Also, ever seen TS2322? It's my pet now. What it do

All in all, TS really puts the "Java" back in JavaScript, and then some.

EDIT: Also crap like not being able to have a question mark and a default value in positional arguments so you gotta add `|undefined` there. Even the stuff it adds on top of JS is poorly thought out.

I wouldn't waste time buying/using a book to learn TS. If you have experience in any statically typed language you should be able to pick up the basics just by a quick peruse of the TS docs.

And then even if you don't I'd still say reading the docs and just browsing existing code assuming you already know JS would get you all the way there.