For example, in Python you could easily do this:

  message = '; cat /etc/passwd'

  # Whoops, shell injection vulnerability!
  subprocess.run(f'echo Message: {message}', shell=True)

  # Correct (assuming sh-compatible shell).
  subprocess.run(f'echo Message: {shlex.quote(message)}', shell=True)

  # Correct (without using shell).
  subprocess.run(['/bin/echo', 'Message:', message])

  let message = '; cat /etc/passwd';

  // Works correctly.
  await $`echo Message: ${message}`.text();

  // Fails safely by throwing error about incorrect usage.
  await $('echo Message: ' + message).text();

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]. 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.).

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] https://openjdk.org/jeps/459

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.

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.

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.

My intuition is that there are many more consumers of node-like environments today than any runtimes 15 years ago.

Note that Bun v1.1 is still compiling at the time of writing (probably for another 20 minutes)

(I'm not here to throw shade at using Discord for OSS "communities" - I do as well - And am concerned about the path forward. Just want to clarify the question's intent.)

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

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.

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.

We’ve been so busy with adding Windows support that it’s been hard to prioritize much else

The big ones for me are continual prisma issues. Mainly due to poor decisions on their side it seems…

Vite crashing. Because I’m using remix.

And then the worst one I don’t see a way around: sentry profiling which requires v8.

I can’t wait for the day everything can be on bun. Everything else sucks and is so slow or requires really bad configuration to make it work.

Can’t believe node itself and TS are so terrible with module compatibility. Bun solves all of this and is 20000x faster when I can use it!

Now you have to compile stuff.

In my case I’ve had apps use certain ts config options, and then another library has a start script which is incompatible.

So you’re stuck needing a different TS config for both things. These annoyances are solved with bun

I've been hesitant to move to TypeScript because I'm unsure how well the debugger works in practice.

My current platform is Node.js + WebStorm IDE as a debugger. I can debug the JavaScript and I can modify it while stopping at a breakpoint or debugger-statement. It is a huge time-saver that I don't have to see something wrong with my code while in the debugger and then find the original source-file to modify and recompile and then restart.

Just curious, do Deno and Bun support edit-while-debug, out of the box? Or do I need to install some dependencies to make that work?

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.

Running tsc with noEmit is pretty much the standard in the frontend as well, as the TS is bundled by esbuild/rollup directly.

    $ time bun hello.ts 
    real  0m0.015s
    user  0m0.008s
    sys   0m0.008s

    $ time ts-node hello.ts 
    real  0m0.727s
    user  0m1.534s
    sys   0m0.077s

TypeScript is entirely metadata, so it just doesn't make sense to need to compile it.

JS is the TS's bytecode but it has been designed to be a language to be developed in, which causes impedance mismatches as tools and people get confused about the usage context.

The people who designed those things ultimately threw in the towel and said that if you want that kind of security, use containers or VMs.

I can see why they chose that route. It's a huge maintenance burden. I can't imagine Google throwing in the towel when it comes to securing their browser's JS engine though.

#!/usr/bin/env -S deno run --allow-net

Then one can just run ./test.ts if the script has +x permission.

Also project such as https://cliffy.io has made writing cli way more enjoyable than node.

It is a good idea to beware of the VC. So it is good idea to support project such as Hono (projects conform to modern web standard, and is runtime agnostic for JS).

I do this all the time. I used to use `npx tsx` in my hashbang line to run TS scripts with Node, but I've started using Deno more because of the permissions. Another great package for shell scripting with Deno is Dax, which is like the Deno version of Bun shell: https://github.com/dsherret/dax

> Also project such as https://cliffy.io has made writing cli way more enjoyable than node.

This looks cool. I've always used the npm package Inquirer (which also works with Deno), but I'll have to compare Cliffy to that and see how it stacks up in comparison.

> Hono (projects conform to modern web standard, and is runtime agnostic for JS)

Hono is awesome. It's fast, very well typed, runs on all JS runtimes, and has zero dependencies.

With secure isolation being a requirement for web browsers, and with the backing of multiple big companies, it seems like there should be enough momentum to make it work properly. Or maybe the browsers rely entirely on process isolation between different origins and won't care about the security of isolating individual modules?

Wasm shared memory semantics are very similar to process isolation on OSes, so presumably the same techniques can be used there (and if those techniques are faulty, then so are containers and VMs).

    import foo from 'foo' with {permissions: ['fs', 'net']}

