Request for the bun team: please provide a clear support policy/EOL timeline. Bonus points for clarity on the stability guarantees that are offered between versions and modules.
I don't think the bun devs are currently parcelling things up like that so doubt this would be worth the effort at this time, i.e. I don't think they're backporting any fixes from 1.1 into a 1.0.x release.
I use both Deno and Bun in production (albeit, on different projects).
They are both great upgrades from node. In particular with the first class support for TypeScript.
Bun is great for large projects with the enhanced DX over any node based environments I have worked on - I use it for a mono-repo project with several frontends and a GraphQl backend. Involved test suites run in 5 seconds, etc.
Deno seems to work really well i lambda style environment (I use them with Supabase) due to their module approach that are entirely stand alone. This is great for small scripts to glue things together.
Bun has -i/--install=fallback which I thought was pretty similar to Deno but I haven't used Deno much to compare. I was thinking about starting to write my scripts with `#!bun -i` but haven't fiddled with it much yet.
The API for the shell function is kind of neat, in that it seems to prevent you from accidentally creating shell injection vulnerabilities by calling it without properly quoting the arguments.
It uses types to get quoting right? Or it quotes everything (regardless if it's already quoted)?
Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)
Formatters basically differentiate the literal parts of the string and the template arguments. There's also a neat postgres library that does the same for sql quoting.
Tagged templates[0], the language feature that enables this, were introduced in ECMAScript 2015 apparently – arguably at least somewhat new in the lifespan of JavaScript. :)
Java is getting a similar feature with template processors[1], currently in preview.
It would be nice to have it in Python as well – i.e. not just f-strings, but something that (like tagged templates) allows a template function process the interpolated values to properly encode them for whatever language is appropriate (e.g. shell, SQL, HTML, etc.). Apparently someone is working on a proposal[2], although there doesn't seem to be much recent progress.
Wow that’s pretty neat. Because of that I also learned about import attributes (https://github.com/tc39/proposal-import-attributes) which is probably going to be quite useful and make the 50 lines of imports in some of my files look even dumber.
Seems like a good release.
I watched their video, and some charts were a bit unclear, as in, I didn't know if they were comparing with the previous Bun version or Node.js.
My experience with using Bun in side projects has been good. The built-in APIs work well in my experience, and I hope popular runtimes adopt at least a subset of them. The hashing and the SQLite bindings come to mind as APIs that I wish were available in Deno and Node.js as well.
They collect some telemetry by default. I don't think the install script tells you that. The only mention of it that I've found is in the Bunfile documentation: https://bun.sh/docs/runtime/bunfig#telemetry
I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation.
They offer an option to create a dependency-free executable for your project, which bundles the runtime with your .js entrypoint. That works great if you want a single binary to distribute to users, but at the moment, the file size is still pretty big (above 90MB on GNU/Linux for a small project). Not terrible, but nothing comparable to Go or QuickJS yet. I wonder if in the future, Bun would offer an option to compile itself with certain features disabled, so we'd get a smaller binary.
I have been playing with using Bun as a Haxe target. It works pretty well and IMO it's a choice to consider if you like Haxe more than TypeScript, or if you want to add a web server to an existing Haxe project without adding another programming language. You can also to do things like generating validation code at compile time, which seems hard to do with just TypeScript.
Note that we do not currently send telemetry anywhere. The extent of what we track right now is a bitset of what builtin modules were imported and a count of how many http requests were sent with fetch(), and a few things like that. This is used in the message printed when Bun panics so we can have a better idea of what the code was doing/did when it crashed
Sorry, I didn't understand your post. From the last 2 phrases, it seems to be the case that you do collect some data.
So, when you say
> Note that we do not currently send telemetry anywhere.
You mean that Oven do not send that data to someone else, right?
I still see value in having a privacy policy so that users can find out what is collected by Oven in a concise way, and how to opt out of that. As far as I know, the fact that any data is collect at all, and that there's a flag to disable it is only mentioned in a documentation page for Bun's TOML config file.
That is unrelated. This is a code signing / notarization issue because we don’t distribute Bun via the Mac App Store and likely the way it was installed was via npm or something other than .zip file we distribute. Code signing is necessary due to the JIT entitlement in Bun (otherwise Bun would be a whole lot slower)
> I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation.
So you mean an informed opt-out, right?
Thank you for the interesting hands-on experiences and insights regarding Bun. I followed the coverage and posts by Jarred here on HN for quite a while, think since the initial alpha release, but haven't used it.
Will keep your examples for helpful added platform APIs in mind for when I hopefully come around to doing sth with Bun!
It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters.
Really, kudos to Bun and Jarred Sumner for living up to the promise he made when the first version was announced!
> So you mean an informed opt-out, right?
I worded it wrong - I meant I'd prefer if it was opt-in, or at least informed opt-out, like you said. Thanks for pointing it out. :)
> It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters.
It is. Some other features you might enjoy are the built-in TypeScript support and test runner. It works well for one-off scripts too, if you'd prefer not using Bash.
For me, it was refreshing coming from Node.js. Hope it is an enjoyable experience for you as well.
Now that Discord will start showing ads, is there any chance Bun will support a communication platform that is open & ad-free like IRC, XMPP, or Matrix?
What kind of question is this? He is working on a JavaScript/TypeScript runtime not building a communication product. Why would you run to him to solve your pet grievance with Discord?
The opt-out telemetry is worrisome. Along with the fact that there doesn't appear to be a way to disable it for single-file executables if you plan to distribute a Bun cli app to users: https://github.com/oven-sh/bun/issues/8927
Are there plans for adding concurrent or parallel execution to the test runner? I recently tried looking at the code base to maybe implement it myself, and it looks like it wouldn't be easy without some reworks.
We need to do some form of this but I’m not exactly sure what yet. I suspect same process but multiple globals might work well. A lot of tests spend time sleeping or waiting for things. They might benefit from that kind of paralellism (like async/await, except between things it runs a whole other global object)
Threads could also work but the problem is you have to re parse & evaluate all the code. That’s a lot of duplicate work. It’s probably still worth it for large enough apps
I find it hilarious that we now present runtimes and other programming stuff like it was Apple presenting a new iPhone. This would be satire 15 years ago. No disrespect to Bun tho, I love Bun.
I feel like such a downer when I ask this about Bun and Deno, but: why should I use them instead of Node?
I don’t mean to take away from the obviously impressive engineering effort here. But VC funding always gives me pause because I don’t know how long the product is going to be around. I was actually more interested in Deno when it promised a reboot of the JS ecosystem but both Bun and Deno seem to have discovered that Node interoperability is a requirement so they’re all in the same (kinda crappy) ecosystem. I’m just not sure what the selling point is that makes it worth the risk.
We could drastically simplify the building and deployment process of our services. By far the greatest advantage is that it runs TS natively. Dropping the compilation stage simplifies everything. From docker imaging to writing DB migrations to getting proper stack traces.
You don't need source maps. You don't have to map printed stack traces to the source. Debugging just works. You don't need to configure directories because src/ is different than dist/ for DB migrations. You don't have to build a `tsc --watch & node --watch` pipeline to get hot reloading. You don't need cross-env. No more issues with cjs/esm interop. Maybe you don't even need a multi-stage Dockerfile.
That's for bun. Deno might have a similar story. We did not opt-in to the Bun-specific APIs, so we can migrate back if Bun fails. Maybe we could even migrate to something like ts-node. Shouldn't be that hard in that case.
IMHO the API of Bun, as well as the package manager, sometimes tries to be _too_ convenient or is too permissive.
Kind of. When you do try to run bun in production you'll find out that it has significant differences to node -- like not handling uncaught exceptions: https://github.com/oven-sh/bun/issues/429
Curious: does it run TS natively or does it just transpile for you? Because the former suggests exciting opportunity for better compiling or JITting if it can actually commit to holding on to the typing.
I'm not sure how difficult it would be for Nodejs to support .ts files natively. But if that's the main reason to use Bun, I'd be worried about its long term viability. Node could announce native .ts support at any time and then Bun might not look so good.
The most compelling argument for Deno is the permission system in my opinion. Node added a permission system recently, but it's much more coarse grained than Deno's. Being able to limit a script to listening on a specific hostname and port, or only allowing it to read a specific environment variable is pretty cool, and makes me less paranoid about trusting third party dependencies. Both Bun and Deno are also more performant than Node in many cases, and add a bunch of little quality of life improvements.
The real question is how much you can trust this. Those kinds of permission systems have been tried before - e.g. .NET used to have something called "Code Access Security". It was retired largely because the very notion of VM-enforced sandbox was deemed inadequate from experience. IIRC SecurityManager in Java was something similar, also deprecated for similar reasons. I'm afraid that Deno will just be a repeat of that.
Imho those permission systems are still too rudimentary and too non-automated. Instead of CLI flags I would like to see permission enforced at dependency boundaries, e.g.
import foo from 'foo' with {permissions: ['fs', 'net']}
The speed increases are nothing to sneeze at; I've moved a few Vite projects over to Bun and even without specific optimizations it's still noticeably faster.
A specific use case where Bun beat the pants out of Node for me was making a standalone executable. Node has a very VERY in-development API for this that requires a lot of work and doesn't support much, and all the other options (pkg, NEXE, ncc, nodejs-static) are out-of-date, unmaintained, support a single OS, etc.
`bun build --compile` worked out-of-the-box for me, with the caveat of not supporting native node libraries at the time—this 1.1 release fixes that issue.
Bun's standalone executables are great, but as far as I'm aware unlike Deno and Node there's no cross compilation support, and Node supports more CPU/OS combinations than either Deno or Bun. Node supports less common platforms like Windows ARM for example (which will become more important once the new Snapdragon X Elite laptops start rearing their heads [1]).
It also helps avoid a node/v8 monoculture, just like with web browsers. I'm sure the ecosystem as a whole will get better because of it, even if you decide not to use it.
I can give a bit of perspective here.
I'm currently porting our the Vanilla Forums frontend (~500k lines of typescript) from using Node, Yarn (we used it back before npm supported lockfiles) and Webpack, to build with bun and Vite.
There are a few notable differences:
- The out of the box typescript interoperability is actually very nice, and much faster than using `ts-node` as we were before.
- Installations (although rare) are a fair bit faster.
- With bun I don't have to do the frankly crazy song and dance that node now requires for ES modules.
- Using bun is allowing us to drop `jest` and related packages as a dependency entirely and it executes our test suite a lot faster than jest did.
For my personal projects I now reach for bun rather than node because
- It has Typescript support out of the box.
- It has a nice test runner out of the box.
- It has much runtime compatibility with browsers (`fetch` is a good example).
- The built-in web server is sufficient for small projects and avoids the need to pull in various dependencies.
My old dog experience has proven multiple times that staying with the main reference tool for the platform always pays out long term, as most forks or guest languages eventually fade out after the hype cycle is over.
The existing tools eventually get the features that actually matter, and I avoided rewriting stuff twice, on the meantime I gladly help some of those projects to backport into the reference tooling for the platform.
The only place I really haven't followed this approach was in regards to C++ in UNIX, which at first sight might feel I am contradicting myself, however many tend to forget C++ was born at Bell Labs, on the same building as UNIX folks were on, and CFront tooling was symbiotic with UNIX.
ESM interop is inarguable. But these days Node has a test runner and compatibility with browsers (it implements fetch)… I guess I feel like Node is likely to catch up with most of this stuff over the lifetime of any long running project.
I really like Deno for small scripts and small side projects - it's just fast to get started with. And it allows me to use web standards, like URL imports to grab packages from CDNs instead of having a config file. There's just less to think about, like oh what was Node's crypto thing? Node is making strides in web compatibility, and building in things like a test runner. And I don't have much interest in migrating company projects away from Node. But Deno feels really fresh and light when I just need to run some JS.
Node is safe choice, IMO. I tried deno and I think it's cool, but I'm staying on node for the time being. Things that deno makes easier are not that hard with node and stability matters for me. For example I had to spend few hours rewriting my tiny service with changed deno API. Don't have any experience with bun, though.
If there are any specific places where Deno didn't support a node API, please file a bug -- we definitely shoot for as close to node.js as possible, and if you have to modify your code that's most often on us.
I have ask myself the same question a couple of weeks ago and decided to use Node for some side stuff. Simply because of Node being the most mature, boring choice. Still, I like the DX improvements of both Bun and Deno a lot. We'll see how it all plays out in some years.
And UX is pretty great: integrated fetch, simplified fs api, integrated test runner (I miss good old TAP style assertions though), ESM/CJS modules just work, some async sugar.
I think if they offer me a paid *worker solution, with sqlite, that's something I'm willing to pay for.
I don't know how you're using Node and not thinking "I wish there was a better option than this". I can't wait to jump ship but Bun/Deno aren't quite there yet, for my needs.
I haven’t used them yet for full sized apps, but they are both fantastic for scripting and small CLIs. Between the ease of running scripts, nice standard libraries, npm ecosystem, and excellent type system, I now feel TypeScript is a better scripting language than Python or Ruby.
I used to think so too, but that was because I had never really used Python. I still think Ruby is a mess, but it's so amazing how easy it is to manipulate data in Python, and so much faster.
I recently wrote a Node/Bun/Deno app that parses a 5k line text file into JSON.
The JavaScript on any runtime takes 30-45 seconds.
The Python implementation is sub 1 second.
I would not have been able to finish the tool so quickly if I were stuck relying on JS.
I still love Typescript but I'm not as blind about it now.
Readit News
https://github.com/oven-sh/bun/issues/7990 (Via https://github.com/endoflife-date/endoflife.date/pull/4382)
https://nodejs.org/en/about/previous-releases#release-schedu...
or:
https://devguide.python.org/versions/
They are both great upgrades from node. In particular with the first class support for TypeScript.
Bun is great for large projects with the enhanced DX over any node based environments I have worked on - I use it for a mono-repo project with several frontends and a GraphQl backend. Involved test suites run in 5 seconds, etc.
Deno seems to work really well i lambda style environment (I use them with Supabase) due to their module approach that are entirely stand alone. This is great for small scripts to glue things together.
For example, in Python you could easily do this:
But the Bun API doesn't separate quoting from executing the command, so you can't make that kind of mistake:Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)
Java is getting a similar feature with template processors[1], currently in preview.
It would be nice to have it in Python as well – i.e. not just f-strings, but something that (like tagged templates) allows a template function process the interpolated values to properly encode them for whatever language is appropriate (e.g. shell, SQL, HTML, etc.). Apparently someone is working on a proposal[2], although there doesn't seem to be much recent progress.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://openjdk.org/jeps/459
[2] https://github.com/jimbaker/tagstr/blob/main/docs/pep.rst
In the past I've written a little plugin that is available for almost all bundlers allowing you to do that: https://dev.to/florianrappl/getting-bundling-superpowers-usi...
It's way overdue to have some way to program what happens at bundling time (without writing your own bundler plugin)
import iconUrl from './my-icon.svg?url'
Maybe I'm not imaginative enough but this seems like a reasonably restricted (i.e. simple) way of parametrizing imports.
My experience with using Bun in side projects has been good. The built-in APIs work well in my experience, and I hope popular runtimes adopt at least a subset of them. The hashing and the SQLite bindings come to mind as APIs that I wish were available in Deno and Node.js as well.
They collect some telemetry by default. I don't think the install script tells you that. The only mention of it that I've found is in the Bunfile documentation: https://bun.sh/docs/runtime/bunfig#telemetry
I'd prefer if it was opt-in, and that users were given instructions for disabling it if they want to during installation.
They offer an option to create a dependency-free executable for your project, which bundles the runtime with your .js entrypoint. That works great if you want a single binary to distribute to users, but at the moment, the file size is still pretty big (above 90MB on GNU/Linux for a small project). Not terrible, but nothing comparable to Go or QuickJS yet. I wonder if in the future, Bun would offer an option to compile itself with certain features disabled, so we'd get a smaller binary.
I have been playing with using Bun as a Haxe target. It works pretty well and IMO it's a choice to consider if you like Haxe more than TypeScript, or if you want to add a web server to an existing Haxe project without adding another programming language. You can also to do things like generating validation code at compile time, which seems hard to do with just TypeScript.
So, when you say
> Note that we do not currently send telemetry anywhere. You mean that Oven do not send that data to someone else, right?
I still see value in having a privacy policy so that users can find out what is collected by Oven in a concise way, and how to opt out of that. As far as I know, the fact that any data is collect at all, and that there's a flag to disable it is only mentioned in a documentation page for Bun's TOML config file.
I wondered why every time I upgraded bun macos would pop up a permissions dialog. This explains that.
Anyway, it can be disabled by adding the following to your environment:
This is the data collected:https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
This 64 bit machine_id line is concerning:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
It may be a unique identifier for your machine.
So you mean an informed opt-out, right?
Thank you for the interesting hands-on experiences and insights regarding Bun. I followed the coverage and posts by Jarred here on HN for quite a while, think since the initial alpha release, but haven't used it.
Will keep your examples for helpful added platform APIs in mind for when I hopefully come around to doing sth with Bun!
It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters.
Really, kudos to Bun and Jarred Sumner for living up to the promise he made when the first version was announced!
> It sounds like a great platform for JS scripting as well - I also think that could be a good and easy way to test the waters.
It is. Some other features you might enjoy are the built-in TypeScript support and test runner. It works well for one-off scripts too, if you'd prefer not using Bash. For me, it was refreshing coming from Node.js. Hope it is an enjoyable experience for you as well.
Note that Bun v1.1 is still compiling at the time of writing (probably for another 20 minutes)
Threads could also work but the problem is you have to re parse & evaluate all the code. That’s a lot of duplicate work. It’s probably still worth it for large enough apps
I think I saw somewhere that 1.0 did not support NextJS. Does 1.1?
On my rpi 4 that I capped to 600mhz for performance testing:
Bun v1.1.0 is out! You're on 1.0.36 [3.93s] Upgraded.
My intuition is that there are many more consumers of node-like environments today than any runtimes 15 years ago.
This combined with the Wayback machine makes for a great way to keep track of detailed information
I don’t mean to take away from the obviously impressive engineering effort here. But VC funding always gives me pause because I don’t know how long the product is going to be around. I was actually more interested in Deno when it promised a reboot of the JS ecosystem but both Bun and Deno seem to have discovered that Node interoperability is a requirement so they’re all in the same (kinda crappy) ecosystem. I’m just not sure what the selling point is that makes it worth the risk.
You don't need source maps. You don't have to map printed stack traces to the source. Debugging just works. You don't need to configure directories because src/ is different than dist/ for DB migrations. You don't have to build a `tsc --watch & node --watch` pipeline to get hot reloading. You don't need cross-env. No more issues with cjs/esm interop. Maybe you don't even need a multi-stage Dockerfile.
That's for bun. Deno might have a similar story. We did not opt-in to the Bun-specific APIs, so we can migrate back if Bun fails. Maybe we could even migrate to something like ts-node. Shouldn't be that hard in that case.
IMHO the API of Bun, as well as the package manager, sometimes tries to be _too_ convenient or is too permissive.
Then you'll use bun build and run node in production, only to find that sourcemaps don't actually work at all: https://github.com/oven-sh/bun/issues/7427
So you'll switch to esbuild + node in production :)
Definitely excited for the promise of bun, but it's not quite baked yet.
node --import tsx ./file.ts
not everyone likes typescript or finds it useful. e.g svelte dropping typescript ?
not to take away the amazing work people at bun have done.
So why doesn't any major runtime run Java natively? Or C++ natively? Or Rust natively?
Why is this such a cool unlock that hasn't been done for any other language?
---
85% of this are people tired/bored of Node.js.
A specific use case where Bun beat the pants out of Node for me was making a standalone executable. Node has a very VERY in-development API for this that requires a lot of work and doesn't support much, and all the other options (pkg, NEXE, ncc, nodejs-static) are out-of-date, unmaintained, support a single OS, etc.
`bun build --compile` worked out-of-the-box for me, with the caveat of not supporting native node libraries at the time—this 1.1 release fixes that issue.
I documented how to build a binary from a JS app with node, deno, and bun here [2]. Node SEA is a bad DX, but not that complex once you figure it out.
1: https://github.com/oven-sh/bun/issues/6832
2: https://github.com/llimllib/node-esbuild-executable
[1] https://www.youtube.com/watch?v=uWH2rHYNj3c
Bun is really nicely compatible with node.
Speed of course is excellent, but the main reason I use Bun and recommend it:
You replace node, npm, tsx, jest, nodemon and esbuild with one single integrated tool that's faster than all of the others.
We banned all these forks at work.
The dev onboarding overhead is not worth the benefits.
Having all 1700 repos using the same build tooling is more important than slight increases in build performance.
There are a few notable differences:
- The out of the box typescript interoperability is actually very nice, and much faster than using `ts-node` as we were before.
- Installations (although rare) are a fair bit faster.
- With bun I don't have to do the frankly crazy song and dance that node now requires for ES modules.
- Using bun is allowing us to drop `jest` and related packages as a dependency entirely and it executes our test suite a lot faster than jest did.
For my personal projects I now reach for bun rather than node because
- It has Typescript support out of the box.
- It has a nice test runner out of the box.
- It has much runtime compatibility with browsers (`fetch` is a good example).
- The built-in web server is sufficient for small projects and avoids the need to pull in various dependencies.
The existing tools eventually get the features that actually matter, and I avoided rewriting stuff twice, on the meantime I gladly help some of those projects to backport into the reference tooling for the platform.
The only place I really haven't followed this approach was in regards to C++ in UNIX, which at first sight might feel I am contradicting myself, however many tend to forget C++ was born at Bell Labs, on the same building as UNIX folks were on, and CFront tooling was symbiotic with UNIX.
I have a file of thousands of string manipulation tests that Jest just crashes on after 3 minutes while Bun runs in in milliseconds.
We are currently looking at vite and vitest to run 1600 jest tests.
ElysiaJS is a good library when you do need a bit more with the routing + middleware. It has great benchmarks as well.
Since I run "npm i" many times per day, that in itself is a big timesaver, not just for local dev but also in CI pipelines.
https://pnpm.io/
(I'm a deno core dev)
And UX is pretty great: integrated fetch, simplified fs api, integrated test runner (I miss good old TAP style assertions though), ESM/CJS modules just work, some async sugar.
I think if they offer me a paid *worker solution, with sqlite, that's something I'm willing to pay for.
I recently wrote a Node/Bun/Deno app that parses a 5k line text file into JSON.
The JavaScript on any runtime takes 30-45 seconds.
The Python implementation is sub 1 second.
I would not have been able to finish the tool so quickly if I were stuck relying on JS.
I still love Typescript but I'm not as blind about it now.