5 ms·

I would be interested to learn from somebody with experience using both Bun and Deno: which one is actually the more compelling Node successor? Bun's website ma

by zx2c4 3y ago

I would be interested to learn from somebody with experience using both Bun and Deno: which one is actually the more compelling Node successor? Bun's website makes some impressive performance claims over Deno. Are these true in practice? And if so, why? Seems like Deno also has similar goals. Also, are there large philosophical differences between the two projects? Like Bun tries to reimplement the kitchen sink but Deno wants a new post-Node way of doing things? (Just guessing, no idea if that's true.) Any seasoned users with time spent on both?

manojlds 3y ago
Deno wanted a post-Node way but they have gone back on their original ambitions (which never resonated with me, to be frank) and now have a pretty limited compatbility whereas Bun has full compatibility with Node.
- ignoramous 3y ago
  Per their own docs, Bun is not fully Node compatible [0]. In my experience, even for APIs its docs claim full-compatibility has some sharp edges. That said, Bun's node-compat story is better than Deno's. While Node's performance story keeps improving release over release [1]. [0] https://archive.is/NCzRQ https://archive.is/NCzRQ [1] https://twitter.com/lemire/status/1699459534190698999 https://twitter.com/lemire/status/1699459534190698999
re-thc 3y ago
Deno wanted to be different but never did enough to force its way. Maybe if they had 10x the funding to rewrite the ecosystem. Now it's in limbo. Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
- ShadowBanThis01 3y ago
  There's plenty to consider if you don't care about Node compatibility. From what I've read (including in this thread and on the Bun PR page), Node seems pretty messy, with modules coming from different sources in different ways. In Deno you just import with a URL. I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!
evbogue 3y ago
Does Bun support url imports for module loading?
- wdb 3y ago
  I think you can achieve this via a bun plugin
- lioeters 3y ago
  I was curious about this too, whether Bun supports URL module imports. Skimmed through the documentation a few times, and I believe it does not. But, the command `bun install` supports NPM and custom registries, as well as Git and .tgz URLs. https://bun.sh/docs/cli/install#git-dependencies https://bun.sh/docs/cli/install#git-dependencies
TheAceOfHearts 3y ago
These tools are way too young for anyone to have actually spent a lot of time using them. Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem. Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support. So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
hollowturtle 3y ago
Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in support for Typescript, JSX with some tooling like linter. It's also based on V8. My best guess it's what Ryan Dahl wanted Node to be as an afterthought. Bun, technically speaking is based on Webkit, but can't really say why, seems a better all-in-on tool(also remember rome?) and not only a runtime. Also with compatibility with current frameworks out of box, Deno wasn't npm compatible some time ago and I wonder if it ever meant to be and not a pivotal change on the run
- ShadowBanThis01 3y ago
  It's known that Deno tacked on NPM support. For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all. The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
  - kozzz 3y ago
    You’re unlikely to encounter any issues with Node in a small project. It’s possible though that you’ll need some module that is not working with Deno.
    - ShadowBanThis01 3y ago
      Thanks. If I can do CRUD and client authorization I should be OK… I say now, anyway!
- azu 3y ago
  > technically speaking is based on Webkit, but can't really say why Why Bun uses WebKit/JSC was described here: > One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that. via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-are-now-supported https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...
e1g 3y ago
We're a full-stack TypeScript shop, and I manage ~50 internal libs and ~500K LOC of TS. Last month I tested out both Deno and Bun as alternative runtimes for us. TLDR: for any semi-complex codebase we have, Bun almost always works, Deno almost never works. We now run all our tests in both Node.js and Bun, and gave up on trying to make Deno happen.
- ShadowBanThis01 3y ago
  What were your "semi-complex" codebases written in and for? Were they testing native Deno, or its integration of NPM packages? I have never used Node and am creating a new project from scratch, so I don't know how worried to be about your commentary.
  - e1g 3y ago
    The "semi-complex" code is legacy code, aka revenue code. Started with plain JS in CJS on Node 12 and evolved to strict TS/ESM on Node 20. A lot of cruft built up from that multi-year evolution. These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
    - ShadowBanThis01 3y ago
      Thanks for the reply! I'm just writing TS code that utilizes Deno/Oak and their MySQL support, to present a REST-style API. I don't know enough to say whether these depart from the standards you're recommending. If they do, I don't know how I would do routing and API support using only the things you mentioned. I'm a one-man band writing both a mobile app and the server to support it. I also know very little about scaling, which I anticipate hiring outside expertise on. I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!
