[Feature Request]: Bun runtime instead of Node.js

[aleksey-hoffman]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Hey guys, consider switching JS runtime from Node.js to Bun
https://bun.sh/
https://www.youtube.com/watch?v=FMhScnY0dME

Proposed Solution

Alternatives Considered

Additional Information

No response

[RaisinTen]

Could you explain why?

[aleksey-hoffman]

@RaisinTen

• It's faster
• It has backward compatibility with Node.js

[RaisinTen]

Does it support Windows?

It's faster

A quick read tells me that most of its performance comes from the features of the language it is implemented in, i.e., Zig. I'm not sure how much of this performance gain would be visible in Desktop apps made using Electron because the biggest part of Electron is Chromium and that is mostly written in C++.

[RaisinTen]

Bun uses the JavaScriptCore engine instead of V8, so if the runtime is changed to Bun, how would that interop with the rest of Chromium? To my understanding, Chromium is too tightly coupled with V8 for it to be be easily replaced with something like JavaScriptCore.

[VerteDinde]

Thanks for adding this feature request! Electron has no plans to move away from Node at this point, both for the reasons that @RaisinTen mentioned above, and the fact that the Bun runtime (while exciting!) is very new and still developing. While we're excited to see how Bun develops and wish the team well, Electron will be staying with Node for the near future 🙂

[michaelslec]

😢 I think y'all made the right decision, but I'm excited to see more mature technologies that increase performance (hopefully soon)!

[jpillora]

@VerteDinde since bun just hit 1.0 https://youtu.be/BsnCpESUEqM?si=SyElPGQijMUNBxn1 have you guys considered this again?

[ninjadev64]

@jpillora I feel like the issues they mentioned are still very relevant, mainly this one:

Bun uses the JavaScriptCore engine instead of V8, so if the runtime is changed to Bun, how would that interop with the rest of Chromium? To my understanding, Chromium is too tightly coupled with V8 for it to be be easily replaced with something like JavaScriptCore.

[herrbasan]

Given how the Electron team works, this is rather unlikely. I think it would be better to ask the Bun team to replicate what Electron does. With their current momentum and speed, this will happen long before the Electron team decided on a strategy how to structure a guide for a future proposal.

[MarshallOfSound]

@herrbasan An issue tracker is not the place to talk down on the individual maintainers that support this project, especially not when on their own issue tracker, a friendly reminder that all interactions on this tracker are governed by electrons Code of Conduct. But here's a list of reasons why not only will Electron not be switching to Bun any time soon, but also an equivalent technology backed by Bun would be hard (not impossible) to build.

• Bun is not API compatible with Node.JS, some existing applications would simply not function, this is unacceptable
• Performance claims while valid in some cases are overblown, incorrectly repeated and in some cases the performance slider falls the other way. E.g. nodes URL parser is 2x faster than buns, for an application like electron that's pretty useful
• Electron utilizes the same JS engine as Chromium does (the underlying rendering engine). This gives us access to some useful things like performant cross-process JS object serialization via the V8 serializer. This would not be possible if the browser engine and the main process runtime were different and that's before you get to actual native interop of the technologies that power Electron, e.g. gin consuming V8 APIs directly.
• Same as the point above, no way Chromium switches to JSCore so you'll end up shipping two separate JS runtimes, each with their own quirks that will make them subtly different and make the bundle twice as big which people won't be super impressed with
• Bun doesn't have full support for napi, let alone support for nan (as nan is backed by raw V8 APIs) so a lot of native modules don't currently work out of the box
• Bun doesn't currently have a way to be built as shared library in the same way we build node
• Node (having existed longer) has publicly documented and battle tested processes for scenarios that bun has never (yet) had to face, security issues, coordinated disclosure, emergency releases.
• This list could keep going 🤷

I want to be clear that I have nothing against Bun as a project, in fact I think it's pretty cool that folks are challenging the status quo because it results in innovation all throughout the ecosystem. The real point tbh is that this is exactly what happened with deno, "oh look a cool new runtime, everyone should switch to it, electron plz switch to deno". And now many years later, has deno taken a piece of node's kingdom, sure, is node still the overwhelming majority, yes.

As a maintainer, I'm not going to subject 10's of thousands of developers (and by side effect hundreds of millions of users) to a brand new hyped up piece of technology just because twitter thinks it's cool right now. We use what is right for the project, not what seems cool at the time. If in the future the landscape changes in some way, we will adapt, we always do (even if the technical challenges can take a while to overcome).

[herrbasan]

I agree with all of it, that's why I think there needs to be something new.

[jpillora]

Thanks for the detailed response @MarshallOfSound, much appreciated

[ArjixWasTaken]

@jpillora

since bun just hit 1.0 https://youtu.be/BsnCpESUEqM?si=SyElPGQijMUNBxn1 have you guys considered this again?

Considering the huge amount of open bug reports, I wouldn't consider bun anywhere close to "production ready" as they claim it to be.

[vjpr]

@MarshallOfSound

Electron utilizes the same JS engine as Chromium does (the underlying rendering engine). This gives us access to some useful things like performant cross-process JS object serialization via the V8 serializer.

Seeing as the sandbox is enabled for renderer processes by default since Electron 20, is there actually any benefit in this mode? Is there any shared memory?

[beorn]

As Marshall explains, Electron is deeply wedded to chromium/v8/node (that was kind-of the whole point of the project) from the start and now to preserve compatibility, so while a Bun runtime might be cool (if nothing else, it's a different set of tradeoffs), it probably belongs in a different project. I just wanted to direct interested people to some other places to go and discuss that potential:
oven-sh/bun#790
gluon-framework/gluon#10
tauri-apps/tauri#5837

[MarcWeber]

Well maybe somebody finds a benchmark which matters which shows there is big benefit. Something like 'running webpack on JS only' cause it doesn't depend on HTTP ? Or thinking about vscode running syntax analysis on 5 files so that startup time actually matters.

[joaopauloalbq]

So basically Microsoft has to improve Node.js and V8 instead of using Bun/Deno. Copying the algorithms and heuristics used by Bun/Deno that make them faster.

Taking a quick look at the runtime repositories I noticed that Bun is primarily written, 87.4%, in a high-performance languages (Zig, CPP and C) and only 11.1% in less performant languages (Javacript and Typescript).

Deno is 47.4% written in high-performance language (Rust) and 52.6% written in less performant languages (Javacript and Typescript).

On the other hand, Node has only 24.4% of codes written in high-performance languages (CPP and C) and the majority, 73.9%, is written in less performant languages (Javascript and Python?!)...

Shouldn't Node.js be written in something like 90% C/CPP and 10% Typescript?

[tonny008]

create a node module to mimic someof its API, implemented with C/CPP