You are completely correct. JSDoc is significantly less overhead, compile-free, easier to read, easier to write, easier to understand, easier to migrate one way or the other, is fully supported in all IDEs and has been for years before TypeScript even existed.
There is literally nothing TypeScript can do that JSDoc cannot do except some extra language functionality like decorators.
The reason TypeScript is being widely adopted is for 2 main reasons:
1) Hype and the fear of being left behind
2) Most developers who think TypeScript is amazing don't know JSDoc exists when they go on their learning stint with TS and by the time they find out JSDoc does exist, it's now alien compared to the thing they just taught themselves to use.
TypeScript like every other compile-to-js thing is a TOOL. The reason TypeScript sucks as a tool is because it gets in the way of productivity, adds expensive time consuming extra code and compilation steps / time and is less readable and less fun.
It also reduces speed across the ground significantly, reduces the flexibility of your code to adapt to developmental changes as the project progresses and significantly increases the "noise / support code" to "actual functional code" ratio in your files.
JSDoc on the other hand is unobtrusive, works everywhere without installing anything other than the IDE, has been around FOR YEARS, is very easy to read and write (including most of the IDEs being able to WRITE IT FOR YOU 90% of the way), can operate at dev time and compile time (yes, it is possible to do this, even without installing TypeScript by the way), and if you really wanted to use it at runtime it would be fairly simple to write a JS to AST then AST to JS that reads JSDoc and does runtime checking for you... but that seems like overkill when a simple data schema validation approach would solve that final runtime issue for user inputs and API / data over the wire which you HAVE TO DO ANYWAY when you have user or third party input.
JSDoc has all the benefit of an easy to use and implement tool without modifying anything at the language level. It is beautiful in its simplicity and ease of use.
TypeScript tries to solve a problem that was solved years ago, and TypeScript does it in a much more intrusive and less elegant way than the existing solution.
If you disagree with any of this, please state clearly how you refute these points above. Since almost everything I have written above is factual I can't see why anyone would want to continue to advocate for a language that is subjectively horrible and objectively less productive as a developer to use.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are completely correct. JSDoc is significantly less overhead, compile-free, easier to read, easier to write, easier to understand, easier to migrate one way or the other, is fully supported in all IDEs and has been for years before TypeScript even existed.
There is literally nothing TypeScript can do that JSDoc cannot do except some extra language functionality like decorators.
The reason TypeScript is being widely adopted is for 2 main reasons:
1) Hype and the fear of being left behind
2) Most developers who think TypeScript is amazing don't know JSDoc exists when they go on their learning stint with TS and by the time they find out JSDoc does exist, it's now alien compared to the thing they just taught themselves to use.
TypeScript like every other compile-to-js thing is a TOOL. The reason TypeScript sucks as a tool is because it gets in the way of productivity, adds expensive time consuming extra code and compilation steps / time and is less readable and less fun.
It also reduces speed across the ground significantly, reduces the flexibility of your code to adapt to developmental changes as the project progresses and significantly increases the "noise / support code" to "actual functional code" ratio in your files.
JSDoc on the other hand is unobtrusive, works everywhere without installing anything other than the IDE, has been around FOR YEARS, is very easy to read and write (including most of the IDEs being able to WRITE IT FOR YOU 90% of the way), can operate at dev time and compile time (yes, it is possible to do this, even without installing TypeScript by the way), and if you really wanted to use it at runtime it would be fairly simple to write a JS to AST then AST to JS that reads JSDoc and does runtime checking for you... but that seems like overkill when a simple data schema validation approach would solve that final runtime issue for user inputs and API / data over the wire which you HAVE TO DO ANYWAY when you have user or third party input.
JSDoc has all the benefit of an easy to use and implement tool without modifying anything at the language level. It is beautiful in its simplicity and ease of use.
TypeScript tries to solve a problem that was solved years ago, and TypeScript does it in a much more intrusive and less elegant way than the existing solution.
If you disagree with any of this, please state clearly how you refute these points above. Since almost everything I have written above is factual I can't see why anyone would want to continue to advocate for a language that is subjectively horrible and objectively less productive as a developer to use.