4 ms·

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I'

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.

paulddraper 4mo ago
Bun prioritized Node.js compatibility. Deno since adjusted, but Bun gained a lot of market share in the meantime.
yroc92 5mo ago
I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.
- 3uler 5mo ago
  But if you look at the node compliance tests, deno has better compliance now days…
  - CharlesW 4mo ago
    Insanely better, at 76% Node compliance in Deno 2.8. Bun 1.3.14 is at just 40.6% with same compliance test. https://node-test-viewer.deno.dev/ https://node-test-viewer.deno.dev/
  - garbagepatch 4mo ago
    I guess Bun had the better marketing then. I liked how every new feature came with a benchmark against the previous version and node. See this for example: https://xcancel.com/bunjavascript/status/2048228152397459590 https://xcancel.com/bunjavascript/status/2048228152397459590 I'd love to see a site comparing the 3 of them in a similar way.
WorldMaker 5mo ago
I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines. (It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
- vmg12 5mo ago
  I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.
  - WorldMaker 4mo ago
    I'm not suggesting it is a conscious decision point. Node has since done a lot to catch up on "less configuration" but Bun still seems to be growing even as what Bun does well Node starts to emulate. Runtime performance is mentioned in this thread here and elsewhere and while some are attributing that to Zig I think some are overlooking the different runtime experience of JavaScriptCore. It's also the "only" runtime difference between Deno and Bun if you assume that Rust and Zig are similarly performant native layers for some saying they like Bun's runtime performance better than Deno's.
npn 5mo ago
because for most people they don't need what deno promises. me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each). bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing. too bad it is a failed promise now.
- robflynn 4mo ago
  I hadn't heard of crystal somehow, I work with ruby a lot so that might be fun to play around with.
wk_end 5mo ago
When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that. But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.
vmg12 5mo ago
Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things). So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration. I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years. Edit: And Deno is now more compatible with node than bun.
- tuananh 5mo ago
  > Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. and yet Bun's npm compat is much much lower than deno https://x.com/rough__sea/status/2057579066744881188 https://x.com/rough__sea/status/2057579066744881188
  - vmg12 5mo ago
    I was talking about the history and not the current state of the projects if that was not obvious.
- nailer 4mo ago
  (thinking emoji) they could merge. Seriously, they're both Rust now. They share goals.
  - tomjakubowski 4mo ago
    I doubt it would work out. The engineering cultures could not be any different.
    - sysguest 4mo ago
shepherdjerred 4mo ago
I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite. So, I switched to Bun and things have been much smoother!
dmit 4mo ago
> Can someone explain why it sounds like there's such rapid growth of Bun? In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
- satvikpendem 4mo ago
  But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
  - sysguest 4mo ago
    well benchmarks that's why if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness... I should check actual perf numbers... well next week or month?
  - sheept 4mo ago
    Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno. Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind. Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
    - sysguest 4mo ago
      yeah it's such a pity deno's security features could have made recent npm attacks moot...
vorticalbox 4mo ago
I think the main issue was when deno first came out it used urls for imports then later added support for npm. By then bun was already a thing and just ate into its share.
- VerifiedReports 4mo ago
  Why do you consider URLs a problem?
  - satvikpendem 4mo ago
    Annoying to update instead of a package.json, which they now have an equivalent of, realizing their mistake.
  - vorticalbox 4mo ago
    I don’t consider them a problem at all. It’s how browsers have worked for a long time. My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction. Personally I would have like deno it stick with url imports and not added the npm support. Ryan set out to “fix” his mistakes with node only to fully embrace them again.
  - AgentME 4mo ago
    One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.) Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.) (Deno's current support for NPM and JSR avoids these issues.)
yoyohello13 4mo ago
Same, I'm mostly a back end dev but when I dip my toes into frontend for personal projects Deno just seems like the most sane choice. It's really nice to work with. I'm kind of sad it doesn't seem to have taken off among the JS folks.
ddosmax556 4mo ago
I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web. This is an annoying to do for exactly two platforms: node.js, and deno. node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works! Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error. Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated. Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports. So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that! I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.
- bartlomieju 4mo ago
  Thanks for feedback, I opened a PR to implement linking functionality that seems more familiar to npm's strategy: https://github.com/denoland/deno/pull/34359 https://github.com/denoland/deno/pull/34359
giancarlostoro 4mo ago
Deno is from scratch attempting to pass as many NodeJS tests as possible. Bun piggybacks off the WebkitJS library iirc and shims anything nodejs specific it needs.
culi 4mo ago
Bun had some early (imo, extremely deceptive) benchmarks that showed it had really good performance compared to Node and Deno. Zig was also a fledgling hotlang and Bun managed to translate the Zig community into more energy behind Bun. In addition to that, the creator of Bun became a minor celebrity for spending probably over 12 hours almost every single day working on it. Everything just came together at the right time really quickly and they managed to capitalize on it. Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.
cptmurphy 4mo ago
Deno permission system is so basic. What you need is capability system
- AgentME 4mo ago
  Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)
  - vrighter 4mo ago
    one more reason I would have preferred a world in which lua was used in js's place
    - AgentME 4mo ago
      Isn't Lua equally monkey-patchable? Both of the languages, along with Python and Ruby, represent nearly everything as mutable objects.
      - vrighter 4mo ago
        but you can relatively easily sandbox anything you want and close all escape hatches. If you want to turn off the monkeypatching functionality, that's just a metatable or two away. I can and regularly disable monkeypatching on some of my libraries (especially where it interacts with c++ interop). JS now has proxy objects, but lua has been able to do this since way before And also those stackful coroutines, would have made callback hell non-existent, and no async/await function coloring either (as long as you started one coroutine somewhere up the call stack.
