A powerful, open-source AI SDK with a unified interface across multiple providers. No vendor lock-in, no proprietary formats, just clean TypeScript and honest open source.
So, some history. When SPA's started to boom on the web JSDoc was a life saver for typing. Application state was getting more complex. We needed more guard rails.
Then Google Closure Compiler came along which added type safety via JSDOC and TS came along with (TS)JSDoc support and it's own TS syntax.
The community chose native TS and Google Closure compiler slipped away into the background.
So (TS)JSDoc support is a relic from when Microsoft was trying to get market share from Google.
Today in 2025, TS offers so much more than the (TS)JSDoc implementation. Generics, Enums, Utility types, Type Testing in Vitest, typeguards, plus other stuff.
Today I use TS. I also use plain JSDoc for documentation. e.g. @link and @see for docs. Or @deprecated when I'm flagging a method to be removed. @example for a quick look up of how to use a component.
TS and plain JSDoc are both important together. But (TS)JSDoc alone, is a relic of the past.
> Today in 2025, TS offers so much more than the (TS)JSDoc implementation. Generics, Enums, Utility types, Type Testing in Vitest, typeguards, plus other stuff.
This was my main impetus for writing this article. Modern JSDoc uses the TypeScript language service. You can use generics, utility types, typeguards (including the `is` keyword), regex parsing, etc all with just JSDoc.
I used these features extensively (especially generics) in a personal project and managed to do it all in JSDoc.
JSDoc is missing a lot of basic capabilities. For example a TypeDef is automatically exported which can cause collisions and forces you to repeat or inline types.
Types for classes are poor and often you'll find yourself creating a `.d.ts` file or `.ts` file to export non trivial types - however the target file doesn't know how to consume them.
You cannot replicate `import type { x } from './foo'` without also re-exporting that import - which causes collisions.
The alternative is to do an inline `const foo = /** @type {import('./foo').x} */ ({})` however this gets messy, repetitive and it's difficult to use algebraic types (e.g. `Event & { detail: string }`)
JSDoc does not understand typescript syntax though? The typescript language server just kinda plows through/over JSDoc sure, but try getting JSDoc to parse some of the TS-ified things that JSDoc has alternatives for.
You are attempting to generate documentation from jsdoc comments using an npm package that is also called "jsdoc". Ofc in this case "JSDoc is not TypeScript". That package only supports the subset of JSDoc that is relevant to it. Though I believe you can use TypeDoc instead if you want to generate documentation from JSDoc that contains typescript types.
In the post I made it explicit that I'm talking about intellisense, developer tooling, type checking etc. You can run `tsc` to do typechecking on a project typed with JSDoc like the examples I've given throughout this thread just fine.
I guess the difference here is I'm coming at this from the perspective of "what is TypeScript used for. Can JSDoc comments substitute that". And the answer is almost completely yes.
Apologies, my first draft of that comment got deleted on a refresh (mobile) and my posted one left out how I'm probably being too pedantic: the official JSDoc is not TypeScript.
Your post is actually one of the more accurate ones compared to others that say "you don't need typescript" with the big caveat that you actually need a whole lot of the typescript ecosystem to make JSDoc work.
I just wish there was an official handover, or a more clear delineation between JSDoc and Typescript JSDoc Extensions.
I think you have a valuable point. I kinda purposely avoided explicitly defining what JSDoc is. Instead I'm relying on "the JSDoc we're all familiar with". I said in the post that if your IDE is giving you intellisense from JSDoc comments then you are almost certainly already using TypeScript. That's about as close as I got to defining the JSDoc I'm talking about
But given that JSDoc doesn't have any sort of formal spec, I think the distinction you're making is more of a historical than a technical one.
This was an interesting and useful post but you’re kind of losing the plot here in these comments defending against what should be a straightforward minor correction.
JSDoc has been around for more than twenty years and most implementations have never had most of the capabilities you’re describing.
It is actively misleading for you to say that JSDoc has these capabilities when you’re referring specifically and exclusively to TypeScript’s implementation of JSDoc, or you could say TypeScript’s alternative JSDoc syntax. Closure always used language like that in their documentation, and explicitly called out that they had diverged from standard JSDoc, as they should have. TypeScript’s own documentation sometimes refers to it as their superset of JSDoc, again recognizing that “JSDoc” actually does mean something specific and different.
The fact that there may not be a formal technical spec doesn’t mean you’re not wrong and it’s preposterous to suggest that.
There was established tooling and documentation going back 25 years, and it doesn’t somehow not count just because they didn’t give you a formal grammar…
I’m curious how type checking is possible in a JDoc project. As far as I’m aware there’s no way to get type checking to work without tsc or a TypeScript LSP plugin.
That is exactly how it works. Any IDE providing you intellisense is using the TypeScript language service. That's why this article is called "JSDoc is TypeScript". If you see a red squiggly because of your JSDoc comment, you are almost certainly already using TypeScript (without any .ts files)
Ha! I see I elicited the copy/paste response I’ve seen elsewhere. The gp comment I was replying to implied a JSDoc only solution (“all in JSDoc”), but given the response, clearly they’re still relying on the TypeScript language service (aka lsp plugin) to achieve type checking inside their IDE.
Wishful thinking on my part that an alternative solution for JSDoc based type checking exists :)
Generally, no. Only in the case you had a requirement to exclusively use JavaScript as the programming language you might be in for an awkward time justifying that you added type checking to the project via the type checker component of TypeScript with JSDoc :)
Depends on your definition of "using" JavaScript. The main difference between common TypeScript and TS-based JSDoc is the need for an additional build step. Being able to ftp-upload your `.js` files and then be done with it is a remarkable advantage over Vite/Webpack/whatever in small to medium-sized projects. If editor based type support is sufficient to you (i.e. no headless checks), you won't need to install any TS packages at all, either. tsserver is still used in the background, but so are thousands of other binaries that keep your editor, OS and computer running, so I don't see that as an argument.
> So (TS)JSDoc support is a relic from when Microsoft was trying to get market share from Google.
> Today in 2025, TS offers so much more than the (TS)JSDoc implementation. Generics, Enums, Utility types, Type Testing in Vitest, typeguards, plus other stuff.
None of that is true! Please don't share misinformation without looking it up first.
These new tech companies/existing companies were not here for the first wave of offshoring engineers many years ago. basically, the product/service degraded and they brought the product/service back onshore.
It's a cycle that will repeat. Product degrades, there will be public outrage, then they will onshore the product to fix the problems caused from offshoring.
IMO, things are different this time (as someone who has been in this industry for about 20 years now) and I don't see these jobs coming back.
For one, many of these companies are now used to their tech teams being remote. The tools, culture, infra, etc. over the last ~5 years has all become remote which lessens the shock of going fully offshore.
Two, many tech teams in the western world are already partially offshored and have been for some time now. I know where I worked, a reasonable % of the team was already offshore in low COL countries (India, etc.). What's happening now is just the expansion of that cost saving after initial testing of the waters was successful.
Three, the quality gap between offshore teams and their western counterparts is now much smaller, and AI will be used to lessen the gap even further (along with just throwing more bodies at each problem which you can do when your salaries are 1/3rd of what they are here).
Four, many products/services now have captured markets with strong network effects, which means they can weather a heavy degradation of services with little to no loss of customers. It's called enshittification, and businesses are doing it now because they absolutely know they can, and get away with it.
I think in the very long term though what will happen is countries like India will actually end up with salaries comparable to western workers, so even though the gap might be smaller, the cost/benefit ratio will change again.
That happened during the last offshoring hype cycle as well. Those Indian developers aren't stupid -- the ones who deliver quality work will soon move somewhere they can earn a salary to reflect that, and it will be comparable to a US/UK/EU salary. Companies who insist on sticking to low salaries are left with the worst people.
I worked with some very good offshore engineers. They all left pretty quickly for a job with double the salary, or moved abroad outright to claim it. The only ones who stuck around were the ones whose poor skills kept them from landing a better job.
It's also great for productivity when your offshore team is a rapidly rotating cast. I remember being in meetings where without any announcement, half of the developers who had slowly started to get to know the project were replaced with new faces who had no idea what they were supposed to do.
Most people take photos of DSO's, but while you've got the gear, why not photograph the moon. It's also technically fun. Using a cooled camera, I video the moon/Jupiter at 20fps at 3000x3000. Then using software, I only take the frames where there is minimal atmospheric distortion. With the remaining frames, you stack them to get a very detailed image of the moon/planets.
Look up the other gear from ZWO the maker of the seestar.
They have active Peltier coolers and you use mains power, a portable battery box, or the 12V output from your car. You also need to power a computer or laptop to capture the images.
Roboscopes like the Seestar are an all-in-one kit and have internal batteries that last about 3-4 hours (although for the moon you don't need more than a minute or so). The S50 can take uncompressed video, which you can then process as GP describes but, compared to a more powerful setup, the camera is 1920x1080 and uncooled, the framerate is limited to 30fps, and it only has a 50mm aperture.
Some app devs use local models on local environments with LLM APIs to get up and running fast, then when the app deploys it switches to the big online models via environment vars.
In large companies this can save quite a bit of money.
have you tried the CoPilot agent tab in Github copilot chat in Webstorm? I wonder if/why you find using it through VSCode better in any way then using it directly in WebStorm.
Basically I'm hybrid touch typing. Because I cover the whole keyboard as I type the chance for error increases the longer I type. I quickly glance to know where i'm aligned.
In hindsight I should have learnt to use the F and J notches more.
I have extensively remapped my IDE shortcuts to be easier to trigger.
jQuery has mostly been replaced by new browser apis. It was a great library that brought the web forward. It will still be around the web for decades to come. If you're updating to jQuery 4. Why not try switching to native js.
