81–90 of 193 posts
Earlier quoted context omitted.
> Plus, bought by Anthropic. Who thinks this is a positive?!
It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
Earlier quoted context omitted.
> 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.
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
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?
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 extend…
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.
And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.
Well done Deno team.
Earlier quoted context omitted.
It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
Yes, famously, acquisitions only make services more reliable, as in the case of Microsoft and Github, or Apple and DarkSky.
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 extend…
Earlier quoted context omitted.
> 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.
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over 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.
Earlier quoted context omitted.
> 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.
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
Earlier quoted context omitted.
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
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…
Earlier quoted context omitted.
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.)
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.