5 ms·

Deno vs. Bun vs. Node.js: A feature comparison

90 points by birkskyum 3y ago

ozten 3y ago
Bun's #1 killer feature is that web application tooling has become a nightmare that everyone dreads dealing with. Bun promises one tool designed for DX to solve bundling, testing, runtime, and more. Even if Bun didn't have a better performance story, I would evaluate switching to it to reduce project complexity.
- andyferris 3y ago
  Does not Deno aim for exactly the same?
  - ozten 3y ago
    Good point. Bun promises compatibility with existing mainstream web development technologies (CommonJS, ES Modules, NodeJs APIs, Typescript, etc). Deno promised "Node", but done a second time the right way (Typescript, new APIs, new package manager, etc). Which is not an entirely new language / platform, but different enough that you have to buy into the Deno vision.
    - jauntywundrkind 3y ago
      Deno in my view was promising web. They actively fought against being Node at all for a long time, & differentiated themselves in being much much less, no package.json at all. Only recently has Deno gotten deep Node intercompatibility, after years of trying to leave that shit behind & finally giving in to the needs to be part of the vast npm externality. The general principle has & still is evident. It's not totally picture perfect rosy - there's lots of pieces missing - but Deno's http serving for example uses standard w3c Request Response objects used by Fetch & Service Worker. https://deno.land/api@v1.36.4?s=Deno.serveHttp https://deno.land/api@v1.36.4?s=Deno.serveHttp But more so, things like typescript & formatting come out of the box & are crazy fast/just work.
      - zarzavat 3y ago
        I just don’t understand why I would want to use Deno. I totally get the idea of wanting a modern Node, and I can appreciate Deno as a form of art. But does it help me do my job better than with Node? The browser API compat doesn’t move me at all, I can have that in Node as well… same with Typescript, it works just fine in Node, in fact I like having it separate because I can configure my build exactly how I want.
        jauntywundrkind 3y ago
        I've spent way too long fighting node.js having bitterly sad compromises in esm support. I've spent way too long hunting through tsconfig options looking for some option that maybe might help. These problems keep recurring. Every time I start a small library, yes, I know I'll make it through, eventually. But I feel lessened by the battle. Compromises are made. I personally feel little enjoyment for configuring build chains. A good fraction for the packages I download have people that made cute interesting personal decisions about how to package stuff - since there is no guidance & no standard - that clashes & conflicts with everything else. Or is distributed as es2015 cjs. Other people's ability to choose, their ability to like configuring their build actively impedes the general flow. Most people dont get the web platform compat. But unjs, cloudflare workers, and dozens of others are just amazing lovely platforms that work so well, and which are often fairly cross portable with little lift. It's fine that you are happy in your niche, but having actual well adopted interoperable protocols has let some really interesting pick & choose futures start to emerge, and it's where the early adopters are. It's where the good stuff is formenting. You don't have to be there now, you can stay in your zone, but is is growing, and it's because of wintercg interoperability efforts all centered around growing web platform ideas outward.
        zarzavat 3y ago
        That’s fair enough but you can do most of these things in Node too, it doesn’t require a new runtime. You can use browser APIs by installing a wrapper, you can use ES modules, you can (I believe) use workers although I haven’t tried that yet. The packaging situation is indeed messed up but that’s because TC39 decided to invent a maximally incompatible new module format. But you can not install CJS packages in Node just as well as you can not install them in Deno. I don’t find configuring build systems enjoyable, but the benefit is that your dev environment is not tightly coupled. If your runtime is also your build system then there’s one tool doing two jobs. Some people might like this. I personally think that this kind of coupling causes more inconvenience over the long-term even if there’s less inconvenience up front.
- klabb3 3y ago
  I think that in general, tooling is underrated. In many ways, tooling is more important than the language itself (although some language features are intertwined with the tooling story). And I don’t mean more features, but rather consistency, reproducibility, simplicity, etc. Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And so on…
  - hu3 3y ago
    Agreed. Go is prime example of a rather (intentionally) unsexy language that sports great tooling.
    - DanielHB 3y ago
      I am not an expert in go, but I find its tooling not good at all, especially package/dependency management. But at least there is _less_ tooling required than most nodejs projects and _less_ tooling fragmentation in general. Rust/Cargo is the one I was most impressed by. But I haven't done any significant work in Rust.
  - dilawar 3y ago
    +1. Before I could understand benefits of Rist, I was sold on cargo.
    - zacmps 3y ago
      I think rustdoc, rust-analyzer, and crater all deserve shout-outs as well.
