Looks very promising, will be building my next project with it. Full TS stack is where I'm most productive. I'm glad we now have a more performant and lean alternative to Electron while not needing to deal with Rust and long compilation steps.
One of the main problems I see with tauri is that system web views just aren’t a great solution for a ui framework. Partly because Linux doesn’t have an official webview implementation, partly because the web views across OS versions have differences (eg. Tauri on Linux had a benchmark saying the boot time was 20+ seconds because of the webview, and win 7 and I think even early versions of win 10 do not use the edge webview).
This is a lot of tradeoffs for saving 100 megs.
I understand that we should be good stewards of our customers’ hardware and not waste things unnecessarily, but also have to balance that with shipping something and not worrying about all the edge cases. Most people in developed countries have Internet connections of 100+ mbps, which means the app will still download in <10 seconds.
Does electrobun support using an embedded chromium for the renderer? I went to the project readme and it was really unclear if that’s a currently-supported option and if so, how to use it.
> Instead of distributing Chromium, By default Electrobun uses your system's native WebView (WebKit on macOS, Edge WebView2 on Windows, WebKitGTK on Linux).
Why don't any of the major distros have a webview? Seems an obvious move if you want apps and alongside user experience, apps are the biggest barrier to linux adoption
There may not be an official webview, but all (?) major distributions have libwebkit2gtk, which is used by Wails (Go) and Tauri (rust). So it's a de facto standard if not official.
My hope is this still acts like a library that multiple Tauri instances share. That would still have the upside of Tauri's shared library architecture (boo statically compiled programs, what a waste of precious ram!) while still letting us have a viable runtime. First app load might not be lightning fast but second app load is hopefully faster!! The OS webviews range from mediocre to absolute garbage; this to me would be a great improvement, that makes me happy!
A Tauri app built on CEF (Chromium) is very similar to Electron (which also uses Chromium). The key difference is that Tauri uses Rust for the application’s business logic, whereas Electron uses JavaScript.
In this case I don't know why I should use Tauri instead of Electron.
The article mentioned notarizing and stapling as problems with prior frameworks. What's the story here? If you don't use xcode as your ide (and I don't see that this project management is happening inside xcode), Apple makes that stuff really hard. And windows is easier but still hard to automate in CI. If this framework offers better solutions I'm all ears.
most use cases are supported out of the box. you just have to set a few env vars
and then build with "notarize: true" in your config... and it pretty much just works
i've signed and notarized things with electrobun and it's perfectly fine. it also gives you escape hatches in case you're doing something more complicated
EDIT: in case i can help you with anything there, feel free to DM me! or join the electrobun discord. i'm very active there. (im not affiliated with EB. just know the struggle of apples notarization system)
I do a lot of web development, and even if we set the great tooling aside for a moment, Bun is still a major improvement (a real leap, I’d say) when it comes to performance.
Are many games built with Electron ...? I know there are a few HTML5 games, crosscode was the first one I recall seeing that really pushed it. Aren't most small games Unity or Godot?
Title should maybe specify that this is a blogpost from the author reflecting over the project. There’s better link to showcase the actual project
https://blackboard.sh/electrobun/docs
afaik its around 14MB but the large majority of that is the Bun runtime itself. at some point it will likely be possible to pick and choose parts of the runtime to include in the binary. thus the bundle size could get a lot smaller in the future
that said electrobun's author has published a bsdiff implementation in zig, and thats used for electrobun's updater. that means you download deltas, not the entire application bundle, every time you push an update to your users. and then it gets patched in-place.
this makes updates tiny, to the tune of a couple kB
@OP I know it's "just" a webview at the end of the day but I still think the Electrobun website could use a screenshot or two. (Or maybe e.g. a short video of an app comparing the startup times of Electrobun, Tauri, Electron etc.)
> short video of an app comparing the startup times of Electrobun, Tauri, Electron etc.
Looks like I hit the submit button a bit too fast. I meant to say: "a short video comparing the startup times of apps using Electrobun, Tauri, Electron etc."
/* Looked at the product for which Electrobun was built, co(lab). «Focus on building instead of managing tools. Keep your code, browser, terminal, notes, and git workflow in one unified interface.» Well, a great idea! This is what Emacs mostly gives me. */
Hey HN, Electrobun creator here. Thanks for posting this.
We just hit v1 - stable which means I've locked down the architecture. If you run into any bugs or need specific apis that you miss from Electron or Tauri please open Github issues and I'll prioritize them. I shipped 50,000 lines of code changes stabilizing and polishing electrobun for v1 over the last month.
Here's a video demo of Colab (also open source) (a hybrid web browser + code editor + PTY terminal) that is built with Electrobun https://www.youtube.com/watch?v=WWTCqGmE86w
Electrobun uses the system webview by default, but a lot of the hello worlds feature the bundleCEF option. Because Electrobun is architected to be webview agnostic when servo and ladybird are ready they should be drop-in alternatives.
Electrobun apps also auto generate a zstd self-extraction wrapper and patch files with every release, so your initial download will be much smaller than if you'd used zip and your updates will be as small as 14KB so you can ship as often as you like without you or your users paying the bandwidth tax.
I'm wondering about security for this sort of thing. I guess it's like node.js in the sense that while you could load JavaScript code downloaded from the Internet at runtime, you probably shouldn't? Any additional gotchas due to the web view?
The business logic of your app is running in the Main process using Bun runtime. The website you load or the app's frontend is running in a separate sandboxed Renderer process. When I run Electrobun app on macOS, I see that it launches the following processes with the following RAM usage:
- views://mainview (33.7MB) <- your frontend is running here
- react-tailwind-vite-dev Networking (5.4MB)
- react-tail wind-vite-dev Graphics and Media (16.7MB)
no real gotchas. JS is slightly dangerous because of JS, yes. You should never fetch things at runtime to execute if possible - instead, you install absolutely everything you need with npm or bun, and it gets inlined at build time
electrobun ships with an RPC (i think it also does some encryption?) so as long as you use that to communicate between your webview and bun "host process" you should be safe.
I'm going to production with a new Electron app at my job this week, i wish this had existed a year ago lol. Electron Builder does a pretty good job making the updates and signatures not TOO painful but it hasn't been painless by any stretch.
Looks cool, I'll try this for my next personal desktop project and see how it goes
If someone from Electrobun is reading this. Can Electrobun compile to android as well. I want to create a simple application which can take some index.html and pass an adblocker and create an app out of it since I think this idea is pretty cool.
I ended up having to use Ionic to create a html <-> Android app thing within github actions but Ionic doesn't support ad blocking abilities.
Moved from the molasses of VSCode to Rust-based Zed, no comparison. The second is snappy, responsive, uses much less memory (I can have 5 Zed open at the same time, no problems), not looking back.
was looking for something just like this. Really helpful
Looks very promising, will be building my next project with it. Full TS stack is where I'm most productive. I'm glad we now have a more performant and lean alternative to Electron while not needing to deal with Rust and long compilation steps.
One of the main problems I see with tauri is that system web views just aren’t a great solution for a ui framework. Partly because Linux doesn’t have an official webview implementation, partly because the web views across OS versions have differences (eg. Tauri on Linux had a benchmark saying the boot time was 20+ seconds because of the webview, and win 7 and I think even early versions of win 10 do not use the edge webview).
This is a lot of tradeoffs for saving 100 megs.
I understand that we should be good stewards of our customers’ hardware and not waste things unnecessarily, but also have to balance that with shipping something and not worrying about all the edge cases. Most people in developed countries have Internet connections of 100+ mbps, which means the app will still download in <10 seconds.
Does electrobun support using an embedded chromium for the renderer? I went to the project readme and it was really unclear if that’s a currently-supported option and if so, how to use it.
> Instead of distributing Chromium, By default Electrobun uses your system's native WebView (WebKit on macOS, Edge WebView2 on Windows, WebKitGTK on Linux).
still:
> Optional CEF: bundle CEF (Chromium) when cross-platform consistency matters most.
from: https://blackboard.sh/electrobun/docs/guides/what-is-electro...
On Windows I noticed for my Tauri app I had to use this https://v2.tauri.app/distribute/windows-installer/#embedded-... (https://github.com/kzahel/jstorrent/commit/10cc1c53#diff-f61...) even on a new windows 11 install for the webview to work, but my app seems to work fine otherwise on all platforms (I only tested Ubuntu desktop though, ha).
Electrobun sounds really cool, glad to see there's more work done to enable cool desktop apps without Electron.
“System's native webview as renderer, CEF Optional”
Taken from the product site (not this blog post) that was linked by another user. So you get to choose it would seem.
Why don't any of the major distros have a webview? Seems an obvious move if you want apps and alongside user experience, apps are the biggest barrier to linux adoption
There may not be an official webview, but all (?) major distributions have libwebkit2gtk, which is used by Wails (Go) and Tauri (rust). So it's a de facto standard if not official.
https://webkitgtk.org/
https://wails.io/docs/gettingstarted/installation/
https://v2.tauri.app/start/prerequisites/
There is a ton of work going into a Tauri based on CEF. https://github.com/tauri-apps/tauri/tree/feat/cef
My hope is this still acts like a library that multiple Tauri instances share. That would still have the upside of Tauri's shared library architecture (boo statically compiled programs, what a waste of precious ram!) while still letting us have a viable runtime. First app load might not be lightning fast but second app load is hopefully faster!! The OS webviews range from mediocre to absolute garbage; this to me would be a great improvement, that makes me happy!
A Tauri app built on CEF (Chromium) is very similar to Electron (which also uses Chromium). The key difference is that Tauri uses Rust for the application’s business logic, whereas Electron uses JavaScript.
In this case I don't know why I should use Tauri instead of Electron.
The article mentioned notarizing and stapling as problems with prior frameworks. What's the story here? If you don't use xcode as your ide (and I don't see that this project management is happening inside xcode), Apple makes that stuff really hard. And windows is easier but still hard to automate in CI. If this framework offers better solutions I'm all ears.
most use cases are supported out of the box. you just have to set a few env vars
and then build with "notarize: true" in your config... and it pretty much just works
i've signed and notarized things with electrobun and it's perfectly fine. it also gives you escape hatches in case you're doing something more complicated
EDIT: in case i can help you with anything there, feel free to DM me! or join the electrobun discord. i'm very active there. (im not affiliated with EB. just know the struggle of apples notarization system)
Thanks, that's great! Very generous.
I see a lot of game devs in discord experimenting with Electrobun to release desktop games.
I think it's going to eat a piece of the Electron pie for Steam indie games.
Most stay with bun after seeing how fast and seamless it is to run typescript games with instant auto reload:
bun --watch game.ts
I do a lot of web development, and even if we set the great tooling aside for a moment, Bun is still a major improvement (a real leap, I’d say) when it comes to performance.
Are many games built with Electron ...? I know there are a few HTML5 games, crosscode was the first one I recall seeing that really pushed it. Aren't most small games Unity or Godot?
CrossCode is a marvel in that they had to build their own runtime: https://news.ycombinator.com/item?id=41155807
I think the most famous Electron game is Vampire Suvivors, but it has since been ported to Unity.
What Discord server are you referring to? Would love to join.
Title should maybe specify that this is a blogpost from the author reflecting over the project. There’s better link to showcase the actual project https://blackboard.sh/electrobun/docs
Neat! Here's the project main page for those interested in more than the release announcement:
https://blackboard.sh/electrobun/docs/
It certainly looks clean enough, and I'm more familiar with zig than rust, so I might give it a shot.
How big does a hello world binary compile to with this?
afaik its around 14MB but the large majority of that is the Bun runtime itself. at some point it will likely be possible to pick and choose parts of the runtime to include in the binary. thus the bundle size could get a lot smaller in the future
that said electrobun's author has published a bsdiff implementation in zig, and thats used for electrobun's updater. that means you download deltas, not the entire application bundle, every time you push an update to your users. and then it gets patched in-place.
this makes updates tiny, to the tune of a couple kB
Just tried their hello world
* npx electrobun init
* [choose hello-world]
* bun install
* bun run build
This generates in linux a folder that takes about 60M [1] (mostly the "bun" executable)
[1] du says 60M, ls says 100M, maybe it is a sparse file ?
I guess since Electron apps are 500MB+, 14MB is considered "tiny".
A regular Electron app for macOS (DMG) is ~80MB. Electrobun's DMG is ~16MB.
And with Election that includes entire Chromium so no need to be fighting system webviews.
Can modern LLMs effectively be used on Electrobun codebases?
yes. the actual APIs are very simple. i'm using claude code a lot
@OP I know it's "just" a webview at the end of the day but I still think the Electrobun website could use a screenshot or two. (Or maybe e.g. a short video of an app comparing the startup times of Electrobun, Tauri, Electron etc.)
> short video of an app comparing the startup times of Electrobun, Tauri, Electron etc.
Looks like I hit the submit button a bit too fast. I meant to say: "a short video comparing the startup times of apps using Electrobun, Tauri, Electron etc."
(I can't edit my comment anymore unfortunately.)
This looks promising. And it's exciting to think it could also target mobile [1].
[1]: https://github.com/oven-sh/bun/issues/21237
/* Looked at the product for which Electrobun was built, co(lab). «Focus on building instead of managing tools. Keep your code, browser, terminal, notes, and git workflow in one unified interface.» Well, a great idea! This is what Emacs mostly gives me. */
Hey HN, Electrobun creator here. Thanks for posting this.
We just hit v1 - stable which means I've locked down the architecture. If you run into any bugs or need specific apis that you miss from Electron or Tauri please open Github issues and I'll prioritize them. I shipped 50,000 lines of code changes stabilizing and polishing electrobun for v1 over the last month.
Here's a video demo of Colab (also open source) (a hybrid web browser + code editor + PTY terminal) that is built with Electrobun https://www.youtube.com/watch?v=WWTCqGmE86w
Electrobun uses the system webview by default, but a lot of the hello worlds feature the bundleCEF option. Because Electrobun is architected to be webview agnostic when servo and ladybird are ready they should be drop-in alternatives.
Electrobun apps also auto generate a zstd self-extraction wrapper and patch files with every release, so your initial download will be much smaller than if you'd used zip and your updates will be as small as 14KB so you can ship as often as you like without you or your users paying the bandwidth tax.
size? performance? bun last time I checked alone is 130MB
This page says bundle size is 14MB: https://blackboard.sh/electrobun/docs/
14MB compressed though. No note on uncompressed
The uncompressed macOS app bundle size for Electrobun's `react-tailwind-vite.app` is ~63MB.
very interesting, thank you for investigating
I'm wondering about security for this sort of thing. I guess it's like node.js in the sense that while you could load JavaScript code downloaded from the Internet at runtime, you probably shouldn't? Any additional gotchas due to the web view?
The business logic of your app is running in the Main process using Bun runtime. The website you load or the app's frontend is running in a separate sandboxed Renderer process. When I run Electrobun app on macOS, I see that it launches the following processes with the following RAM usage:
- views://mainview (33.7MB) <- your frontend is running here
- react-tailwind-vite-dev Networking (5.4MB)
- react-tail wind-vite-dev Graphics and Media (16.7MB)
- react-tailwind-vite-dev (60.7MB)
no real gotchas. JS is slightly dangerous because of JS, yes. You should never fetch things at runtime to execute if possible - instead, you install absolutely everything you need with npm or bun, and it gets inlined at build time
electrobun ships with an RPC (i think it also does some encryption?) so as long as you use that to communicate between your webview and bun "host process" you should be safe.
I'm going to production with a new Electron app at my job this week, i wish this had existed a year ago lol. Electron Builder does a pretty good job making the updates and signatures not TOO painful but it hasn't been painless by any stretch.
Looks cool, I'll try this for my next personal desktop project and see how it goes
Are there any numbers on comparison to electron?
If someone from Electrobun is reading this. Can Electrobun compile to android as well. I want to create a simple application which can take some index.html and pass an adblocker and create an app out of it since I think this idea is pretty cool.
I ended up having to use Ionic to create a html <-> Android app thing within github actions but Ionic doesn't support ad blocking abilities.
they don't support mobile targets at the moment but i'm pretty sure i saw the creator saying it's a "sometime in the future" thing
Moved from the molasses of VSCode to Rust-based Zed, no comparison. The second is snappy, responsive, uses much less memory (I can have 5 Zed open at the same time, no problems), not looking back.