|
|
|
|
|
|
by basil-rash
782 days ago
|
|
|
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. |
|
|
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.