- no_wizard 3y ago
  it can't build stylesheets or run a headless browser yet, so its not entirely a one stop shop
- dzogchen 3y ago
  I would argue that random segfaults are not particularly good DX.
report-to-trees 3y ago
I wasn't expecting a deep and thorough comparison just from the headline... but the feature list and comparison text here is worse than I thought it would be, bordering on useless. "Built in" means nothing because the value prop of node compared to the other two is the ecosystem and maturity. Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? "Secure by default" in particular means nothing by itself here either. Bun specifically promises better compatibility with existing npm modules then Deno so the comparison here is much different than the chart would lead you to believe.
- SkyMarshal 3y ago
  > Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? In general I would expect a linting tool or any other component that is a first class feature of the app would be less likely to be released with bugs and breaking changes than a third party one.
  - report-to-trees 3y ago
    Sure, maybe. How would you know without doing some research into a specific project? My point was that the feature checklist here is so surface level it's useless as a practical comparison.
  - paulddraper 3y ago
    Maybe?
  - booi 3y ago
    In this day and age the “linting” tool does a lot more than just respond yes or no. It usually has a rules engine, templates, config file support and enforces a lot more things than just syntactical correctness. With that in mind it’s probably impossible to build a linter that’s going to be able to serve these needs that’s also built-in and on the same release cadence as the runtime itself.
- Hexagon56k 3y ago
  > worse than I thought it would be, bordering on useless. I'm all ears! Will revise it later today Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node. We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't think any company would read this and think "Woah, let's ditch node!" Should I list "better compatibility with existing Node modules" as a feature for Bun?
zamalek 3y ago
Deno does have a built-in package manager[1], the fact that it's not home-grown shouldn't be held against it. [1]: https://deno.land/manual@v1.36.4/basics/import_maps https://deno.land/manual@v1.36.4/basics/import_maps
SkyMarshal 3y ago
It was pretty clear what Bun’s advantages vs Node are, but less so vs Deno. This helps clarify it. It’s mainly that Bun has a built-in package manager* and minifier and Deno doesn’t. And Deno has a few extras Bun doesn’t. I imagine those will equalize somewhat with future releases. This is a helpful overview, though I would also like to see a deep dive on some categories, like security (Deno permissions vs Bun trustedDependencies). * Or maybe Deno has one too: https://news.ycombinator.com/item?id=37475462 https://news.ycombinator.com/item?id=37475462
princevegeta89 3y ago
Isn't Deno under the strong commercial grip of a couple of corporate companies, including the one that develops it?
- birkskyum 3y ago
  I think deno (made by Deno Company) and bun (made by Oven) are in quite similar situations here, both controlled by companies eyeing deployment services of their respective runtimes as the main source of revenue. Node is in the OpenJS Foundation, so it's in a different situation.
officialchicken 3y ago
What about a built-in standard library? That seems somewhat important.
ComputerGuru 3y ago
So where does all this backend activity leave frontend tooling? It seems the divide only grows despite the upstream attempts by the ES committee to bridge the gap.
- birkskyum 3y ago
  It leaves frontend tooling in a great place. All these features like built-in test runners, typescript/jsx support, faster iteration loop are quite convenient. There is still work to do for both runtimes in getting a high level of support for all the front-end frameworks, but there is good progress.
- DanielHB 3y ago
  Adding the bundler to the runtime is the way to go in my opinion, the code you write in your scripts/server should run exactly the same as in the browser and not require separate configuration (besides bundling-specific things like how to split your modules for lazy loading). It is crazy that every web framework these days is trying to re-solve bundling for browsers