The best you can do currently is run your dependencies in a Worker, and enforce permissions programmatically for the worker [1]:

For example:

  new Worker(import.meta.resolve('./worker.js'), {
    type: 'module',
    deno: {
      permissions: {
        net: ['news.ycombinator.com'],
        read: [new URL('./sqlite.db', import.meta.url)],
        write: false,
      },
    },
  })

[1] https://docs.deno.com/runtime/manual/runtime/workers#specify...

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.

Will check once I get to my computer

Edit: was not fixed. We made other changes to fs.readSync to improve Node compatibility, but missed this. It will get fixed though

[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.

This can become a big time sink on bigger teams. That time could be saved by just not allowing it until a full team initiative is agreed on.

When you have a lot of projects to support, it's rare for the benefits to outweight the costs

For what it's worth, I'll say that I can understand such top down governance: you'd have an easier time around moving across projects that you work on within the org, there'd be less risk of a low bus factor, BOM and documentation/onboarding might become easier.

Same as how there are Java or .NET shops out there, that might also focus on a particular runtime (e.g. JDK vendor) or tooling (an IDE, or a particular CI solution, even if it's Jenkins).

On the other hand, if the whole org would use MySQL but you'd have a use case for which PostgreSQL might be a better fit, or vice versa, it'd kind of suck to be in that particular situation.

It's probably the same story for Node/Deno/Bun, React/Vue/Angular or anything else out there.

No reason why that mandated option couldn't eventually be Bun, though, for better or worse.

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.

But you also have to remember this is JS we’re talking about… stuff changes every 10 minutes.

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.

AFAIK, Pnpm monorepos do not follow standard npm. Bun does follow standard npm monorepos.

Pnpm's feature to override dependency versions is nice for legacy projects with many 3rd party dependencies. Not sure if Bun has the same feature. I mostly use it on greenfield projects with dependencies that I control.

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'm a deno core dev)

Don't take it as a criticism, I totally understand that you need to iterate on API and nobody promised me that it'd be stable till the end of time, but still work is work.

If you recall that exact issue, definitely feel free to file an issue.

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.

Came for the ts interoperability, stayed for the performance.

Also seems like the most sensible project in the space - I tried Deno and it was... rough. Bun on the otherhand was easy to intergrate and a very pleasant experience.

Have yet to run Bun in production tho.

Nowadays if you start a new Javascript project you need to setup, vite/esbuild/webpack, eslint/oxlint/biome, prettier, typescript, etc, that is a ton of dependencies that YOU need to maintain for years, and if it is part of the tool you are using, then you don't, ideally there shouldn't be a breaking change, let's see how bun manages that when the time comes.

I am waiting for bun or a tool that has everything I need to bundle my frontend app, I'm very tired of fiddling with all the dependencies and try to make to work every dependency together, I have a legacy project that I work on, I would have migrated a long time ago to another tool, but there is none that would fix the current issue and it's managing the project build, test, formatter, lint dependencies, after using Rust I feel super frustrated with the Javascript ecosystem state.

Also you asked why? I want to work on the project, there is already a lot of work to maintain the dependencies up to date, the tooling should not be part of that work.

When things are not that coupled, independent components you bring together, you can update the webserver, and/or some components, and keep the old version of the test library for now, until you decide it's time to upgrade.

I'm currently fighting PHP + Laravel. I want to upgrade PHP but I can't because the version of Laravel I'm using depends on an older version of PHP. So I have to upgrade them both in lockstep anyway.

JS doesn’t have anything like that, which is why projects like Deno, Bun, Biome, etc are interesting. These projects explore how JS can also get a great out of the box experience without requiring the complex setup and maintenance steps that so many existing tools require.

Besides, professionally, you normally don’t make the choice in a vacuum. Linters, package managers, testing, bundling/building, type safety, and even formatting are all very useful in big projects with lots of people. So you often don’t get to say “ah we just won’t have unit tests because jest doesn’t care enough about backwards compatibility.”

Regarding runtime libraries, it’s similar to the battery-included approach of go or python, you get what you need to get started out of the box and only reach for dependencies when you want to go further. Testing library, an http server, a websocket server that’s perfectly reasonable to have as core library of a runtime developed to run web servers.

I however find Bun more useful as a Swiss army knives, to use with nodejs, to reduce the number of development dependencies.

Does this mean the release was made with failing tests, or am I misunderstanding?

Skipping tests from a Linux suite that doesn't make sense to run on Windows is very common. Skipping tests that should pass on a platform but doesn't just in order to cut a release isn't as common.

What does that even mean? Bun is run by a fictional French character capable of interplanetary travel? Or are you calling them a spoiled brat with money? Why does that affect code organisation? Or is it code quality?

If you’re going to criticise the project and the people who run it, some clarity of communication and specifics on the issues would be appreciated so others can evaluate your claims. Otherwise it’s just empty insults which do not advance the discussion.

And I’m glad they spent time on Windows support, that’s something neglected in the web development world

> The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity.

Bun is still pretty young and experimental, and not really production ready, though it’s getting there fast. If it grows enough to force node to improve, or if it takes over node, that would be a success based on their own goal

https://bun.sh/docs/api/ffi

So has Deno, but Bun's feel more evolved as it comes bundled with tools and sufficient examples for working with pointers. The only thing Bun is missing right now is the Deno equivalent of non-blocking FFI calls, ie `await mylib.myFunc()`.

Another one on my wishlist for Bun: embedded Bun. A library distribution would be nice, so that we can call into Bun as ie "libbun.so" from other languages. It would be more resourceful than just embedding WebKit/SpiderMonkey/v8 as these lack any real capabilities besides running vanilla JS.

Edit:

The docs mention:

> Because Bun can directly execute TypeScript, you may not need to transpile your TypeScript to run in production. Bun internally transpiles every file it executes (both .js and .ts), so the additional overhead of directly executing your .ts/.tsx source files is negligible.

https://bun.sh/docs/runtime/typescript

The idea I'm getting from this is that both JS and TS are transpiled to something else. Are types preserved in this bytecode, AST, or whatever it is?

At this point, IMO, it should just be implemented within V8. Would make things much simpler for everyone.

Why incur the type-declaration overhead if they are not used after all?

Plus, for local dev, iteration and watch/rebuild is more important than failing with invalid types on every change. Sometimes it’s helpful to circle back to fix/update types after you’ve tried a couple approaches. (TS can still be finicky at times!) On top of that, your IDE should report type errors as you work anyways.

I would still prefer though that Bun did it for me, in a separate process perhaps, so I wouldn't need to configure a separate CI job, or manually enter the tsc-command. I read that Bun has its own test-runner too so why not its own type-checker too.

On Node.js I just edit the source-code then re-start the debugger on it, and edit it while in the debugger then rinse and repeat.

I use runtime assertions to catch errors in argument-types etc. as needed.

Bun is our one-stop-shop for Typescript.

Thank you!

Is `remix run dev` fully working now with the additional node API support?

Can you tell I don't use bun yet? Because none of my questions are about the release. But I tried it out a few weeks ago on my NextJS project and it didn't work, but will try bun 1.1.

One thing I miss in Node.js is ability to run a HTTPS -server in a simple way without having to muddle with generating & installing a correct type of certificate. I understand there can be a "self-signed certificate" but there doesn't seem to be any npm-module I could install to take care of that.

Since Bun is a "server-side" JavaScript platform it would be great if it could support https out of the box too.

Bun shell keeps the more esoteric syntax of Unix-like shells but also requires a dependency (Bun itself). If you already have Bun installed why wouldn't you just write a JS script?

The velocity of writing filesystem and file manipulation files in shell is many times greater than in javascript. Bun shell lets you leverage the power of shell for that stuff while being able to leverage your javascript code at the same time, with fairly minor downsides in exchange.

On the dependency side it'd be slick if you could bun --compile these like normal bun apps.

https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...

Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.

Then I look into the source for it:

https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...

For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:

https://github.com/ziglang/zig/issues/1840

I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :

    #include 
    #define MY_MSG "Hello World!\n"
    int main() {
        WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), MY_MSG, sizeof(MY_MSG), nullptr, nullptr);
        return 0;
    }

I'm not sure it's possible to not have kernel32 loaded into your process anyways. Even if you create an EXE that imports 0 DLLs, kernel32 gets loaded into the process by NTDLL. The callstack from main:

    ConsoleApplication1.exe!main()
    kernel32.dll!BaseThreadInitThunk()
    ntdll.dll!RtlUserThreadStart()

https://github.com/ziglang/zig/issues/11894

So often I read the release notes and think “what a great idea, why wasn’t this already a thing” e.g. syntax highlighted errors

Such approach makes those projects looks like unicorns, not production stuff - even they are.