Maybe they're just trying to say that robo taxis look like the future, not bike taxis?

1. there are plenty things you can't express in jsdoc but can in typescript, flow did the right thing here where you have access to full language, not sure why typescript never did it, they could, with the same syntax flow is using

2. you can have navigation that goes to typescript file instead of definition, just arrange your exports in package.json correctly (first ones take precedence)

Well I'd love to hear some concrete examples if you have any on hand! I was of the same opinion as you until I refactored a project of mine to use JSDoc.

Since any TypeScript type can be expressed in JSDoc, I imagine you're mostly thinking of generics. At least that was my main sticking point. JSDoc does actually have generic slots with the @template tag. Actually using them in practice is a little unintuitive but involves typing the return type. E.g. for a function it'd look like this:

  /** @type {ReturnType<typeof useState<Book[]>>} */
  const [books, setBooks] = useState();

Last time I checked, there isn't a way to extend types (https://www.typescriptlang.org/docs/handbook/2/objects.html#...) that works exactly like in TypeScript.

JSDoc actually has the @extends tag

  /**
   * @typedef {object} Dog @extends Animal
   * @property {string} childProp
   */

But I don't really use that feature in TypeScript. Instead I rely on `&`. This works in exactly the same way in JSDoc.

Also if you're curious about the equivalent of `extends` in generic slots, here's an example I have from a different project

  /**
   * @template {Record<string, unknown>} [T=Record<string, unknown>]
   * @typedef {{
   *   children?: NewickNode<T>[];
   *   name?: string;
   *   length?: number;
   *   data?: T;
   * }} NewickNode
   */

The generic slot here, T, is "extended" by Record<string, unknown>. The equivalent in TypeScript would look like

  type NewickNode<T extends Record<string, unknown> = Record<string, unknown>> = {
    children?: NewickNode<T>[];
    name?: string;
    length?: number;
    data?: T;
  };

the equivalent in typescript would be "export type" not just "type", since as I pointed out that type is exported without you being able to control it

> throw away all the benefits of compile-time errors because we'd rather have runtime errors

This is inaccurate on multiple counts. First of all, you can still run tsc with JSDoc if you want a hard error and you can still use strict mode with JSDoc. Your tsconfig file governs JSDoc-typed code just the same as it governs .ts-typed code. In both cases you can also ignore the red squigglies (the exact same red squigglies) and end up with runtime errors.

Nobody is advocating for reduced type safety or increased runtime errors.

I also think there are many valid reasons to loathe a build step (like not dealing with the headache that is the discrepency between the way the TS compiler deals with import paths vs js runtimes).

All that being said, I'm not really trying to convince anyone to stop using TypeScript. I'm simply pointing out that using JSDoc is using TypeScript. It's the same language service.

You can use `&` operator to combine types. Works for adding fields, making branded types, etc.

which is not the same as "extends".

There's also a slight performance caveat when it comes to interfaces vs intersections (&) to keep in mind: https://github.com/microsoft/Typescript/wiki/Performance#pre...

Things like type star imports, destructured imports or satisfies operator don't work in jsdoc.

All non erasable constructs won't work as well of course but playing devil's advocate you could explicitly state that you're interested in erasable constructs only because ie. 1) that's what typescript should be doing from day 1 and/or 2) it seem to be the future with ie. nodejs adopting built in type erasure support.

Support for generics is limited in JSDoc compared to TypeScript, especially when arrow function is involved. Things that work fine in TypeScript trigger errors even though they are syntactically the same.

Because AirBnB's ESLint config has been burned into my brain I almost only use arrow functions. I also use generics extremely often. It's definitely a little more clunky but I haven't run into anything you can do in TypeScript that you can't do in JSDoc.

JSDoc also allows you to type stuff in-line. For example I often have to type an empty array like so:

  const [books, setBooks] = useState(/** @type {Book[]} */([]));

If you have a tangible example of a problem you've run into, I'd love to walk through it.

JavaScript example:

https://www.typescriptlang.org/play/?filetype=js#code/PTAEAE...

Almost equivalent typescript code:

https://www.typescriptlang.org/play/?#code/C4TwDgpgBA6glsAFg...

(I had to make it a little bit different from the JS code to make it compile)

(Well, this is not exactly about arrow function I guess. I remembered that part wrong.)

Note that I cannot make the type check in JS code to pass. Whatever I do, there is always a error. Meanwhile, it does not take much to TS code to work.

Try this out. I think it's a much more faithful representation of your TypeScript example too. JSDoc just wants you to be explicit about the default for generic slots (which is `unknown` in TypeScript).

https://www.typescriptlang.org/play/?filetype=js#code/PTAEAE...

