Hacker News Reader

Comment by yard2010 | Hacker News Reader

yard2010

Tangibly related: Bun has a built-in S3-compatible client. Bun is a gift, if you're using npm consider making the switch.

View on HN

I tried to go this route of using Bun for everything (Bun.serve, Bun.s3 etc), but was forced back to switch back to NodeJS proper and Express/aws-sdk due to Bun not fully implementing Nodes APIs.

What were the most significant missing bits?

The worst thing is issues without any visibility.

The other day I was toying with the MCP server (https://github.com/modelcontextprotocol/typescript-sdk). I default to bun these days and the http based server simply did not register in claude or any other client. No error logs, nothing.

After fiddling with my code I simply tried node and it just worked.

It definitely works in bun just fine. I have a production built mcp server with auth running under bun.

Now if you convert the request / response types to native bun server, it can be finicky.

But it works fine using express under bun with the official protocol implementation for typescript.

Actually writing a book about this too and will be using bun for it https://leanpub.com/creatingmcpserverswithoauth

Not sure about the specific underlying apis, but as of my last attempt, Bun still doesn't support PDF.js (pdfjs-dist), ssh2, or playwright.

localAddress is unsupported on sockets, meaning you can not specify an outgoing interface, which is useful if you have multiple network cards.

Proividing built APIs to not rely on NPM is one of the most interesting aspects of Bun IMO.

Can someone explain the advantage of this?

If I want S3 access, I can just use NPM

If I don't want S3 access, I don't want it integrated into my runtime

Would you rather use an officially maintained solution or some random package by a random author who might abandon the project (or worse)?

The S3 packages on NPM are maintained by AWS

Indeed but I was arguing about a general point.

I'd be surprised if any of your Node projects had less than 100 total deps of which a large number will be maintained by a single person.

See Express for example. 66 total deps with 26 deps relying on a single maintainer.

https://npmgraph.js.org/?q=express

But even in the case of the official aws-sdk they recently deprecated v2. I now need to update all my not-so-old Node projects to work with the newer version. Probably wouldn't have happened if I had used Bun's S3 client.

So let's put every package under the sun into the client?

This approach does not scale. We should make NPM better.

How do you make NPM better?

BTW I'm not saying we should kill NPM. What I'm saying is we should reduce our dependance on random packages.

Bun doesn't need to add everything into the core engine. Eg: when using .NET you still add plenty of official Microsoft dependencies from Nuget.

- NPM could migrate to reproducible builds of artefacts

- Trust could be opt-in by default

- Dependency installation could be made fully reproducible

is there a way to wrap their s3 client for use in HonoJS/CF workers?

No. It's implemented in native code (Zig) inside bun itself and just exposed to developers as a JavaScript API.

Source code: https://github.com/oven-sh/bun/tree/6ebad50543bf2c4107d4b4c2...

10/10 Loving it (and how fast it is!) - its just not the use-case that fits my needs.

I want maximum ability to "move" my projects among services/vendors/providers

i assume you can just use it[0] in your project and then build (using bun) for cf workers[1]

[0] https://bun.sh/docs/api/s3

[1] https://hono.dev/docs/getting-started/cloudflare-workers \ (https://bun.sh/docs/api/workers ?)

I came here to say the same thing.

Rather ship oven/bun through docker and have a 90mb container vs using node.

Reply on news.ycombinator.com