Hacker News Reader

Comment by vvpan | Hacker News Reader

So, anybody using Bun? Does it live up to hype?

I have not used it in production yet, but it's been great for one-off scripts and side projects. Setting up a TypeScript Node environment with ts-node, ts-jest, ESM support, top level await, etc. is more annoying than it should be. More recent Node releases have alleviated some of this pain, but not as trivial as running bun init.

I've enjoyed using the bun shell [1] API.

[1] https://bun.sh/blog/the-bun-shell

Ohh bun shell looks interesting. I was looking at zx[1] for some frontend pipeline scripting tasks that were just beyond maintainable bash, but maybe I'll give bun shell a go.

[1] https://github.com/google/zx

Bun shell has less features than zx or dax https://github.com/dsherret/dax. I tried it out but had to change tooling.

It’s good unless you want a repl (they pretend to have one but it’s miserable: >6s latency all the time when it updates), or you plan to use any native modules. The error messages are also significantly worse than node’s. I used it for a bit, but node with ‘—loader tsx’ does everything I want nowadays with none of the downside. If I was building a simple server, perhaps with websockets, and I was sure it need native modules, I’d consider using Bun. I have several such services live now actually.

I too would use it if the REPL worked properly. JS developers are often used to working interactively - the browser/console workflow - and have come to rely on testing ideas or problems / solutions in the REPL interactively.

It's efficient, as you can test and narrow things down in isolation and figure out what is working or not-working very quickly. It's also a good way to try a new module, and this is reflected in docs that eg, use node's REPL as a demo.

One bizarre problem with bun's REPL at the moment, which can be quite the unexpected "gotcha", is the REPL itself seems to be cached, and it goes stale. It actually expects to be able to update itself online every day or so, or it breaks!

Yeah, well cool - unless you ever work offline. Eg, had you expected to work on a long flight and now half your dev workflow was broken, for no good reason. (And unfortunately bun's "--prefer-offline" flag had no effect.)

I don't want to criticise bun too much - it is incredibly fast, and has made other significant workflow enhancements.

But a REPL is a dealbreaker for some of us. I guess it's similar to hot code-reloading in compiled languages, you don't go back to the minutes-long compile-wait cycle for the kinds of problems that kind of workflow makes instantaneous.

Currently, the REPL is an alias of `bunx bun-repl`, and bun-repl is a community-maintained npm package. We haven't had the time to do our own REPL. Honestly, we really need to hire more engineers. We're a small team and there's so much to do

Fixing the issue of not being able to run the repl offline would seem relatively low-effort//high-impact?

Started using it as soon as they hit 1.0 and never looked back, we’re implementing it in every project now.

Bun + uwebsocket cut my server costs and requirements significantly for my websocket app. It's a real delight to work with.

How did it cut your server costs - increased performance and therefore reduced load?

Bun looks quite promising, but I've heard mixed feedback on it being a "drop in" replacement of node. Any experience with that aspect?

Perf gain mostly from uwebsocket is what it looks like.

Do you use uwebsocket with Bun explicitly? I thought Bun has websocket support built in by internally using uwebsockets?

Yes, Bun uses uWebSocket internally. I think OP was saying the perf gain comes from the combination of Bun + uWebSocket. For http, most of that is coming from uWS, which is pretty much best performing HTTP framework out there ime.

https://github.com/oven-sh/bun/blob/main/src/http.zig#L34

I'm using it for my programming language (~15kLOC) as a dev and test runner and haven't had any Bun specific issues so far.

It still surprises me with its instant startup.

Been using it recently and it’s great, the quality of life stuff is really nice (like, not having to worry about compiling TS) and it’s really fast. Some things are still missing though, but for me it’s already better than Node

using it on all my side projects, some of which made it to production. some of which had lots of dependencies in the past and seamlessly switched over

one employer/client has a big project I'm afraid to attempt changing anything on, but I wonder

It has been extremely fun to use for personal projects. There are still some things that just do not work, though, like brotli compression which means any library using axios with their default brotli compression setting will crash at runtime. There is also no equivalent to the `npm outdated` command and a few other niceties. It is always little unexpected things, so it would be difficult to recommend for production uses just yet, but things are improving rapidly and I could see it becoming stable enough very soon. The APIs it exposes are so awesome—like giving node an excellent standard library—and the fact that I don’t need a compile step to execute TypeScript code makes it easier to get up and running with Bun than without it. Highly recommend trying for non-production work!

Pretty awesome, but I hope they get the node:crypto module to 100% soon.

It’s super fast and nice. But I can’t bring myself to use it with anything other than side projects because of the VC funding model.

oh yeah, it's amazing! The speed is great but just the DX is so much nicer than npm, yarn, or node itself. It took us a few tries to getting it working for our prod environments, but nothing we couldn't figure out within the same day.

I thought having a binary for a lock file was weird (don't know the technical reasons behind it besides maybe speed) but after using it for months now, it never has caused an issue for us.

Thanks for the feedback. What kind of product are you using it for? Any issues with library compatibility?

The Bun libraries made it very easy to create my own static site generator. Not a huge lift, I know, but it’s been a delight to work with.

[deleted]

Reply on news.ycombinator.com