chamomeal 4mo ago
I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node. Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now. Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice
- wiseowise 4mo ago
  > Node always felt immature compared to stuff like go or java. Not enough boilerplate and EnterpriseBeanFactorySingleton?
  - chamomeal 4mo ago
    Lmao well I still prefer node to java for many reasons. But if anybody is looking for EnterpriseBeanFactorySingleton in node world, nestjs scratches that itch of a 5:1 boilerplate-to-biz-logic ratio
nsonha 4mo ago
"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here). Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.
spixy 4mo ago
Because I don't care about that permission system. Server will run in some container or k8s anyway. And node / bun development is much easier because of many many npm packages.
- interstice 4mo ago
  Although the attacks on the NPM ecosystem are making that sound more like a liability by the day.
wiseowise 4mo ago
> Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Bundler + used by Claude Code, that’s pretty much it.
pier25 4mo ago
Bun doesn't require special tooling since it uses standard TS and follows the Node conventions. With Deno you need special tooling for eg the weird import system and package manager. Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc. Finally, Bun overall has better performance and efficiency compared to Deno. That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.

paulddraper 4mo ago

Bun prioritized Node.js compatibility. Deno since adjusted, but Bun gained a lot of market share in the meantime.

yroc92 5mo ago

I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.

3uler 5mo ago
But if you look at the node compliance tests, deno has better compliance now days…
- CharlesW 4mo ago
  Insanely better, at 76% Node compliance in Deno 2.8. Bun 1.3.14 is at just 40.6% with same compliance test. https://node-test-viewer.deno.dev/ https://node-test-viewer.deno.dev/
- garbagepatch 4mo ago
  I guess Bun had the better marketing then. I liked how every new feature came with a benchmark against the previous version and node. See this for example: https://xcancel.com/bunjavascript/status/2048228152397459590 https://xcancel.com/bunjavascript/status/2048228152397459590 I'd love to see a site comparing the 3 of them in a similar way.

WorldMaker 5mo ago

I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines. (It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)

vmg12 5mo ago
I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.
- WorldMaker 4mo ago
  I'm not suggesting it is a conscious decision point. Node has since done a lot to catch up on "less configuration" but Bun still seems to be growing even as what Bun does well Node starts to emulate. Runtime performance is mentioned in this thread here and elsewhere and while some are attributing that to Zig I think some are overlooking the different runtime experience of JavaScriptCore. It's also the "only" runtime difference between Deno and Bun if you assume that Rust and Zig are similarly performant native layers for some saying they like Bun's runtime performance better than Deno's.

npn 5mo ago

because for most people they don't need what deno promises. me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each). bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing. too bad it is a failed promise now.

robflynn 4mo ago
I hadn't heard of crystal somehow, I work with ruby a lot so that might be fun to play around with.

wk_end 5mo ago

When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that. But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.

vmg12 5mo ago

Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things). So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration. I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years. Edit: And Deno is now more compatible with node than bun.

tuananh 5mo ago
> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. and yet Bun's npm compat is much much lower than deno https://x.com/rough__sea/status/2057579066744881188 https://x.com/rough__sea/status/2057579066744881188
- vmg12 5mo ago
  I was talking about the history and not the current state of the projects if that was not obvious.
