I'm not super familiar with tailwind plus, but I am familiar with MUI.

MUIs paid offerings are open-core, you pay for support and a couple of extra features.

Tailwind plus looks like paying for basic components (checkboxes, sidebars, buttons) and it doesn't even offer anything like DataGrid (free with mui).

> and it doesn't even offer anything like

Shows Tailwind was just too little too late.

I'm not even sure it supports aarch64 hosts. There doesn't seem to be anything in there re: Arch ARM which sucks because that's a bit of a pain to set up.

For something that is a bash wrapper over qemu these limitations are surprising.

Sure but the parents point was more about declarative UIs than React. SolidJS and Svelte are declarative.

Not often you see Lexx references: https://floor796.com/#t0l2,597,381

Kai strikes again. That series was hilarious to my undergrad self. I think I caught it on Comedy Central or the Sci-Fi Channel (SyFy) junior year.

Indeed

Anything special about Raspberry Pi's that require X11? Raspberry Pi OS defaults to Wayland nowadays, and there's specific kiosk Wayland compositors like Cage (https://github.com/cage-kiosk/cage).

Tho admittedly kiosk-wm (https://github.com/JOT85/kiosk-wm) is much more succinct.

I write dashboards using X11/OpenGL for displaying otel metrics.

GLFW for my window library.

Wayland is overkill.

I would go straight /dev/fb if it meant I could also antialias and make it pretty and didn’t need a cursor.

less RAM and power usage

Why is an LLM trying to switch node versions?

Because somewhere inside its little non-deterministic brain, the phrase "switch to node version xxx" was the most probable response to the previous context.

God I loved kparts, but wasn't that more the idea that everything should be embeddable?

> KPart technology is used in kde to reuse GUI components ... By using kparts in applications developers can spend less time implementing text editor or command line features, for example and just use a katepart or a konsolepart instead.

https://techbase.kde.org/Development/Tutorials/Using_KParts

Yes it is, but since "KDE 5" I've seen less of it. Besides the obvious example of Konqueror another great example of it was reKonq, which used Akregator, Okular and Kget to handle RSS and PDFs respectively (all within the reKonq window).

Now not even Falkon does that.

Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.

  $ ls -1 /usr/lib/qt6/plugins/kf6/parts | wc -l
  20

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.

https://github.com/jsdoc/jsdoc/issues/1917

https://github.com/jsdoc/jsdoc/issues/1917#issuecomment-1250...

tuples, `&` operator, and even generics all work perfectly well inside a `@type` declaration. For example:

```js

  /**
   * @type {{
   *   slug: `${string}_${number}`;
   *   id: number;
   * } & { status?: [code: number, text: string]; }}
   */
  const example = { slug: 'abc_34', id: 34 };

is the exact equivalent of

```ts

  const example: {
    slug: `${string}_${number}`;
    id: number;
  } & { status?: [code: number, text: string] } = { slug: 'abc_34', id: 34 };

For TS-specific keywords like `satisfies`, there's a corresponding JSDoc keyword like @satisfies. Generics use @template.

Is there any specific feature you think is not supported? I'm sure I could work up a TS Playground example.

> Is there any specific feature you think is not supported

Yeah, uhm, most of what you've been posting? :). That JSDoc example above gives:

    ERROR: Unable to parse a tag's type expression for source file /Work/lol-jsdoc-why/index.js in line 1 with tag title "
    type" and text "{{  slug: `${string}_${number}`;  id: number;} & { status?: [code: number, text: string]; }}": Invalid type expre
    ssion "{  slug: `${string}_${number}`;  id: number;} & { status?: [code: number, text: string]; }": Expected "!", "$", "'", "(", 
    "*", ".", "...", "0", "?", "@", "Function", "\"", "\\", "_", "break", "case", "catch", "class", "const", "continue", "debugger", 
    "default", "delete", "do", "else", "enum", "export", "extends", "false", "finally", "for", "function", "if", "implements", "impor
    t", "in", "instanceof", "interface", "let", "new", "null", "package", "private", "protected", "public", "return", "static", "supe
    r", "switch", "this", "throw", "true", "try", "typeof", "undefined", "var", "void", "while", "with", "yield", "{", Unicode letter
     number, Unicode lowercase letter, Unicode modifier letter, Unicode other letter, Unicode titlecase letter, Unicode uppercase let
    ter, or [1-9] but "`" found.

Edit: Also, your first edit says Webpack switched from TypeScript to JavaScript, but Webpack source was never written in TypeScript.

We're talking about two different things here. All my examples work perfectly fine with TypeScript

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

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.

Also tbh I've never met anyone that uses that package to generate API docs. I don't think it's a very modern package: https://github.com/jsdoc/jsdoc/issues/2129

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…

What about the whole "graph" part? Are there any openapi libraries that deal with that?

OpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.

And the fetching in a single request?

There is json-schema which is a sort of dialect/extension of OpenAPI which offers support for fetching relations (and relations of relations etc) and selecting a subset of fields in a single request https://json-schema.org/

I used this to get a fully type safe client and API, with minimal requests. But it was a lot of work to get right and is not as mainstream as OpenAPI itself. Gql is of course much simpler to get going

The question I answered was regarding contracts. Fetching in a single request can be handled by your BFF.

So make things more complicated than gql?

gql is clearly the more complicated of the two ...

a gql server in python is about as simple as you can possibly go to exposing data via an API. You can use a raw http client to query it.

You still require gql requests to deal with. There's pretty much the same amount of code to build in BFF as it is to build the same in GQL... and probably less code on the frontend.

The value of GQL is pretty much equivalent to SOA orchestration - great in theory, just gets in the way in practice.

Oh and not to mention that GQL will inadvertently hide away bad API design(ex. lack of pagination).. until you are left questioning why your app with 10k records in total is slow AF.

Your response is incredibly anecdotal (as is mine absolutely), and misleading.

GQL paved the way for a lot of ergonomics with our microservices.

And there's nothing stopping you from just adding pagination arguments to a field and handling them. Kinda exactly how you would in any other situation, you define and implement the thing.

Yeah I love it when a request turns into an N+1 query because the FE guys needed 1 more field.

What's that old saying, "fool me once ..."

We haven't been using it as long but it's definitely saved us from things that were "impossible" to associate in our microservice backend.