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.
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 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?
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.
also wondering about this. it sure isn't in electrobuns own discord server. i'm in that one and its mostly Q&A (with Yoav doing most of the answering and a couple people like me doing most of the questioning, ha)
this is the first i'm hearing about games being built with electron / web tech too, let alone electrobun. i thought most game devs would just go for unity or godot
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.
/* 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. */
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.
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.
My understanding is that the tauri CEF will use shared libraries where-as every Electron instance has its own copy of Chrome.
That's the whole point of my post: we get a relatively up to date Chrome and we get a shared library that all Tauri apps can share! Hence why I discussed why running n+1 apps should have lower overhead.
So it seems much much much better than Electron to me. Electron values the app developer, wants to give them assurances that the chromium is the exact specified chromium version, and bundles it. I get it, the world is complex and clamping down is a natural response, but this conservatism has given Electron its deservedly bad reputation, and Tauri's slightly shifted stance alleviates so much pain.
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.
> Instead of distributing Chromium, By default Electrobun uses your system's native WebView (WebKit on macOS, Edge WebView2 on Windows, WebKitGTK on Linux).
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.
i'm not sure how you could have any meaningful comparison here except for comparing bun to node. everything is pretty modular so you can swap things out. i would compare webview to chromium bundle size, but that has tradeoffs too, and electrobun can use chromium (CEF) too. so that's also moot.
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
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.
@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."
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
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)
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.
maddada | 11 days ago
seebeen | 5 hours ago
zdragnar | 18 hours ago
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.
queenkjuul | 17 hours ago
Looks cool, I'll try this for my next personal desktop project and see how it goes
hu3 | 17 hours ago
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
GCUMstlyHarmls | 16 hours ago
hopfog | 15 hours ago
I think the most famous Electron game is Vampire Suvivors, but it has since been ported to Unity.
egeozcan | 15 hours ago
hopfog | 15 hours ago
[OP] merlindru | 4 hours ago
this is the first i'm hearing about games being built with electron / web tech too, let alone electrobun. i thought most game devs would just go for unity or godot
skybrian | 17 hours ago
Ikryanov | 11 hours ago
- 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)
[OP] merlindru | 10 hours ago
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.
nine_k | 17 hours ago
synergy20 | 16 hours ago
perpil | 16 hours ago
Bolwin | 14 hours ago
Ikryanov | 11 hours ago
[OP] merlindru | 10 hours ago
sumolessons | 15 hours ago
[1]: https://github.com/oven-sh/bun/issues/21237
lukevp | 15 hours ago
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.
onimishra | 15 hours ago
Taken from the product site (not this blog post) that was linked by another user. So you get to choose it would seem.
jauntywundrkind | 15 hours ago
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!
Ikryanov | 11 hours ago
In this case I don't know why I should use Tauri instead of Electron.
jauntywundrkind | 2 hours ago
That's the whole point of my post: we get a relatively up to date Chrome and we get a shared library that all Tauri apps can share! Hence why I discussed why running n+1 apps should have lower overhead.
So it seems much much much better than Electron to me. Electron values the app developer, wants to give them assurances that the chromium is the exact specified chromium version, and bundles it. I get it, the world is complex and clamping down is a natural response, but this conservatism has given Electron its deservedly bad reputation, and Tauri's slightly shifted stance alleviates so much pain.
Bolwin | 14 hours ago
austinjp | 13 hours ago
https://webkitgtk.org/
https://wails.io/docs/gettingstarted/installation/
https://v2.tauri.app/start/prerequisites/
kzahel | 13 hours ago
Electrobun sounds really cool, glad to see there's more work done to enable cool desktop apps without Electron.
lgvld | 11 hours ago
still:
> Optional CEF: bundle CEF (Chromium) when cross-platform consistency matters most.
from: https://blackboard.sh/electrobun/docs/guides/what-is-electro...
Imustaskforhelp | 15 hours ago
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.
[OP] merlindru | 10 hours ago
rubymamis | 15 hours ago
Ikryanov | 11 hours ago
throwaway290 | 10 hours ago
phplovesong | 15 hours ago
[OP] merlindru | 4 hours ago
what kind of numbers are you looking for?
Alifatisk | 15 hours ago
KingOfCoders | 14 hours ago
codethief | 13 hours ago
codethief | 9 hours ago
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.)
InfiniteLoopGuy | 12 hours ago
[OP] merlindru | 11 hours ago
chrisco255 | 11 hours ago
[OP] merlindru | 10 hours ago
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
mrighele | 10 hours ago
* 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 ?
xrd | 9 hours ago
[OP] merlindru | 9 hours ago
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)
xrd | 8 hours ago
yoav | 7 hours ago
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.
[OP] merlindru | 4 hours ago
jit-it | 6 hours ago
hwisnu_bearblog | 6 hours ago
Jgoauh | 6 hours ago