Hover over the variables and you should see that the type inference is working just the same as in your TypeScript example

Ah I see. Looks like you avoided using the "@callback" tag but instead used the "@typedef" tag directly. Thanks!

I do think it illustrates a problem with TypeScript's support for JSDoc though. You see, I started with the code in JS and could not make it work, after which I translated it to TS. In JS/JSdoc, "@callback" is the "idiomatic" way of defining a function callback type with JSDoc. (It also makes it easier to add documentation for each parameter if necessary.) And indeed, @callback works the most of the time, except in such cases where these JSDoc tags don't work nicely together, and these alternatives become necessary.

This is absolutely a fair point. JSDoc predates TypeScript by over a decade. It's not until more recently that the syntaxes have started to converge.

My brain definitely works in TypeScript so I tend to translate from there. I definitely consider myself more familiar with TypeScript than with JSDoc, but sometimes (e.g. here) that's a benefit not a weakness

and types can be written in .d.ts file(s), which can be used in jsdoc out of the box (no import needed)

that's not "jsdoc is typescript" anymore because you're falling back to something else - type definition files where you do have access wider typescript functionality.

also not a full solution - for .d.ts types to be available globally without explicit import the .d.ts file itself cannot use any imports/exports. this means you can't reuse types from other places to construct your types. you can workaround this by explicitly importing .d.ts in jsconfig/tsconfig but you're still left with other issues.

those types do actually become globally visible everywhere polluting global namespace which is bad in itself

there are no guarantees about them being in sync with actual code, which violates the whole point of using type safety.

they don't solve cases where you need typescript inlined functionality locally in your code or to perform assertion with satisfies operator etc.

You could, but in a large codebase with multiple contributors, it easily becomes messy and confusing.

ReturnType is TypeScript, no? You’re using JSDoc to express but it’s a TypeScript type.

As I stated in the article, JSDoc is TypeScript :P

TypeScript utility types are available in JSDoc. You can pretty much copy-paste any typescript Type/Interface into JSDoc

Isn't that the whole point of the article? For all intents and purposes, JSDoc IS TypeScript

> there are plenty things you can't express in jsdoc but can in typescript

This isn't really true anymore, they have systematically added pretty much every type system feature to the JSDoc-like syntax.

Having JSDoc-like syntax isn't the same as it being fully supported. If you have a large enough codebase, you'll likely find a few cases where things work in TypeScript but its equivalent somehow fails type check in JSDoc.

> If you have a large enough codebase, you'll likely find a few cases where things work in TypeScript but its equivalent somehow fails type check in JSDoc.

You keep repeating this throughout the thread. Can you give an example?

Not that person, but is there an easy way to write something like a basic semver?

export type SemVer = `${number}.${number}.${number}`;

Could you extend it to work with regex groups like:

export const SemVerRegex = /^(?<major>0|[1-9]\d)\.(?<minor>0|[1-9]\d)\.(?<patch>0|[1-9]\d)(?:-((?:0|[1-9]\d|\d[a-zA-Z-][0-9a-zA-Z-])(?:\.(?:0|[1-9]\d|\d[a-zA-Z-][0-9a-zA-Z-]))))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$/;

Could the groups be extracted so you the type back if you ran the regex on a string like: "1.2.3", or "1.2.3-prerelease"?

I don't understand the second part of your comment (that's a value, not a type), but the first part looks like this:

    /** @typedef {`${number}.${number}.${number}`} SemVer */

Here's a playground: https://www.typescriptlang.org/play/?filetype=js#code/PQKhAI...

Thanks for the example, I had a good play around with it.

The second part of my comment is a value yes, but it's implicitly typed by typescript automatically. I was asking about how to use that type (and it's internals) in jsdoc.

> it's implicitly typed by typescript automatically

What do you mean by this? Can you share an example?

Regular expressions do not act as type guards, and there's no way to express a type that allows one regular expression but rejects another (they're all just `RegExp`): https://www.typescriptlang.org/play/?target=5#code/MYewdgzgL...

You wouldn't use `test()` like in your example.

`test()` only returns a boolean, you want to look at `exec()` which returns the result of the regular expression (typed as: `RegExpExecArray | null` which you can narrow down to `RegExpExecArray` by checking if the result is null or not).

RegExpExecArray gives you a structure that looks different between the jsdoc version and the typescript version.

The typescript version has `.groups` inside RegExpExecArray.

You can use that as is, or you can add some extra type utilities to extract the named groups from inside the regex. (If you look inside typescript's issues on github you'll find a whole bunch of them that people have wanted typescript to include by default).

