> Had to explain to my employer attending that it is still typescript
"is" is doing a lot of heavy lifting there: JSDoc and TypeScript are two different ways to explicit prescribe typing in a way that tooling can use to determine correctness. The TS syntax is _far_ more powerful, but JSDoc can do most of the common TS use cases, for folks who want to stay in JS land while still benefiting from type tooling (either invoked or straight up built into the IDE).
> in a way that tooling can use to determine correctness.
As I pointed out in the article, the "tooling" is exactly TypeScript language services. If you are using JSDoc and you get squigglies or intellisense or any other similar features, you are using TypeScript.
You can copy-paste basically any bit of TypeScript into a JSDoc comment and it will work. JSDoc supports any non-runtime feature of TypeScript (so not enums). Even generics! You can even reference TypeScript utility types!
The whole point of this article was to correct the idea that JSDoc is not TypeScript. It absolutely is! There's almost nothing you can't define in JSDoc that you can't define in a .ts file. Albeit with a sometimes clunkier syntax
> If you are using JSDoc and you get squigglies or intellisense or any other similar features, you are using TypeScript.
This is true in the same way you are "using" C++ if you are on Windows. When most people say "use XYZ language" they mean "are personally writing code in XYZ language" rather than "under the hood my code is transpiled to this other language I don't write in"
By "JSDoc is TypeScript", culi means "JSDoc syntax and TypeScript syntax are two alternative ways to describe types to the TypeScript compiler/language services, and the two syntaxes have nearly-identical expressive power".
I understood it that way too. Only that it fails in that interpretation.
Just because currently the most popular method for parsing JSDoc utilizes TypeScript-related tooling doesn't mean we should associate them with each other.
To my previous example, an ISO C++ can be compiled by GCC but also can be compiled by Clang (and many other compilers).
Perhaps I should've expanded further to "the specific JSDoc dialect supported by the TypeScript compiler and TypeScript syntax are two alternative ways to …".
Unlike ISO C++ I'm not aware of any standard for what JSDoc is outside of specific implementations. There's a bunch of stuff documented on https://jsdoc.app/ but it only partially overlaps with the JSDoc syntax that TypeScript uses, and is not what the article is talking about.
The situation is not unlike Markdown before the CommonMark standard (except with less pressure to standardize, because most codebases are written with specific tooling in mind). Maybe we should refer to it as "TypeScript-flavored JSDoc".
In practice today JSDoc 100% completely and utterly always is Typescript.
It might not have been so originally. It might still be possible to do differently. But in practice today you are getting Typescript in your JSDoc with the out of the box tooling that is everywhere.
Welcome to the "a cat [1] has four legs [2], and therefore everything with four legs [3] is a cat [1]" fallacy. That's not how that works.
JSDoc is its own spec, and is not typescript, and is absolutely not at type annotation parity with typescript. Plenty of things that are hard to type in TS that are impossible to annotate use JSDoc.
So: just because tsc, the tool, can read in typing information that was written in JSDoc, does not make JSDoc typescript. tsc simply supports JSDOc. Very handy! Not the same thing in the slightest.
You are mixing theory with practice. In theory felines can be both cats and tigers. In practice the felines walking around your neighborhood are all cats.
No of course not, that's an absolutely ridiculous thing to say. ∀A -> B does not mean ∀B -> A, it only means ∃B -> A.
tsc, the executable, not only supports TypeScript, the language, but also knows how to read JSDoc when you're not giving it TypeScript. It supports JSDoc for code that isn't TypeScript. I'd repeat that a few more times but hopefully twice is enough to make the point obvious.
Sure. In theory people could be doing that. But for the third time: what is happening in practice?
What people _could_ be doing vs what they _are_ doing was explicitly my point, so please stop pretending it wasn't, less we have to repeat this merry go round.
If the question is about whether JSDoc is TypeScript, and you want to turn it into a different question, maybe your question belongs in a different thread.
JDoc, the spec and docs-in-practice, is not TypeScript, the language and tooling ecosystem in practice, and does not have type annotation parity with TypeScript (so it's not even "the choice is arbitrary in practice because they do the same thing").
JSDoc is simply a supported spec by the TypeScript tooling. Saying "JSDoc is TypeScript" when you're a programmer, especially one that uses one or the other, is idiotic: your job relies on precision in both code and terminology.
"is" is doing a lot of heavy lifting there: JSDoc and TypeScript are two different ways to explicit prescribe typing in a way that tooling can use to determine correctness. The TS syntax is _far_ more powerful, but JSDoc can do most of the common TS use cases, for folks who want to stay in JS land while still benefiting from type tooling (either invoked or straight up built into the IDE).