I always notate my functions with JSDocs and my DTOs as jsdoc types which in any modern IDE gives you the same advantages that you would get out of the explicit typescript interface/type.

And Unlike typescript my code doesn't need to be transpiled at all since it is already vanilla JS.

Discipline doesn't scale. https://www.sicpers.info/2020/10/discipline-doesnt-scale/ Add 10 people to your project and start forgetting some docs or failing to update them.

> Discipline doesn't scale.

I want a shirt with this on it.

The presence or absence of a compilation stage has nothing to do with static typing. Flow.js is static typing. MyPy is static typing. It sounds like your JSDoc comments are static typing, if your IDE ends up passing them through the TypeScript type checker in JS mode.

It may not be very comprehensive static typing but it is static typing none-the-less.

I'd say it reduces bugs... in size, making them harder to find.

Reduces bugs in size, or only leaves smaller bugs behind?

These are two very different outcomes.

If the remaining bugs are unrelated to the class of bugs that were eliminated entirely, then the difficulty in finding them has little bearing on the outcome, since we’re now talking about an entirely different class of bugs.

This is conjecture, but in my experience you'd get the following:

- in JS, your code will run with the bug then do something catastrophic during runtime that you can then notice and trace to the core issue

- in Java it won't compile, so you fix it so it compiles and runs, then it'll hit you in like 2 hours of runtime with a NPE or something and you'll have no idea what caused it

Maybe Kotlin, Rust, and the like solve that sort of thing better but I've yet to be convinced.

But is there any evidence that the NPE would have blown up catastrophically without type checking? Is the NPE even related to type checking?

It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all.

Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently.

- We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion.

- Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item.

The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping.

Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not.

This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs.

This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted.

What am I missing?