afavour 3y ago
There’s an important column missing in the table: ownership. Both Bun and Deno are made by companies with heavy VC investment. Node is not. Don’t want to state the obvious but those VCs want to see a return on their investment and that makes me very hesitant to invest in Bun or Deno, especially at this early stage. Don’t know if it’s coincidence or if the competition has lit a fire under the Node project but it’s recently been adding some great stuff like a built in test runner and watch mode. I’m optimistic.
- birkskyum 3y ago
  That is true. Both deno and bun runtimes are released under MIT license, and might potentially outlive the companies behind them.
  - exabyte 3y ago
    So this is a good thing with regards to your parent comment? I.e., should we feel safe using Bun despite heavy VC investment?
    - birkskyum 3y ago
      It depends on the project how conservative you have to be, and what to emphasize. Generally, this company is very fast moving, so waiting some months could make it significantly easier to gauge if it's a good fit.
  - Rapzid 3y ago
    There are a relative handful of people willing and able to work on these projects. Lots of OSS software just gets abandoned when their corporate sponsors stop developing them; like Chakra Core and a bunch of Mozilla projects.
- yieldcrv 3y ago
  My positive experience with NextJS by VC backed Vercel ($2.5bn valuation) makes me not skeptical of a package by mere nature of it being maintained and marketed by a for profit company with heavy VC investment. Its all about how it integrates and how it avoids vendor lock in.
yeck 3y ago
Bun is getting a lot of hype due to all the press, but almost everyone is just echoing Bun's docs and marketing material and lack direct experience using it. I haven't done a deep dive into Bun yet, but I have tried porting a legacy project to it. Hit a lot of issues after a few hours of hacking around. It wouldn't correctly install node modules because of opt-in dependency lifecycles (and maybe other issues?) and then I couldn't use it to execute the existing webpack build without encountering opaque runtime errors. The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm.
- rz2k 3y ago
  Wasn’t version 1.0.0 released three days ago? I think people are surprised that the performance claims don’t completely disappear with real world scenarios. It seems like a lot of eventually successful platforms began in the same way: the claims about improvements are real, and there are still a lot of rough edges.
- TheFreim 3y ago
  > The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm. There was discussion about this the other day. It's marketed as a "drop-in" replacement but from perusing HN and elsewhere I see people having issues with real projects. It looks like a promising project, which I hope succeeds, but there also seems to be an unfortunate amount of marketing that, as you note, is being uncritically repeated.
- hk1337 3y ago
  It seems like it has potential but I tried using it with a Shopify app I am building and for some reason it wasn't automatically creating the cloudflare tunnel in dev mode. Also, there's no verbose flag to show more detailed log message.
- DanielHB 3y ago
  I think running a bundler on top of bun defeats half of the purpose of the tool, unfortunately bun's own bundler is still very lackluster and definitely not good enough to use. On top of that most of the popular frontend frameworks (Vite, NextJS, etc) are doing their own bundling so I wouldn't use bun with those tools either. I would consider it only for backend nodejs at the moment.
nnx 3y ago
One under-advertised unique feature of Bun is that it supports proper tail calls, thanks to the JavascriptCore runtime. Both Node and Deno, using V8, do not support those so some (functional) algos are harder to express there.
yieldcrv 3y ago
Any real benchmarks with version 1.0? Has anybody replaced everything with Bun in their 100 dependency project with a loose scaffolding of a deprecated node version due to some crucial dependency This is the kind of thing I want to see even before using bun in a greenfield project
- evnix 3y ago
  Did this recently, on a largish project based on express and typeorm. The only issue we had was with a native image manipulation library in combination with alpine linux image which was an easy fix. Rest worked flawlessly. Performance wasn't an issue for us, Dev experience was really bad on Node and the amount of hacks required to get esm/commonjs working in tandem was insane. Bun got rid of a lot of those hacks and we are slowly cleaning up the codebase.
rcarmo 3y ago
For me, the key thing that is missing is dgram (UDP) support. Makes bun unusable for a lot of IoT scenarios.
- ryapric 3y ago
  Why would you want to use JavaScript in IoT scenarios?
  - rcarmo 3y ago
    Well, Node-RED for starters. Plus homebridge, and plenty of UPNP and protocol-specific solutions that, for some reason, are coded in JavaScript.
  - DanielHB 3y ago
    I do it at my company, to talk to microcontrollers. We have a few CLI tools we use for testing that run on NodeJS. Our web-wrapped maintenance desktop application also sends UDP packages directly to microcontrollers but there we do it a bit differently. We have a proxy that forwards websocket messages as UDP packets running in the native code of our desktop application. Would be really nice if we could send UDP messages directly from the browser, but it is understandable from security perspective.
