Discussion on: To TS or not to TS, that is NOT the question. Is it?

[JoelBonetR 🥇]

TS is a good addition to JS, but there's no tech to rule them all. There are few disadvantajes on using it:

• More initial setup.
• Additional learning on top of JavaScript is required.
• Larger compilation/transpilation times.

We need to be honest about what we use. Knowing the good and the bad things of what we use helps us improving our work, fanboying something usually tends to a blid-following which is usually not good.

[Rense Bakker]

The first 2 are true for JSdoc as well, with the disadvantage that JSdoc does not enforce type safety. If people forget to update it, your code will fail in runtime.

Compilation time (in milliseconds) is a very small price to pay for actual type safety. It saves me many hours of trying to debug a JavaScript runtime error.

[JoelBonetR 🥇]

1- I'm not saying that TS is bad in any piece of this texts.
2- JSDoc is PART of JavaScript, hence of TypeScript.
3- No, you can't have outdated docs with TS-Pragma, it will take care of that plus you can use ESLint JSDoc plugin just like you do in any project.

[Rense Bakker]

1 - no you just spread false info about TS in an attempt to make it look worse than your beloved JSDoc.
2 - Comments are part of JS, JSDoc is a specific way of formatting your comments so that they can be interpreted. Thats definitely something you need to learn.
3 - or you can just dump a tsconfig in your JavaScript project. Do npm i --save-dev typescript and voila. Suddenly all your JavaScript code became Typescript code and you can benefit from type safety. Commit it and your whole team benefits from the same type safety.

[JoelBonetR 🥇]

Sure you can use TS as dependency in your project. If you read the post it's written on it. JSDoc REQUIRES TYPESCRIPT to work for that type checking, again is explained in the post, using TS Pragma.
TS has more features than what you can reach with TS Pragma + JSDoc but most of the mortals don't always need those features, that's the key point on that. Is a less strict, hence more flexible way of having type-checking, inference and so. Again, it's explained in the post.

[Rense Bakker]

Except your JSDoc approach is not more flexible. Everyone on the team will have to atleast learn the basics of JSDoc. Usually that doesn't happen though and people just copy paste doc blocks from other parts of the code, forget to change it and create a gigantic mess. If you need less strict typings, you should probably ask yourself why. What kind of mess are you trying to create?

The Flexibility that you speak of is something that Typescript does provide and exactly what makes it so powerful. Because it is a superset of Javascript, every developer who knows Javascript can start using it, without having to learn anything. The only difference is that Typescript is a Javascript flavor that doesnt allow you to create a mess, like having a function getCat that returns a Cat and then later using that result as if it's a Dog (aka type safety). Devs on the team who have more experience with Typescript features, can apply their knowledge to provide properly typed functions/libraries for the rest of the team to use. When team members are curious about how to type things more efficiently (which happens often when they stumble upon things during code reviews), you can plan an afternoon with them and explain Typescript generics or other features to them.

To me, the JSDoc approach just looks like at some point you wanted to use Typescript, but when you did, Typescript told you that some of your code was not type safe and instead of accepting that and learning how to fix it, you decided to look for a way to convince yourself you didn't do anything wrong.

[JoelBonetR 🥇]

you can do all those things except for generic types with the approach suggested in the post and none of the issues you try to bring upon the table are right.
Why don't you create your own post praising the goods of TS instead bothering on other's posts with things you didn't even tested?