afavour 3y ago
I’m not over the moon with it but I’m kind of interested to know why I need a Node successor at all. Both Bun and Deno are VC funded tools so I have base level suspicion around monetization and longevity. It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues. Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility. Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
- madsbuch 3y ago
  It is well explained in the blog article: https://bun.sh/blog/bun-v1.0#why-bun-exists https://bun.sh/blog/bun-v1.0#why-bun-exists This is extremely compelling for frontend DX.
  - afavour 3y ago
    That kind of speaks to my point, though: a number of the features listed there (e.g. test runner, .env file support, watch mode) have either been recently added to Node or will be soon (and are available today as experimental flags). The bundler stuff is certainly more compelling though the page doesn't specify what makes it better than esbuild except that it comes built-in... but that's where, for me, VC concerns raise their head. If I go all in on Bun bundler, what happens if the company switches their priority towards monetization and neglects the bundler? I'm going to have to unroll all the configuration work I will have done and go back to an external bundling library. And it's still not entirely clear what I gain!
    - fkyoureadthedoc 3y ago
      If it delivers on the promise of solving the require vs import module nonsense that would be enough for me. Maybe node copies that too, but that's also a win imo.
schemescape 3y ago
If I recall correctly, Bun doesn’t support Windows, unlike Node/Deno. Edit: sounds like this is changing. Thanks for the correction!
- schemescape 3y ago
  The link has been changed to the Bun 1.0 blog post which specifically mentions experimental/incomplete Windows support.
- jakegmaths 3y ago
  It has experimental support as of this release: https://bun.sh/blog/bun-v1.0#bun-more-thing https://bun.sh/blog/bun-v1.0#bun-more-thing
  - schemescape 3y ago
    Interesting! The original link has no Windows binaries, so I assumed nothing had changed.

by zx2c4 3y ago

manojlds 3y ago

Deno wanted a post-Node way but they have gone back on their original ambitions (which never resonated with me, to be frank) and now have a pretty limited compatbility whereas Bun has full compatibility with Node.

ignoramous 3y ago
Per their own docs, Bun is not fully Node compatible [0]. In my experience, even for APIs its docs claim full-compatibility has some sharp edges. That said, Bun's node-compat story is better than Deno's. While Node's performance story keeps improving release over release [1]. [0] https://archive.is/NCzRQ https://archive.is/NCzRQ [1] https://twitter.com/lemire/status/1699459534190698999 https://twitter.com/lemire/status/1699459534190698999

re-thc 3y ago

Deno wanted to be different but never did enough to force its way. Maybe if they had 10x the funding to rewrite the ecosystem. Now it's in limbo. Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.

ShadowBanThis01 3y ago
There's plenty to consider if you don't care about Node compatibility. From what I've read (including in this thread and on the Bun PR page), Node seems pretty messy, with modules coming from different sources in different ways. In Deno you just import with a URL. I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!

evbogue 3y ago

Does Bun support url imports for module loading?

wdb 3y ago
I think you can achieve this via a bun plugin
lioeters 3y ago
I was curious about this too, whether Bun supports URL module imports. Skimmed through the documentation a few times, and I believe it does not. But, the command `bun install` supports NPM and custom registries, as well as Git and .tgz URLs. https://bun.sh/docs/cli/install#git-dependencies https://bun.sh/docs/cli/install#git-dependencies

TheAceOfHearts 3y ago

These tools are way too young for anyone to have actually spent a lot of time using them. Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem. Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support. So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.