Akronymus 3y ago
Can one use bun in combination with something like aspnet core to replace vite, for example? Or am I fundamentally misunderstanding what bun is?

90 points by birkskyum 3y ago

Bun's #1 killer feature is that web application tooling has become a nightmare that everyone dreads dealing with. Bun promises one tool designed for DX to solve bundling, testing, runtime, and more. Even if Bun didn't have a better performance story, I would evaluate switching to it to reduce project complexity.

andyferris 3y ago
Does not Deno aim for exactly the same?
- ozten 3y ago
  Good point. Bun promises compatibility with existing mainstream web development technologies (CommonJS, ES Modules, NodeJs APIs, Typescript, etc). Deno promised "Node", but done a second time the right way (Typescript, new APIs, new package manager, etc). Which is not an entirely new language / platform, but different enough that you have to buy into the Deno vision.
  - jauntywundrkind 3y ago
    Deno in my view was promising web. They actively fought against being Node at all for a long time, & differentiated themselves in being much much less, no package.json at all. Only recently has Deno gotten deep Node intercompatibility, after years of trying to leave that shit behind & finally giving in to the needs to be part of the vast npm externality. The general principle has & still is evident. It's not totally picture perfect rosy - there's lots of pieces missing - but Deno's http serving for example uses standard w3c Request Response objects used by Fetch & Service Worker. https://deno.land/api@v1.36.4?s=Deno.serveHttp https://deno.land/api@v1.36.4?s=Deno.serveHttp But more so, things like typescript & formatting come out of the box & are crazy fast/just work.
    - zarzavat 3y ago
      I just don’t understand why I would want to use Deno. I totally get the idea of wanting a modern Node, and I can appreciate Deno as a form of art. But does it help me do my job better than with Node? The browser API compat doesn’t move me at all, I can have that in Node as well… same with Typescript, it works just fine in Node, in fact I like having it separate because I can configure my build exactly how I want.
      - jauntywundrkind 3y ago
        I've spent way too long fighting node.js having bitterly sad compromises in esm support. I've spent way too long hunting through tsconfig options looking for some option that maybe might help. These problems keep recurring. Every time I start a small library, yes, I know I'll make it through, eventually. But I feel lessened by the battle. Compromises are made. I personally feel little enjoyment for configuring build chains. A good fraction for the packages I download have people that made cute interesting personal decisions about how to package stuff - since there is no guidance & no standard - that clashes & conflicts with everything else. Or is distributed as es2015 cjs. Other people's ability to choose, their ability to like configuring their build actively impedes the general flow. Most people dont get the web platform compat. But unjs, cloudflare workers, and dozens of others are just amazing lovely platforms that work so well, and which are often fairly cross portable with little lift. It's fine that you are happy in your niche, but having actual well adopted interoperable protocols has let some really interesting pick & choose futures start to emerge, and it's where the early adopters are. It's where the good stuff is formenting. You don't have to be there now, you can stay in your zone, but is is growing, and it's because of wintercg interoperability efforts all centered around growing web platform ideas outward.
        zarzavat 3y ago
        That’s fair enough but you can do most of these things in Node too, it doesn’t require a new runtime. You can use browser APIs by installing a wrapper, you can use ES modules, you can (I believe) use workers although I haven’t tried that yet. The packaging situation is indeed messed up but that’s because TC39 decided to invent a maximally incompatible new module format. But you can not install CJS packages in Node just as well as you can not install them in Deno. I don’t find configuring build systems enjoyable, but the benefit is that your dev environment is not tightly coupled. If your runtime is also your build system then there’s one tool doing two jobs. Some people might like this. I personally think that this kind of coupling causes more inconvenience over the long-term even if there’s less inconvenience up front.
klabb3 3y ago
I think that in general, tooling is underrated. In many ways, tooling is more important than the language itself (although some language features are intertwined with the tooling story). And I don’t mean more features, but rather consistency, reproducibility, simplicity, etc. Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And so on…
- hu3 3y ago
  Agreed. Go is prime example of a rather (intentionally) unsexy language that sports great tooling.
  - DanielHB 3y ago
    I am not an expert in go, but I find its tooling not good at all, especially package/dependency management. But at least there is _less_ tooling required than most nodejs projects and _less_ tooling fragmentation in general. Rust/Cargo is the one I was most impressed by. But I haven't done any significant work in Rust.
