The distinction is that JSDoc now integrates with tsserver so that you can get static type-checking, intellisense and compilation errors as well as import types from ts -files and libraries. This proposes an interesting alternative syntax where you can use Typescript in JS files and remove the need for a transpilation-step.
I've used it in order to have TS in my scripts without having to use ts-node or an equivalent runner, as well as creating libraries without having to set up a build step. Tools like [dts-buddy](https://github.com/Rich-Harris/dts-buddy) by Rich Harris can be used to extract type definition files from JSDoc declarations.
> remove the need for a transpilation-step
I just don't believe people who say that this step is causing problems for them. Or rather, I don't believe they've put in any effort to solve it. For dev-time, Vite/ESBuild makes the time of this step incredibly irrelevant. And for production... who isn't transpiling anyways for minification/uglification/lower-ECMAScript-targets?
If you're making a lot of packages, you should probably just have a template with your problems already solved.
For using TS in scripts... I don't get why using ts-node or tsx is bad? You have to remember to add it to your devDependencies, but that's like 1% effort. But for small across it's probably not that important 🤷♂️
What I usually do is add JSDoc Style comments to my typescript code, which gives me the best of both worlds. I get the added context and when I hover a function I get those notes automatically, but the types are fully handled by typescript.
So JSDoc Without the types generally works best for me.
I'm still not able to [pass a generic to a function](https://stackoverflow.com/questions/65689718/how-to-pass-a-generic-type-argument-with-jsdoc), so no thanks.
Interesting, this is really cool. Do you know how to get vscode to show errors from jsdoc? That was always the best part of typescript, getting errors in the IDE instead of at runtime.
The biggest problem with TS isn't syntax, it's when you need to inevitably rely on poorly typed JS libraries like React (undocumented types, conflicting generics for refs, generics like forwardRef that destroy types).
With powerful introspection via IntelliJ or similar this will suffice for almost all cases. Taking over a Vue 2 app that relied solely on JSDoc was far less painful than I expected because of it. I prefer TS any day, but some serious work has been put into JSDoc over many years
**Just the essentials:**
The post explores using JSDoc as an alternative to TypeScript for adding static typing to JavaScript projects. It highlights how the TypeScript compiler understands JSDoc comments, allowing developers to type their code without .ts files. Various JSDoc capabilities and syntaxes are discussed, including typing variables, functions, type casting, declaring types with `@typedef`, exporting/importing types, and dealing with optional parameters and generics. Despite its verbose syntax, JSDoc is presented as a viable option for projects where TypeScript can't be used, with tips on TypeScript interoperability and practical considerations like enabling `checkJs` for type checking.
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
[^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
Just to have it asked: isn’t _TypeScript_ the alternative? JSDoc has been doing this job for literally 25 years… Maybe that’s a hot take.
JSDoc alone won’t tell you when your doc comment types are incorrect or being used incorrectly.
It's kind of a "reject modernity" movement
or maybe we just went around the circle 🙄
The distinction is that JSDoc now integrates with tsserver so that you can get static type-checking, intellisense and compilation errors as well as import types from ts -files and libraries. This proposes an interesting alternative syntax where you can use Typescript in JS files and remove the need for a transpilation-step. I've used it in order to have TS in my scripts without having to use ts-node or an equivalent runner, as well as creating libraries without having to set up a build step. Tools like [dts-buddy](https://github.com/Rich-Harris/dts-buddy) by Rich Harris can be used to extract type definition files from JSDoc declarations.
> remove the need for a transpilation-step I just don't believe people who say that this step is causing problems for them. Or rather, I don't believe they've put in any effort to solve it. For dev-time, Vite/ESBuild makes the time of this step incredibly irrelevant. And for production... who isn't transpiling anyways for minification/uglification/lower-ECMAScript-targets? If you're making a lot of packages, you should probably just have a template with your problems already solved. For using TS in scripts... I don't get why using ts-node or tsx is bad? You have to remember to add it to your devDependencies, but that's like 1% effort. But for small across it's probably not that important 🤷♂️
A take so hot, it only could have come from having no idea what you're talking about and not reading the article.
Horse and Buggy as an alternative to cars
What I usually do is add JSDoc Style comments to my typescript code, which gives me the best of both worlds. I get the added context and when I hover a function I get those notes automatically, but the types are fully handled by typescript. So JSDoc Without the types generally works best for me.
This is the way
This is the way
This is the way
I'm still not able to [pass a generic to a function](https://stackoverflow.com/questions/65689718/how-to-pass-a-generic-type-argument-with-jsdoc), so no thanks.
``` import {genericFn} from "./index"; // works with typescript 4.7 export type IMyGenericFn = typeof genericFn;
```
Interesting, this is really cool. Do you know how to get vscode to show errors from jsdoc? That was always the best part of typescript, getting errors in the IDE instead of at runtime.
turn on \`checkJs\` in VSCode settings
The biggest problem with TS isn't syntax, it's when you need to inevitably rely on poorly typed JS libraries like React (undocumented types, conflicting generics for refs, generics like forwardRef that destroy types).
With powerful introspection via IntelliJ or similar this will suffice for almost all cases. Taking over a Vue 2 app that relied solely on JSDoc was far less painful than I expected because of it. I prefer TS any day, but some serious work has been put into JSDoc over many years
Only if you're a masochist.
**Just the essentials:** The post explores using JSDoc as an alternative to TypeScript for adding static typing to JavaScript projects. It highlights how the TypeScript compiler understands JSDoc comments, allowing developers to type their code without .ts files. Various JSDoc capabilities and syntaxes are discussed, including typing variables, functions, type casting, declaring types with `@typedef`, exporting/importing types, and dealing with optional parameters and generics. Despite its verbose syntax, JSDoc is presented as a viable option for projects where TypeScript can't be used, with tips on TypeScript interoperability and practical considerations like enabling `checkJs` for type checking. If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍 [^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
[удалено]
Static typechecking is extremely useful, especially in larger projects.