hollowturtle 3y ago

Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in support for Typescript, JSX with some tooling like linter. It's also based on V8. My best guess it's what Ryan Dahl wanted Node to be as an afterthought. Bun, technically speaking is based on Webkit, but can't really say why, seems a better all-in-on tool(also remember rome?) and not only a runtime. Also with compatibility with current frameworks out of box, Deno wasn't npm compatible some time ago and I wonder if it ever meant to be and not a pivotal change on the run

ShadowBanThis01 3y ago
It's known that Deno tacked on NPM support. For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all. The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
- kozzz 3y ago
  You’re unlikely to encounter any issues with Node in a small project. It’s possible though that you’ll need some module that is not working with Deno.
  - ShadowBanThis01 3y ago
    Thanks. If I can do CRUD and client authorization I should be OK… I say now, anyway!
azu 3y ago
> technically speaking is based on Webkit, but can't really say why Why Bun uses WebKit/JSC was described here: > One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that. via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-are-now-supported https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...

e1g 3y ago

We're a full-stack TypeScript shop, and I manage ~50 internal libs and ~500K LOC of TS. Last month I tested out both Deno and Bun as alternative runtimes for us. TLDR: for any semi-complex codebase we have, Bun almost always works, Deno almost never works. We now run all our tests in both Node.js and Bun, and gave up on trying to make Deno happen.

ShadowBanThis01 3y ago
What were your "semi-complex" codebases written in and for? Were they testing native Deno, or its integration of NPM packages? I have never used Node and am creating a new project from scratch, so I don't know how worried to be about your commentary.
- e1g 3y ago
  The "semi-complex" code is legacy code, aka revenue code. Started with plain JS in CJS on Node 12 and evolved to strict TS/ESM on Node 20. A lot of cruft built up from that multi-year evolution. These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
  - ShadowBanThis01 3y ago
    Thanks for the reply! I'm just writing TS code that utilizes Deno/Oak and their MySQL support, to present a REST-style API. I don't know enough to say whether these depart from the standards you're recommending. If they do, I don't know how I would do routing and API support using only the things you mentioned. I'm a one-man band writing both a mobile app and the server to support it. I also know very little about scaling, which I anticipate hiring outside expertise on. I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!

afavour 3y ago

I’m not over the moon with it but I’m kind of interested to know why I need a Node successor at all. Both Bun and Deno are VC funded tools so I have base level suspicion around monetization and longevity. It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues. Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility. Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.

madsbuch 3y ago
It is well explained in the blog article: https://bun.sh/blog/bun-v1.0#why-bun-exists https://bun.sh/blog/bun-v1.0#why-bun-exists This is extremely compelling for frontend DX.
- afavour 3y ago
  That kind of speaks to my point, though: a number of the features listed there (e.g. test runner, .env file support, watch mode) have either been recently added to Node or will be soon (and are available today as experimental flags). The bundler stuff is certainly more compelling though the page doesn't specify what makes it better than esbuild except that it comes built-in... but that's where, for me, VC concerns raise their head. If I go all in on Bun bundler, what happens if the company switches their priority towards monetization and neglects the bundler? I'm going to have to unroll all the configuration work I will have done and go back to an external bundling library. And it's still not entirely clear what I gain!
  - fkyoureadthedoc 3y ago
    If it delivers on the promise of solving the require vs import module nonsense that would be enough for me. Maybe node copies that too, but that's also a win imo.

schemescape 3y ago

If I recall correctly, Bun doesn’t support Windows, unlike Node/Deno. Edit: sounds like this is changing. Thanks for the correction!

schemescape 3y ago
The link has been changed to the Bun 1.0 blog post which specifically mentions experimental/incomplete Windows support.
jakegmaths 3y ago
It has experimental support as of this release: https://bun.sh/blog/bun-v1.0#bun-more-thing https://bun.sh/blog/bun-v1.0#bun-more-thing
- schemescape 3y ago
  Interesting! The original link has no Windows binaries, so I assumed nothing had changed.