- dilawar 3y ago
  +1. Before I could understand benefits of Rist, I was sold on cargo.
  - zacmps 3y ago
    I think rustdoc, rust-analyzer, and crater all deserve shout-outs as well.
no_wizard 3y ago
it can't build stylesheets or run a headless browser yet, so its not entirely a one stop shop
dzogchen 3y ago
I would argue that random segfaults are not particularly good DX.

report-to-trees 3y ago

I wasn't expecting a deep and thorough comparison just from the headline... but the feature list and comparison text here is worse than I thought it would be, bordering on useless. "Built in" means nothing because the value prop of node compared to the other two is the ecosystem and maturity. Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? "Secure by default" in particular means nothing by itself here either. Bun specifically promises better compatibility with existing npm modules then Deno so the comparison here is much different than the chart would lead you to believe.

SkyMarshal 3y ago
> Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? In general I would expect a linting tool or any other component that is a first class feature of the app would be less likely to be released with bugs and breaking changes than a third party one.
- report-to-trees 3y ago
  Sure, maybe. How would you know without doing some research into a specific project? My point was that the feature checklist here is so surface level it's useless as a practical comparison.
- paulddraper 3y ago
  Maybe?
- booi 3y ago
  In this day and age the “linting” tool does a lot more than just respond yes or no. It usually has a rules engine, templates, config file support and enforces a lot more things than just syntactical correctness. With that in mind it’s probably impossible to build a linter that’s going to be able to serve these needs that’s also built-in and on the same release cadence as the runtime itself.
Hexagon56k 3y ago
> worse than I thought it would be, bordering on useless. I'm all ears! Will revise it later today Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node. We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't think any company would read this and think "Woah, let's ditch node!" Should I list "better compatibility with existing Node modules" as a feature for Bun?

zamalek 3y ago

Deno does have a built-in package manager[1], the fact that it's not home-grown shouldn't be held against it. [1]: https://deno.land/manual@v1.36.4/basics/import_maps https://deno.land/manual@v1.36.4/basics/import_maps

SkyMarshal 3y ago

It was pretty clear what Bun’s advantages vs Node are, but less so vs Deno. This helps clarify it. It’s mainly that Bun has a built-in package manager* and minifier and Deno doesn’t. And Deno has a few extras Bun doesn’t. I imagine those will equalize somewhat with future releases. This is a helpful overview, though I would also like to see a deep dive on some categories, like security (Deno permissions vs Bun trustedDependencies). * Or maybe Deno has one too: https://news.ycombinator.com/item?id=37475462 https://news.ycombinator.com/item?id=37475462

princevegeta89 3y ago

Isn't Deno under the strong commercial grip of a couple of corporate companies, including the one that develops it?

birkskyum 3y ago
I think deno (made by Deno Company) and bun (made by Oven) are in quite similar situations here, both controlled by companies eyeing deployment services of their respective runtimes as the main source of revenue. Node is in the OpenJS Foundation, so it's in a different situation.

officialchicken 3y ago

What about a built-in standard library? That seems somewhat important.

ComputerGuru 3y ago

So where does all this backend activity leave frontend tooling? It seems the divide only grows despite the upstream attempts by the ES committee to bridge the gap.

birkskyum 3y ago
It leaves frontend tooling in a great place. All these features like built-in test runners, typescript/jsx support, faster iteration loop are quite convenient. There is still work to do for both runtimes in getting a high level of support for all the front-end frameworks, but there is good progress.
DanielHB 3y ago
Adding the bundler to the runtime is the way to go in my opinion, the code you write in your scripts/server should run exactly the same as in the browser and not require separate configuration (besides bundling-specific things like how to split your modules for lazy loading). It is crazy that every web framework these days is trying to re-solve bundling for browsers

afavour 3y ago

There’s an important column missing in the table: ownership. Both Bun and Deno are made by companies with heavy VC investment. Node is not. Don’t want to state the obvious but those VCs want to see a return on their investment and that makes me very hesitant to invest in Bun or Deno, especially at this early stage. Don’t know if it’s coincidence or if the competition has lit a fire under the Node project but it’s recently been adding some great stuff like a built in test runner and watch mode. I’m optimistic.

