I am increasingly starting to think there are two very distinct engineer types.

1. Engineers who are so damn experienced in FE JS they don't have type related bugs in their code.

2. Those who jumped early on the TS bandwagon and assume the alternative is tons of JS bugs because of types.

While I'm not against types per se (nor does the article claim I am), if you go by which are the most popular languages (Python, JS, etc), you could very well argue that not having types is far less a problem than type-fans suggest/assume.

Now, the errors on this page. I haven't looked at them, but think from a user perspective. The product works, so these might be but red herrings. Perhaps some race condition, or a plugin blocking something, or something like a React inefficiency or semi-correct use of a useEffect. The causes could be many, but as long as the UX doesn't suffer, there may or may not be a legit reason to even care.

You mentioned something about discipline. Praying to God is not involved in JS, btw. 🙂 Discipline though, I think you may be onto something. Perhaps those of us (roughly 50% of JS devs) who don't run into the issues TS devs love to bring up, have developed a certain subconscious discipline.

To answer your first question, imagine this. Every day at least one engineer on your team moans about having to figure out some weird type or interface in the code, another one asking for a huddle to solve the same thing, or simply just having to read code full of types. Have you seen a React app written in TS? I think it's barely readable because of course we're not talking about the simple types anymore like string, numbers, etc. And then you find yourself having to Google why that weird React type isn't the correct one, and need another even weirder one. All the while if you just wrote it in JS, it would have worked just fine. Those minutes add up, and assuming the struggle goes away over time would be false, because people come and go all the time, so you'll always have a few engineers struggling. That's just ONE of the productivity dampening aspects.