You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found the earlier proposal in [#2376](#2376) and understand the response there: Bun was not planning on replacing JavaScriptCore. I'm not trying to reopen that specific proposal to replace JSC's JIT with Hop.js/AOT, or to argue that another engine would necessarily be better.
Instead, I'd like to ask a broader question: What would justify re-evaluating Bun's long-term JavaScript engine choice, and would it be useful to make those evaluation criteria explicit?
Why revisit the question now?
Bun's Rust rewrite was a major milestone, but I understand that it primarily targeted the safety and maintainability of Bun's own code. It does not automatically make replacing JavaScriptCore easier, and the Rust rewrite announcement explicitly says that Bun will continue using C/C++ libraries such as JSC.
At the same time, Bun 1.4 demonstrates substantial ongoing investment in JavaScriptCore, including upstream WebKit updates and engine-level performance improvements. Those are strong reasons to continue with JSC, and any alternative would need to justify its additional cost.
I think it would still be useful to understand the long-term trade-offs of this dependency, especially as Bun continues to expand its compatibility and all-in-one runtime capabilities.
A few recent examples illustrate the areas worth evaluating:
I realize these crash reports do not establish that upstream JavaScriptCore is the root cause. The problems may lie in Bun's integration with JSC, in the embedding boundary, or elsewhere. Replacing the engine would not automatically fix them. I mention them as examples of the debugging and maintenance challenges that should be considered, not as proof that JSC should be abandoned.
What would be useful to evaluate?
Rather than proposing an immediate migration, would it be worthwhile to conduct a scoped feasibility study comparing the following approaches?
Continue investing in JSC. Identify which limitations can realistically be addressed through upstream contributions, Bun-specific changes, and better integration.
Clarify the engine boundary. Map the parts of Bun that depend on JSC-specific behavior and understand the long-term cost of maintaining that integration. This does not necessarily mean building an engine-agnostic abstraction.
Evaluate alternatives as research candidates. Consider other engines, including Rust-based projects such as [Boa](https://github.com/boa-dev/boa), without assuming that they are ready to replace JSC or would provide better performance.
A meaningful comparison would need to go beyond synthetic benchmarks. Cold-start time, steady-state throughput, peak RSS, garbage-collection behavior, ECMAScript conformance, Node.js compatibility, native addons and FFI, platform support, and long-term maintenance costs would all matter.
I'm not suggesting that Bun should immediately replace JavaScriptCore, build its own engine, or introduce a runtime-selectable engine abstraction. A conclusion that JSC remains the best choice would be perfectly reasonable if supported by those trade-offs.
My main question is whether Bun considers its current engine choice a settled long-term commitment, or whether there are conditions under which the team would be open to evaluating alternatives again.
Would a feasibility study or an explicit set of criteria for revisiting the engine choice be useful, or are there constraints that make this a non-starter for the foreseeable future?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Re-evaluating Bun's long-term JavaScript engine strategy
I found the earlier proposal in [#2376](#2376) and understand the response there: Bun was not planning on replacing JavaScriptCore. I'm not trying to reopen that specific proposal to replace JSC's JIT with Hop.js/AOT, or to argue that another engine would necessarily be better.
Instead, I'd like to ask a broader question: What would justify re-evaluating Bun's long-term JavaScript engine choice, and would it be useful to make those evaluation criteria explicit?
Why revisit the question now?
Bun's Rust rewrite was a major milestone, but I understand that it primarily targeted the safety and maintainability of Bun's own code. It does not automatically make replacing JavaScriptCore easier, and the Rust rewrite announcement explicitly says that Bun will continue using C/C++ libraries such as JSC.
At the same time, Bun 1.4 demonstrates substantial ongoing investment in JavaScriptCore, including upstream WebKit updates and engine-level performance improvements. Those are strong reasons to continue with JSC, and any alternative would need to justify its additional cost.
I think it would still be useful to understand the long-term trade-offs of this dependency, especially as Bun continues to expand its compatibility and all-in-one runtime capabilities.
A few recent examples illustrate the areas worth evaluating:
I realize these crash reports do not establish that upstream JavaScriptCore is the root cause. The problems may lie in Bun's integration with JSC, in the embedding boundary, or elsewhere. Replacing the engine would not automatically fix them. I mention them as examples of the debugging and maintenance challenges that should be considered, not as proof that JSC should be abandoned.
What would be useful to evaluate?
Rather than proposing an immediate migration, would it be worthwhile to conduct a scoped feasibility study comparing the following approaches?
A meaningful comparison would need to go beyond synthetic benchmarks. Cold-start time, steady-state throughput, peak RSS, garbage-collection behavior, ECMAScript conformance, Node.js compatibility, native addons and FFI, platform support, and long-term maintenance costs would all matter.
I'm not suggesting that Bun should immediately replace JavaScriptCore, build its own engine, or introduce a runtime-selectable engine abstraction. A conclusion that JSC remains the best choice would be perfectly reasonable if supported by those trade-offs.
My main question is whether Bun considers its current engine choice a settled long-term commitment, or whether there are conditions under which the team would be open to evaluating alternatives again.
Would a feasibility study or an explicit set of criteria for revisiting the engine choice be useful, or are there constraints that make this a non-starter for the foreseeable future?
All reactions