birkskyum 3y ago
That is true. Both deno and bun runtimes are released under MIT license, and might potentially outlive the companies behind them.
- exabyte 3y ago
  So this is a good thing with regards to your parent comment? I.e., should we feel safe using Bun despite heavy VC investment?
  - birkskyum 3y ago
    It depends on the project how conservative you have to be, and what to emphasize. Generally, this company is very fast moving, so waiting some months could make it significantly easier to gauge if it's a good fit.
- Rapzid 3y ago
  There are a relative handful of people willing and able to work on these projects. Lots of OSS software just gets abandoned when their corporate sponsors stop developing them; like Chakra Core and a bunch of Mozilla projects.
yieldcrv 3y ago
My positive experience with NextJS by VC backed Vercel ($2.5bn valuation) makes me not skeptical of a package by mere nature of it being maintained and marketed by a for profit company with heavy VC investment. Its all about how it integrates and how it avoids vendor lock in.

yeck 3y ago

Bun is getting a lot of hype due to all the press, but almost everyone is just echoing Bun's docs and marketing material and lack direct experience using it. I haven't done a deep dive into Bun yet, but I have tried porting a legacy project to it. Hit a lot of issues after a few hours of hacking around. It wouldn't correctly install node modules because of opt-in dependency lifecycles (and maybe other issues?) and then I couldn't use it to execute the existing webpack build without encountering opaque runtime errors. The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm.

rz2k 3y ago
Wasn’t version 1.0.0 released three days ago? I think people are surprised that the performance claims don’t completely disappear with real world scenarios. It seems like a lot of eventually successful platforms began in the same way: the claims about improvements are real, and there are still a lot of rough edges.
TheFreim 3y ago
> The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm. There was discussion about this the other day. It's marketed as a "drop-in" replacement but from perusing HN and elsewhere I see people having issues with real projects. It looks like a promising project, which I hope succeeds, but there also seems to be an unfortunate amount of marketing that, as you note, is being uncritically repeated.
hk1337 3y ago
It seems like it has potential but I tried using it with a Shopify app I am building and for some reason it wasn't automatically creating the cloudflare tunnel in dev mode. Also, there's no verbose flag to show more detailed log message.
DanielHB 3y ago
I think running a bundler on top of bun defeats half of the purpose of the tool, unfortunately bun's own bundler is still very lackluster and definitely not good enough to use. On top of that most of the popular frontend frameworks (Vite, NextJS, etc) are doing their own bundling so I wouldn't use bun with those tools either. I would consider it only for backend nodejs at the moment.

nnx 3y ago

One under-advertised unique feature of Bun is that it supports proper tail calls, thanks to the JavascriptCore runtime. Both Node and Deno, using V8, do not support those so some (functional) algos are harder to express there.

yieldcrv 3y ago

Any real benchmarks with version 1.0? Has anybody replaced everything with Bun in their 100 dependency project with a loose scaffolding of a deprecated node version due to some crucial dependency This is the kind of thing I want to see even before using bun in a greenfield project

evnix 3y ago
Did this recently, on a largish project based on express and typeorm. The only issue we had was with a native image manipulation library in combination with alpine linux image which was an easy fix. Rest worked flawlessly. Performance wasn't an issue for us, Dev experience was really bad on Node and the amount of hacks required to get esm/commonjs working in tandem was insane. Bun got rid of a lot of those hacks and we are slowly cleaning up the codebase.

rcarmo 3y ago

For me, the key thing that is missing is dgram (UDP) support. Makes bun unusable for a lot of IoT scenarios.

ryapric 3y ago
Why would you want to use JavaScript in IoT scenarios?
- rcarmo 3y ago
  Well, Node-RED for starters. Plus homebridge, and plenty of UPNP and protocol-specific solutions that, for some reason, are coded in JavaScript.
- DanielHB 3y ago
  I do it at my company, to talk to microcontrollers. We have a few CLI tools we use for testing that run on NodeJS. Our web-wrapped maintenance desktop application also sends UDP packages directly to microcontrollers but there we do it a bit differently. We have a proxy that forwards websocket messages as UDP packets running in the native code of our desktop application. Would be really nice if we could send UDP messages directly from the browser, but it is understandable from security perspective.

Akronymus 3y ago

Can one use bun in combination with something like aspnet core to replace vite, for example? Or am I fundamentally misunderstanding what bun is?