Electrobun v1: Build fast, tiny, and cross-platform desktop apps with TypeScript(blackboard.sh)
blackboard.sh
Electrobun v1: Build fast, tiny, and cross-platform desktop apps with TypeScript
https://blackboard.sh/blog/electrobun-v1/
62 comments
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.
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.
Are the types up to date with the docs? For example, when using BrowserWindow I get typescript errors if trying to pass an object with the key "partition".
thank you for building electrobun!!
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 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 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.
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.
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
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
node has watch mode and runs TypeScript files now too.
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.
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...
still:
> Optional CEF: bundle CEF (Chromium) when cross-platform consistency matters most.
from: https://blackboard.sh/electrobun/docs/guides/what-is-electro...
“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.
Taken from the product site (not this blog post) that was linked by another user. So you get to choose it would seem.
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.
Electrobun sounds really cool, glad to see there's more work done to enable cool desktop apps without Electron.
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/
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!
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.
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.
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.
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.
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.
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
Looks cool, I'll try this for my next personal desktop project and see how it goes
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)
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 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.
Once installed, I've found Electron installs tend to balloon from 80-200mb (installer) to 1.5GB or more (Electron + dedicated browser cache)
/* 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. */
This looks promising. And it's exciting to think it could also target mobile [1].
[1]: https://github.com/oven-sh/bun/issues/21237
[1]: https://github.com/oven-sh/bun/issues/21237
@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.)
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.)
Can modern LLMs effectively be used on Electrobun codebases?
yes. the actual APIs are very simple. i'm using claude code a lot
Awesome tooling indeed. I made the switch from my native Swift/SwiftUI app to electrobun. Building the UI in React + Tailwind, while having the RPC bridge to my native core is the game changer for me
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
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 ?
* 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 ?
[deleted]
Other distros than Ubuntu are out of scope[1], so not usable for me, sadly.
[1]: https://github.com/blackboardsh/electrobun/issues/4#issuecom...
[1]: https://github.com/blackboardsh/electrobun/issues/4#issuecom...
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 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
size? performance? bun last time I checked alone is 130MB
This page says bundle size is 14MB: https://blackboard.sh/electrobun/docs/
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)
- 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.
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.
impressive work! this might nudge me into building desktop applications.
Are there any numbers on comparison to electron?
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.
what kind of numbers are you looking for?
what kind of numbers are you looking for?
[deleted]
was looking for something just like this.
Really helpful
can you build a single .exe standalone app or standalone installer ? i only see folders or .exes relying on buind in the same folder is the archive
[deleted]
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.
Electrobun lets you open/manipulate/close webview windows and communicate with them using typed rpc. It also handles building, code signing, and notarization.
And because I'm using Bun, running an HMR + React + Tailwind server is just one command (`bun ./index.html`) or like 5 lines of code. Pass --console and the webview's console.log()s get streamed to your Terminal too.
There's tons of other things Electrobun does that I haven't even mentioned, because I haven't interacted much with them yet. E.g. I know that it lets you show platform-native notifications, prompts/popups, etc.
There also is a very impressive updating mechanism that relies on a bsdiff implementation written in Zig. You just ship the deltas, so updates to very large apps are just a few KBs most of the time.
It's genuinely a very productive stack and impressive piece of tech.
[1] Not affiliated - I just like the project.
[2]: The API and implementation was clear, so I'll cautiously say this is not a case of "rewrites are always faster". In fact, the Tauri version was a rewrite too :)