c-hendricks (u/c-hendricks)

c-hendricks commented on GraphQL: The enterprise honeymoon is over johnjames.blog/posts/grap... · Posted by u/johnjames4214

JAlexoid · an hour ago

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.

c-hendricks · 11 minutes ago

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.

c-hendricks commented on JSDoc is TypeScript culi.bearblog.dev/jsdoc-i... · Posted by u/culi

culi · an hour ago

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

c-hendricks · 18 minutes ago

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.

c-hendricks commented on JSDoc is TypeScript culi.bearblog.dev/jsdoc-i... · Posted by u/culi

culi · 2 hours ago

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.

c-hendricks · 2 hours ago

> 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.

c-hendricks commented on JSDoc is TypeScript culi.bearblog.dev/jsdoc-i... · Posted by u/culi

culi · 4 hours ago

> 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.

c-hendricks · 2 hours ago

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...

c-hendricks commented on GraphQL: The enterprise honeymoon is over johnjames.blog/posts/grap... · Posted by u/johnjames4214

lateforwork · 8 hours ago

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

c-hendricks · 8 hours ago

And the fetching in a single request?

c-hendricks commented on GraphQL: The enterprise honeymoon is over johnjames.blog/posts/grap... · Posted by u/johnjames4214

lateforwork · 8 hours ago

If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.

c-hendricks · 8 hours ago

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

c-hendricks commented on GraphQL: The enterprise honeymoon is over johnjames.blog/posts/grap... · Posted by u/johnjames4214

sibeliuss · 11 hours ago

Exactly! Once its working, it can be very healthy. And especially on the client. For a very, very, very long time. We started using GraphQL at the very beginning, back in 2015, and the way it has scaled over time -- across backend and frontend -- has worked amazingly well. Going on 10 years now and no slowing down.

c-hendricks · 10 hours ago

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.

c-hendricks commented on I tried Gleam for Advent of Code blog.tymscar.com/posts/gl... · Posted by u/tymscar

marliechiller · a day ago

One thing im wondering with the LLM age we seem to be entering: is there value in picking up a language like this if theres not going to be a corpus of training data for an LLM to learn from? Id like to invest the time to learn Gleam, but I treat a language as a tool, or a means to an end. I feel like more and more I'm reaching for the tool to get the job done most easily, which are languages that LLMs seem to gel with.

c-hendricks · a day ago

I hope this isn't the future of "new" languages. Hopefully newer AI tools can actually learn a language and they won't be the limiting factor.

c-hendricks commented on Id Software devs form "wall-to-wall" union rockpapershotgun.com/id-s... · Posted by u/simjue

hellojesus · 2 days ago

My point is exactly that the union didn't do what was best for its members because their actions collapsed the company.

Unions are subject to the constraints of operations. LTL is a very debt-heavy industry, and yellow pushed the envelop too far. But the union could have tried to negotiate a contract contingent on operating costs and debt load. They didn't. Instead they chose their line and then striked until the company went under.

Maybe not the best example, but it was the one on my mind.

c-hendricks · 2 days ago

> because their actions collapsed the company

The company blamed the collapse on their actions, different things.

c-hendricks commented on Id Software devs form "wall-to-wall" union rockpapershotgun.com/id-s... · Posted by u/simjue

seneca · 2 days ago

> If the company's existence depends on the unfair exploitation of its staff, its foreclosure is inevitable and justified, and that is simply the price everyone involved must pay to maintain equilibrium.

Claiming that all non-union companies are inherently operating via "unfair exploitation of its staff" is ridiculous. It's entirely possible for a labor union to go too far and drive a company to become noncompetitive.

These sort of canned answers are empty claptrap and not really fit for an honest discussion.

c-hendricks · 2 days ago

The statement wasn't really pro or against unions. Simply put, if your company can only survive while exploiting its workers it shouldn't survive.

Whether that's due to constant turnover from poor treatment of their employees, or due to union strikes, doesn't change the statement.