> Is there a link where they say they spent 38% of their development time on this?

No there is not. The comment you're replying to has no factual basis for this claim.

Nor is there a basis in the article for 'what these Javascript devs are calling "The Typescript Tax"'. In the article there's one comment that refers to such a tax, but the commenter doesn't claim to agree, and every reply disagrees.

Nor is there a basis in the article for "Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming." The article says nothing about the total quantity of bugs, bugs per line of code, or other comparable metric.

The comment you're replying to seems to have a predetermined agenda tangentially related to the article.

My apologies, I was commenting very generally regarding attitudes typical of Javascript developers I have encountered in my professional life, rather than addressing the article directly. Also, you're right. 38% of development time is not the same as 38% of bugs, mea culpa, but there is an overall point to my statement about the productivity cost that I believe remains correct regardless.

You gained more reputation by owning your mistake than you lost by making it.

You’re correct, but it’s also true that debugging is often a greater percentage of time/effort than the original coding, so 38% of bugs is nothing to sniff at.

Although typing bugs are often the simpler type of bugs to fix.

The bigger problem is that "Simple fix" !== "Simple ramifications". Runtime issues caused by missing very simple typing bugs can bring down critical systems in Node. I worked at a company where a payment batching system built ( not by me ) with a MongoDB database failed to work correctly because the aggregation query was checking a field was `null`, without checking if it was there in the first place... No one even noticed for several weeks until someone finally investigated the low volumes. That's a very kind example too, just because they're simple to debug when they pop up doesn't mean that they won't cause massive destruction in prod.

This is only true if the bug is caught by the runtime checker. Lots of type bugs aren't, especially in languages with type coercion.

Until they’re not. I’ve had some codebases where it took 3-4 hours to figure out that some really bizarre issue was really just a type bug. And I don’t consider myself a terrible debugger.

Obviously. Any distribution will have some exemplars toward the tail.

I don't think that's really true as a general rule. Passing a variable of an unexpected type or nullable could have completely unpredictable behavior depending on what assumptions the code makes about the incoming parameter. It could have no effect or a catastrophic one, there's really no way to know without reading actual code.

So true and simpler to detect too.

The kinds of bugs which TypeScript prevents are those which could have been caught by the simplest of integration tests using the simplest inputs.

Every time I rename or change something in TypeScript, I have to change it in so many different places. In JavaScript, changes where much more localized.

Not at all. Typing bugs often leave code looking perfectly fine until you discover that one of the variables you expected to be y was actually x. And the only way to find out is to just print out everything

Can happen with TypeScript too. There is no runtime type checking so if you parsed a JSON object and cast some unknown property `const result = someRemoteObject.someUnknownPropertyWhichIsAString as number`, it doesn't guarantee that the result is actually a number. You still need to do actual schema validation just like with old school JavaScript.

Better languages solve this. In haskell you define a datatype for json before you parse it.