Please support the bun.js runtime请支持使用bun.js运行时

[jiafuzhang]

It is hoped that the author can support the use of bun.js to run playwright, as the execution speed and resource consumption of bun.js are both superior to those of node.js.
希望作者能支持使用bun.js运行playwright，因为bun.js的执行速度和资源占用都要优于node.js

[jiafuzhang]

Thank you.谢谢。

[padamson]

Thanks for raising this!

A bit of context on the architecture: playwright-rust is a native Rust client that talks JSON-RPC over stdio to Microsoft's Playwright driver, which Microsoft ships and tests against Node.js. The Node process is an internal implementation detail — it shuttles messages between Rust and the browser — so your own dev runtime (Bun, Deno, etc.) is orthogonal to using this crate. You can use Bun for everything else in your stack today and playwright-rust works fine.

That said, I'd like to understand the use case better before deciding whether to invest here. A few questions:

1. What's your workload — E2E testing, scraping/automation, agent tooling, something else?
2. What specifically would Bun-as-driver-runtime unblock for you that the current setup doesn't? (e.g. container size, per-worker memory at high concurrency, single-runtime constraint, etc.)
3. Do you have numbers showing the Node driver — not the browser itself — is a bottleneck in your workload?

The reason I'm asking: supporting Bun as the driver runtime means tracking Microsoft's driver against Bun's evolving Node compatibility and owning a second test matrix, which is a real maintenance commitment for a pre-1.0 project. I'm open to it if there's a concrete need, but I want to make sure it solves a real problem rather than a perceived one.

Leaving this open for now — if others have the same need, please chime in with your use case.

[jiafuzhang]

Thank you for your response, it's very delightful.
感谢作者的回答，非常开心。

Here is the answer to your question.
下面回答你的问题。

1. What's your workload — E2E testing, scraping/automation, agent tooling, something else?
   Our job involves web scraping/automation. It's somewhat similar to RPA but not exactly the same. So we are currently starting to develop it ourselves.
   我们的工作是爬虫/自动化，有点类似RPA但是又不太一样，所以现在开始着手自己开发。
2. What specifically would Bun-as-driver-runtime unblock for you that the current setup doesn't? (e.g. container size, per-worker memory at high concurrency, single-runtime constraint, etc.)
   We use Axum to build the service to handle the tasks that need to be executed. Initially, the plan was to support a maximum of 1000 concurrent connections. At this point, Bun.js, as the runtime, would have a significant improvement in CPU and memory usage, as well as response time compared to Node.js.(We are planning to purchase a server to be used within the company.)
   我们用axum搭建服务处理需要执行的任务，期初计划最大支持1000并发，这个时候bun.js作为运行时cpu、内存使用量和响应时间相比node.js会有较大的提升。（我们准备采购一台服务器放在公司内部使用）
3. Do you have numbers showing the Node driver — not the browser itself — is a bottleneck in your workload?> > The reason I'm asking: supporting Bun as the driver runtime means tracking Microsoft's driver against Bun's evolving Node compatibility and owning a second test matrix, which is a real maintenance commitment for a pre-1.0 project. I'm open to it if there's a concrete need, but I want to make sure it solves a real problem rather than a perceived one.
   Currently, we are in the initial stage of design and development, and we do not have actual production environment operation data yet. It was during the previous technology selection process that we came across the performance analysis articles of bun.js and node.js. We searched for relevant information on Google and inquired about the possibility of using bun.js to run playwright, as well as the resources that could be saved during high concurrency. The results showed certain advantages. Of course, for the project author, it might increase additional workload. Therefore, please continue with your original development plan and consider the feasibility after the project 1.0 is stable.
   目前我们在设计开发的初级阶段，还没有实际的生产环境运行数据。是之前技术选型时看到bun.js和node.js的性能分析文章，在google查询相关资料和询问ai使用bun.js运行playwright的可能性，以及在高并发时可以节约的资源，得到的结果有一定的优势。当然，但对于项目作者来说可能会增加额外的工作量。所以，请作者继续你的原定开发计划，等项目1.0稳定后再考虑可行性。

Summary: For projects with certain requirements for response time and concurrency, using Rust for business development would be a good choice. If a configuration or parameter option for choosing between Bun.js or Node.js can be added in version 1.0 or 2.0 after the project is stable, it would be a very useful feature.
Thank you again, and wish you good life and work!
总结：使用rust进行业务开发肯定是对响应时间和并发有一定需求的项目，如果能在项目稳定后1.0或者2.0增加一个选择bun.js或者node.js的配置或者参数选项，将会是一个很好的功能。
再次感谢，以及祝生活工作都好！

[padamson]

Thanks for the additional information. A clarification on how playwright-rs runs the driver, and what's already possible:

playwright-rs does not run Playwright itself. It spawns the official Playwright driver as <node> cli.js run-driver. The runtime (Node.js) and the driver code both come from upstream Playwright; the bindings only launch them.

You can already point the bindings at a different runtime without any code change: set PLAYWRIGHT_NODE_EXE to your bun binary and PLAYWRIGHT_CLI_JS to the bundled package/cli.js, and playwright-rs will spawn bun cli.js run-driver. Whether it actually works depends on bun's Node.js compatibility and Playwright's own assumptions about the runtime, which is upstream and not something the Rust bindings can change.

So please feel free to try the env override above and report back. First-class bun support would need to come from Playwright itself, so I will leave this open to track interest and any upstream movement. If the experiments surface anything I can do here to support bun, I'll consider it.

[jiafuzhang]

Thanks for the additional information. A clarification on how playwright-rs runs the driver, and what's already possible:

playwright-rs does not run Playwright itself. It spawns the official Playwright driver as . The runtime (Node.js) and the driver code both come from upstream Playwright; the bindings only launch them.<node> cli.js run-driver

You can already point the bindings at a different runtime without any code change: set to your binary and to the bundled , and playwright-rs will spawn . Whether it actually works depends on bun's Node.js compatibility and Playwright's own assumptions about the runtime, which is upstream and not something the Rust bindings can change.PLAYWRIGHT_NODE_EXE``bun``PLAYWRIGHT_CLI_JS``package/cli.js``bun cli.js run-driver

So please feel free to try the env override above and report back. First-class bun support would need to come from Playwright itself, so I will leave this open to track interest and any upstream movement. If the experiments surface anything I can do here to support , I'll consider it.bun

Thank you. I will provide feedback after conducting the test later.