7 ms·

In which way is Bun superior to Deno? Asking as someone who has yet to try either.

by Yoric 2y ago

stevage 2y ago
I use it to run typescript projects. It seems to just work. whereas TSC and tsx and ts-node all seem to complain a lot about configuration and module setup and stuff.
- vmfunction 2y ago
  The parent is asking about how bun compare to Deno, not node. TSC, tsx, and ts-node are nodejs related. I also would like to know. Deno seems to be mature and ready. It runs .ts files from command line. Of course there is no point of picking one JS runtime over another. I would follow the WinterCG group, and use something that is runtime agonistic like hono. It already has a React like front end built in (jsx-lite type).
  - stevage 2y ago
    My understanding was that Deno has compatibility issues with Node - it can't necessarily run all normal Node code. Whereas Bun definitely can.
    - Pozzuh 2y ago
      I don't think Bun "definitely can" run most Node code. Both Deno[1] and Bun's[2] Node compatibility are incomplete. Bun being perceived as more compatible is mostly clever marketing. [1] https://docs.deno.com/runtime/manual/node/compatibility https://docs.deno.com/runtime/manual/node/compatibility [2] https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
      - deleted 2y ago
        [deleted]
      - stevage 2y ago
        Huh, interesting. Surprised I haven't run into any of these incompatibilities. Sounds like I have some reading to do.
      - Jarred 2y ago
        From the beginning, Bun was designed to be a drop-in replacement for Node.js. That’s why Bun implements Node’s globals. That’s also why Bun automatically detects when CommonJS is used in the entry point and ensures CommonJS is loaded. require and many other Node.js features “just work” in Bun.
- deleted 2y ago
  [deleted]
alabhyajindal 2y ago
I was put off by Deno because of the way it handles dependencies. I didn't understand why I had to use URLs instead of `npm i`. Also not a big fan of the permissions flags when running a command. Explicit declaration for every single permission was very annoying. Bun has better speed and great documentation. And they're shipping new features very fast.
- tracker1 2y ago
  Yeah, I think import maps resolves a lot of those issues myself... I both loved and hated it. I liked that it was just a matter of referencing any live source module, but hated trying to keep various references synced (like std).
- jeswin 2y ago
  > I didn't understand why I had to use URLs instead of `npm i` (a) With npm, Microsoft is the gatekeeper of everything NodeJS. URLs are the most decentralized way to do dependencies. (b) Self-hosting can help with some security issues with npm. Makes it easier for private projects to not have to trust npm hosted third party libraries, which is important in many corporate environments.
spiffytech 2y ago
To grossly oversimplify, it's a choice between "make things better by starting fresh" (Deno) vs "make things better but don't change anything" (Bun). Bun's approach is easier to adopt, and seems to be "good enough" for many people. Deno made a very deliberate compatibility break from the Node ecosystem. They wanted fresh start, to make smarter choices and ditch historical baggage. They thought people would be motivated to push through the adoption friction. I think that plan has been less successful than hoped, and Deno keeps walking it back. They're more compatible than before, but aren't a drop-in replacement. IMHO they prefer it that way. Bun, on the other hand, explicitly feels that any compatibility gap with Node is a bug. Bun wants to beat Node at its own game, wants adoption to be as easy as running `bun index.js` instead of `node index.js`. Then you opt into their special APIs as-needed. Bun's headline feature is "free speedup", but they also target many of the same DX conveniences Deno does, like trivial TS integration. When Deno came out, the question was "how is Deno better than Node?". Deno had strong answers, give or take the compatibility differences. But today you could instead ask, "why port to Deno instead of just dropping in Bun?", and that's more complicated to decide.
- tmikaeld 2y ago
  For me, building production software in Deno - it's the sandbox that sets Deno apart. Knowing that even if there's a bad package, it can't call any external server or write/read files from disk. Even generally, I now know that the code I wrote don't do any unauthorized things I didn't explicitly tell it to do.
  - alabhyajindal 2y ago
    How common is this scenario really? I rarely find myself using obscure packages. Most of the ones I use are hugely popular and vetted by the developer community.
    - thejazzman 2y ago
      Their dependencies have dependencies which have dependencies and their dependencies dependencies' could be compromised If you think someone is reviewing all the code every time a new release is cut... popularity means it's one of the hottest targets.

