6 comments

[ 4.1 ms ] story [ 26.9 ms ] thread
> The API is shaped after Sharp: construct from an input, chain transforms, pick an output format, then await a terminal method.

(https://sharp.pixelplumbing.com/)

Good! I like the pipeline workflow.

Glad to see that Bun is doing something that Java has been doing since 1998.
This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM.

---------------

Pre-empting the "how can you tell", here's some of the tells.

> The API is shaped after Sharp:

Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing.

> The constructor accepts a path, bytes, or a Blob — including Bun.file() and Bun.s3().

> The format is sniffed from the bytes — extensions and Content-Type are ignored.

Repeatedly formatting statements as X: Y, X — Y, or [b]X[b] Y is also an LLM-ism.

> Don’t pass user-controlled strings directly to the constructor — that’s an arbitrary-file-read primitive.

> When passing a TypedArray/ArrayBuffer, don’t mutate it while a terminal is pending — decode runs off-thread and borrows the bytes.

Doing so by leading with what-it's-not / what-not-to-do is even more of an LLM-ism.

I really like this. Having image manipulation as a core standard library feature rather than an optional package makes complete sense to me for a web development platform in 2026.

It's not like image manipulation is a poorly understood problem or a fast-moving field.