There's a few regex PRs to add extraction and syntax checking to typescript by default, but they're delayed until after the compiler switch from ts to go. (but there's porting to go in the PRs anyway).

Thanks for the reply.

> RegExpExecArray gives you a structure that looks different between the jsdoc version and the typescript version.

> The typescript version has `.groups` inside RegExpExecArray.

The JSDoc version has `.groups` too, and it appears to be typed identically to the TypeScript version given similar configuration.

Here's the TypeScript version: https://www.typescriptlang.org/play/?target=5&strictNullChec...

And here's the JSDoc version: https://www.typescriptlang.org/play/?target=5&strictNullChec...

Could you show me what you mean in the playground? You can change it to JSDoc mode by selecting "JavaScript" in the "Lang" dropdown in the "TS Config" tab.

it is possible to do many of these with @typedef, but it gets difficult with JSDoc very quickly. In TypeScript you can easily create multi-line type aliases. Not quite so in JSDoc.

TypeScript's type system is Turing complete so you have access to essentially unlimited expressivity (up to the typechecking termination depth): https://news.ycombinator.com/item?id=14905043

Except you can't have ie. union as argument, which means you can't construct ie. SQL/MongoDB-like where clauses.

This is a genuinely accurate critique of GraphQL. We're missing some extremely table-stakes things, like generics, discriminated unions in inputs (and in particular, discriminated unions you can discriminate and use later in the query as one of the variants), closed unions, etc.

Yeah I used it for this one via Babel from a CDN but it felt pretty crufty: https://tools.simonwillison.net/box-shadow

Yes, I guess it would start showing advantage for complex ones.

The idea is interesting, shame there is nothing for full stack like this, something like opinionated fossil-scm setup - which already has project management built in (for llm to use for its dev progress); together with backend and runtime state squashed inside single sqlite so you can create/delete them independently without a fuss.

Response API does support resuming.

But it's not gigantic improvement as models don't regenerate "lost"/past parts of conversation, they're heavily cached and were from pretty much day 1, that's why they have highly reduced cost.

But this fractalbits thingy is not open source.

Their internals (in zig, actually interesting functional part) are proprietary.

What is open source is client side to access it from rust.

Did I get it right?

Yes, since zig is moving to new async IO and we'd like to wait for it to be more stable before open sourcing our metadata engine. You can check the underneath runtime which we are using for now: https://codeberg.org/thomas-fractalbits/iofthetiger

Of course they're not. Everybody is waiting for next generation that will run LLMs faster to start buying.

Every generation runs LLMs faster than the previous one.

I never understood why bitcoin is winning popularity/pricing over ie. ethereum - which doesn't burn energy anymore and you can actually do programming on it, not just moving money from a to b.

Because it's based on narratives. Bitcoin has the strong narrative and the "network effect". Because bitoin keeps surviving, the narrative reinforces itself. At this point surely most people know, even if they're unwilling to admit or fooling themselves, the utility value is basically dead.

The utility value is now a pure gamble that a person tomorrow will pay me more than I paid for it today, thinking that a person in the future will pay them more than they paid. And that can be a powerful enough narrative to keep it going.

But if bitcoin disappeared today, 99.99999% of the world wouldn't even notice, that is how little of a problem it solves.

Anyway, the point is, imagine the scenario if ethereum overtook bitcoin in value. What will this actually do to the ecosystem? In my view, it would be catastrophic to the value of all coins, because it suddenly destroys the narrative of a "store of value" (the last lingering narrative). Any other coin could just overtake ethereum, and out of all the thousands of coins, which one? At that point, I think the whole thing comes down.

One interpretation of this comment, if viewed from an adversarial angle, is that comments like this, although perhaps not this comment specifically, are designed to dissuade people from buying crypto days before a bull-run starts.

Accurate data illuminate a lot of things.

I would benefit enormously from people buying crypto to keep the price going up. I've owned bitcoin for 9 years. I bought it when I realised that the narrative was strong enough to overcome any technical arguments and I wanted to profit from that. One day I'm assuming it help me retire.

(I just wish I'd bought more)

Bitcoin has a longer proof-of-work history, which is the only thing that secures any blockchain.

Stake also secures blockchain and doesn't waste energy.

One theory backed with proprietary data is that it's because bitcoin was created by the US government and money printed by the Fed goes in bitcoin so the government will one day pay its projected $113T of debt by dumping on everyone.

Just because they are not leading current sprint of maximizing transformers doesn't mean they're not doing anything.

It's not impossible that they asses it as local maximum / dead end and are evaluating/training something completely different - and if it'll work, it'll work big time.

Remote team?

Do remote teams take walks together ;)

Maybe if they are also using AR glasses and bring slack with them... They need a currently taking a walk channel.

Ah, how silly of me to overlook that option.

If you think about it "dog/whatever walking together" on a huddle could work quite well.