In which way is Bun superior to Deno? Asking as someone who has yet to try either.

by Yoric 2y ago

In which way is Bun superior to Deno? Asking as someone who has yet to try either.

I use it to run typescript projects. It seems to just work. whereas TSC and tsx and ts-node all seem to complain a lot about configuration and module setup and stuff.

vmfunction 2y ago
The parent is asking about how bun compare to Deno, not node. TSC, tsx, and ts-node are nodejs related. I also would like to know. Deno seems to be mature and ready. It runs .ts files from command line. Of course there is no point of picking one JS runtime over another. I would follow the WinterCG group, and use something that is runtime agonistic like hono. It already has a React like front end built in (jsx-lite type).
- stevage 2y ago
  My understanding was that Deno has compatibility issues with Node - it can't necessarily run all normal Node code. Whereas Bun definitely can.
  - Pozzuh 2y ago
    I don't think Bun "definitely can" run most Node code. Both Deno[1] and Bun's[2] Node compatibility are incomplete. Bun being perceived as more compatible is mostly clever marketing. [1] https://docs.deno.com/runtime/manual/node/compatibility https://docs.deno.com/runtime/manual/node/compatibility [2] https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
    - deleted 2y ago
      [deleted]
    - stevage 2y ago
      Huh, interesting. Surprised I haven't run into any of these incompatibilities. Sounds like I have some reading to do.
    - Jarred 2y ago
      From the beginning, Bun was designed to be a drop-in replacement for Node.js. That’s why Bun implements Node’s globals. That’s also why Bun automatically detects when CommonJS is used in the entry point and ensures CommonJS is loaded. require and many other Node.js features “just work” in Bun.
deleted 2y ago
[deleted]

alabhyajindal 2y ago

I was put off by Deno because of the way it handles dependencies. I didn't understand why I had to use URLs instead of `npm i`. Also not a big fan of the permissions flags when running a command. Explicit declaration for every single permission was very annoying. Bun has better speed and great documentation. And they're shipping new features very fast.

tracker1 2y ago
Yeah, I think import maps resolves a lot of those issues myself... I both loved and hated it. I liked that it was just a matter of referencing any live source module, but hated trying to keep various references synced (like std).
jeswin 2y ago
> I didn't understand why I had to use URLs instead of `npm i` (a) With npm, Microsoft is the gatekeeper of everything NodeJS. URLs are the most decentralized way to do dependencies. (b) Self-hosting can help with some security issues with npm. Makes it easier for private projects to not have to trust npm hosted third party libraries, which is important in many corporate environments.

spiffytech 2y ago

To grossly oversimplify, it's a choice between "make things better by starting fresh" (Deno) vs "make things better but don't change anything" (Bun). Bun's approach is easier to adopt, and seems to be "good enough" for many people. Deno made a very deliberate compatibility break from the Node ecosystem. They wanted fresh start, to make smarter choices and ditch historical baggage. They thought people would be motivated to push through the adoption friction. I think that plan has been less successful than hoped, and Deno keeps walking it back. They're more compatible than before, but aren't a drop-in replacement. IMHO they prefer it that way. Bun, on the other hand, explicitly feels that any compatibility gap with Node is a bug. Bun wants to beat Node at its own game, wants adoption to be as easy as running `bun index.js` instead of `node index.js`. Then you opt into their special APIs as-needed. Bun's headline feature is "free speedup", but they also target many of the same DX conveniences Deno does, like trivial TS integration. When Deno came out, the question was "how is Deno better than Node?". Deno had strong answers, give or take the compatibility differences. But today you could instead ask, "why port to Deno instead of just dropping in Bun?", and that's more complicated to decide.

tmikaeld 2y ago
For me, building production software in Deno - it's the sandbox that sets Deno apart. Knowing that even if there's a bad package, it can't call any external server or write/read files from disk. Even generally, I now know that the code I wrote don't do any unauthorized things I didn't explicitly tell it to do.
- alabhyajindal 2y ago
  How common is this scenario really? I rarely find myself using obscure packages. Most of the ones I use are hugely popular and vetted by the developer community.
  - thejazzman 2y ago
    Their dependencies have dependencies which have dependencies and their dependencies dependencies' could be compromised If you think someone is reviewing all the code every time a new release is cut... popularity means it's one of the hottest targets.