nailer 4mo ago
(thinking emoji) they could merge. Seriously, they're both Rust now. They share goals.
- tomjakubowski 4mo ago
  I doubt it would work out. The engineering cultures could not be any different.
  - sysguest 4mo ago

shepherdjerred 4mo ago

I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite. So, I switched to Bun and things have been much smoother!

dmit 4mo ago

> Can someone explain why it sounds like there's such rapid growth of Bun? In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

satvikpendem 4mo ago
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
- sysguest 4mo ago
  well benchmarks that's why if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness... I should check actual perf numbers... well next week or month?
- sheept 4mo ago
  Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno. Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind. Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
  - sysguest 4mo ago
    yeah it's such a pity deno's security features could have made recent npm attacks moot...

vorticalbox 4mo ago

I think the main issue was when deno first came out it used urls for imports then later added support for npm. By then bun was already a thing and just ate into its share.

VerifiedReports 4mo ago
Why do you consider URLs a problem?
- satvikpendem 4mo ago
  Annoying to update instead of a package.json, which they now have an equivalent of, realizing their mistake.
- vorticalbox 4mo ago
  I don’t consider them a problem at all. It’s how browsers have worked for a long time. My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction. Personally I would have like deno it stick with url imports and not added the npm support. Ryan set out to “fix” his mistakes with node only to fully embrace them again.
- AgentME 4mo ago
  One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.) Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.) (Deno's current support for NPM and JSR avoids these issues.)

yoyohello13 4mo ago

Same, I'm mostly a back end dev but when I dip my toes into frontend for personal projects Deno just seems like the most sane choice. It's really nice to work with. I'm kind of sad it doesn't seem to have taken off among the JS folks.

ddosmax556 4mo ago

I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web. This is an annoying to do for exactly two platforms: node.js, and deno. node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works! Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error. Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated. Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports. So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that! I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.

bartlomieju 4mo ago
Thanks for feedback, I opened a PR to implement linking functionality that seems more familiar to npm's strategy: https://github.com/denoland/deno/pull/34359 https://github.com/denoland/deno/pull/34359

giancarlostoro 4mo ago

Deno is from scratch attempting to pass as many NodeJS tests as possible. Bun piggybacks off the WebkitJS library iirc and shims anything nodejs specific it needs.

culi 4mo ago

Bun had some early (imo, extremely deceptive) benchmarks that showed it had really good performance compared to Node and Deno. Zig was also a fledgling hotlang and Bun managed to translate the Zig community into more energy behind Bun. In addition to that, the creator of Bun became a minor celebrity for spending probably over 12 hours almost every single day working on it. Everything just came together at the right time really quickly and they managed to capitalize on it. Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.

cptmurphy 4mo ago

Deno permission system is so basic. What you need is capability system

AgentME 4mo ago
Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)
- vrighter 4mo ago
  one more reason I would have preferred a world in which lua was used in js's place
  - AgentME 4mo ago
    Isn't Lua equally monkey-patchable? Both of the languages, along with Python and Ruby, represent nearly everything as mutable objects.
    - vrighter 4mo ago
      but you can relatively easily sandbox anything you want and close all escape hatches. If you want to turn off the monkeypatching functionality, that's just a metatable or two away. I can and regularly disable monkeypatching on some of my libraries (especially where it interacts with c++ interop). JS now has proxy objects, but lua has been able to do this since way before And also those stackful coroutines, would have made callback hell non-existent, and no async/await function coloring either (as long as you started one coroutine somewhere up the call stack.

chamomeal 4mo ago

I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node. Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now. Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice

wiseowise 4mo ago
> Node always felt immature compared to stuff like go or java. Not enough boilerplate and EnterpriseBeanFactorySingleton?
- chamomeal 4mo ago
  Lmao well I still prefer node to java for many reasons. But if anybody is looking for EnterpriseBeanFactorySingleton in node world, nestjs scratches that itch of a 5:1 boilerplate-to-biz-logic ratio

nsonha 4mo ago

"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here). Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.

spixy 4mo ago

Because I don't care about that permission system. Server will run in some container or k8s anyway. And node / bun development is much easier because of many many npm packages.

interstice 4mo ago
Although the attacks on the NPM ecosystem are making that sound more like a liability by the day.

wiseowise 4mo ago

> Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Bundler + used by Claude Code, that’s pretty much it.

pier25 4mo ago

Bun doesn't require special tooling since it uses standard TS and follows the Node conventions. With Deno you need special tooling for eg the weird import system and package manager. Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc. Finally, Bun overall has better performance and efficiency compared to Deno. That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.