Although it's more verbose, it makes code less dense because it lives outside the function parameters.

Also, it's not a super limited subset. For instance, you can write types in .d.ts the IDE uses those types in jsdoc out of the box.

▲

epolanski a day ago | parent [-]

The list of things jsdoc cannot do is long but a simple example is overloading, you cannot express this[1] in jsdoc, and if you need to reference .d.ts files you're back at using TypeScript, so the point of JSDoc was...?

If you need precise return typing, conditional types, literal values, etc, you aren't going far if anywhere with JSDoc.

[1] https://shorturl.at/pg5dL

	▲	efortis a day ago \| parent \| next [-]
		There a few points in favor of TS types in jsdoc (in order): 1. not having to type everything (many types are not helpful) 2. makes code less dense (and they can be rendered in HTML) https://x.com/efortis/status/1989776568676221137 3. not needing a compiler (browsers don't support TS) I think the main jsdoc caveat is around private types. About 1, IDK if there’s a way to set up TS for that.
	▲	g947o a day ago \| parent \| prev [-]
		This specific one is actually supported since TypeScript 5.0: https://devblogs.microsoft.com/typescript/announcing-typescr... But not properly documented (https://www.typescriptlang.org/docs/handbook/jsdoc-supported...), which shows how much Microsoft neglects JS + JSDoc workflow. Github issues have been created a long time ago, but nothing has been done so far. Apparently Microsoft is too busy with their AI slop to work on actually useful stuff.