Brian Lovin
/
Hacker News
Daily Digest email

Get the top HN stories in your inbox every day.

yoav

Hey hn! Author here:

Thanks to whoever submitted.

Electrobun is in the very early stages. The roadmap is a bit out of date. Here are some highlights:

- it’s like Tauri in that it uses the system webview and does not bundle chromium

- it’s like Electron in that it bundles Bun instead of Node for the main process so you just write typescript for both the main and browser contexts

- native bindings written in c/objc with a zig wrapper that the bun process runs

- it will be cross platform, but working on stability first

- the cli handles updates code signing and everything else you need and outputs build artifacts that you just need to upload to S3 or any static file host.

- it has a custom optimized bsdiff implementation in zig that autogenerates updates for your app as small as 4KB

- it has a custom zig self extracting mechanism that uses zstd so your initial download is also as small as can be.

- it has a custom encrypted easy to use RPC mechanism between bun and browser processes where you just write method signatures and handlers.

- it has a custom OOPIF implementation so you can embed isolated browser contexts with your html <electrobun-webview> element that are performant and easy to use so you could build a multi tab web browser with it if you wanted.

chalst

> Thanks to whoever submitted.

That would be https://news.ycombinator.com/user?id=CharlesW aka Charles Wiltgen.

chalst

He’s on BlueSky, where I see Yoav already follows.

pmuk

Do you have any examples apps built on electrobun?

yoav

https://www.eggbun.sh/ is built with Electrobun.

jacobgorm

Tauri also uses the system webview and does not bundle Chromium, right?

davidmurdoch

"it’s like Tauri in that it uses the system webview and does not bundle chromium"

bsimpson

[flagged]

joshmanders

> You should pick a different name.

Can we please stop telling people to change their names because something else exists with a similar name?

If we take this stance seriously, then Google would have to change their name as San Diego Colab has existed for a year before Jupyter was created, therefore existed before Google Colab.

benatkin

These comments don't solve the annoyance of false assumptions on HN, because they often contain a false assumption of their own.

Google didn't have the same issue with confusion because of San Diego Colab that colab.sh will have if they keep their name and get popular. That's because San Diego Colab wasn't nearly as well known as Google Colab is now.

So I can say "Can we please stop" to your comment, and I'm sure you can find something with my comment and get in a loop of "can we please stop".

veidr

So this aspires to be something like Tauri, but with Zig for the fast/native bits, and leaning harder on and more opinionated about the frontend/UI part?

That's a pretty interesting proposal, but also a staggeringly huge amount of work.

yoav

It’s only been a few months but yes it’s a huge undertaking.

I’m only picking up steam though and my whole career has been taking on these kinds of huge projects so it’s just getting started.

veidr

Awesome. :) Good luck.

I think it's a really attractive package for an early-stage one-person project. Nice docs, and cute bunny.

FWIW, it also seems super-sensible to focus on Mac only for now, and get the basics working well there — a good Mac DX could provide the traction/momentum to get more contributors to help build out the obvious cross-platform promise.

klabb3

> it also seems super-sensible to focus on Mac only for now

I’m the first guy to agree to reduced scope, but unfortunately the reality of cross platform is that the subtle details affect the APIs, and once you add more platforms, you can realize issues too late. As a simple example, MacOS has a concept of “showing/activating the app” whereas Windows has… well individual windows. They add up, especially if you add mobile to the mix.

I think the most sensible is to keep the api surface small, and also to peek at electron, tauri etc to learn and try not making expensive mistakes.

brailsafe

Ya, I kind of hate to say it, but it feels like because of Window's backwards compatibility and variation in UI styles over the years, people expect Mac apps to be comparatively pretty consistent, and consistently good. There's some wiggle room, but usually it's some niche open source app that's just too generally useful to prioritize mac

zephraph

This is awesome! I built a similar tool as an experiment while at Recurse: https://github.com/zephraph/webview. Didn’t really do any heavy lifting though, just reused some of Tauri’s crates. Does Bun run on the same process as the GUI binding? OSX steals the main thread when rendering a native window which made me lean towards separating the processes. Still wonder if there’s a better way.

yoav

I’m using bun for the main process. Bun runs a zig binary which can call objc/c methods. So the “main native application thread” is technically the zig process.

Then there’s all kinds of fancy rpc between bun and zig and between bun and browser contexts.

zephraph

Ah, cool, that’s essentially what I’m doing too. Rust binary does the system interactions. I’m just using a pretty simple json RPC over stdio though.

sshine

How do they manage the OS-specific stuff with pure TypeScript? How does it compare in benchmarks against Tauri for size and speed?

c0wb0yc0d3r

I dug through it a tiny bit because I was curious as well. To me it looks like OS-specifics aren't dealt with in the project. It uses bun to run the TypeScript. From the getting started docs the project just opens a browser window for the UI. I didn't look to see if this meant the user's default browser or a bundled browser.

yoav

Native bindings written in c/objc and a zig binary that bun spawns.

semireg

A: native bindings written in zig

thot_experiment

Tangential but I hadn't heard of Bun before and their performance claims had me interested, sadly seems you just can't beat V8 in the real world. I threw some poorly optimized art code I wrote yesterday at it and it's almost 2x as slow as when I run the same code in node.

hiccuphippo

Most of the speed ups seem to be in optimizations to the native code and porting js libraries to it. I'd expect pure javascript code to not have much of a difference. 2x sounds like you hit some limitations of JavaScriptCore itself.

niutech

So is it a yet another webview-based framework like NeutralinoJS (https://neutralino.js.org), Electrino (https://github.com/pojala/electrino) or DeskGap (https://deskgap.com)? What's their advantage apart from using Bun instead of Node?

For relly lightweight cross-platform desktop apps better use a non-webview-based native framework like Qt, GTK, wxWidgets or even recently released FLTK 1.4.

yayoohooyahoo

Modern apps these days often end up needing to render complex layouts and rich text, so you end up needing QWebview anyway. At least that's been my experience creating desktop apps lately.

niutech

You can get pretty much any layout using Qt/QML or Gtk.Builder, no need for bloated webview.

dgfitz

> Modern apps these days often end up needing to render complex layouts and rich text

/end up needing/choosing/

rubymamis

Couldn't agree more, QML with C++ for the logic (or Rust or whatever other bindings you want to use), is the best imo.

Tmpod

If you want to use Rust, Slint[0] may be something to consider, seeing as the existing bindings for Qt and QML are not very pleasing to use (mostly talking about qmetaobject-rs and cxx-qt). If I'm not mistaken, Slint is developed by ex-QML people.

[0]: https://slint.dev

cageface

One of my favorite things about Tauri is that I can write all the "back end" code in Rust. I think this has a lot of advantages for performance and correctness. For that reason alone I'm more inclined to reach for it than Electron or something like this when I have options.

barbequeer

I love to see projects like this, the more alternatives we have for creating cross-platform apps, the better.

bitsandboots

As an alternative to electron, using bun as a base sounds nice. But being better than electron is a low bar when it's the source of the laziest, most bloated programs on my system.

Also, still waiting for bun to work on freebsd. Patiently! But it's on my xmas wishlist :)

schneehertz

Basically, this is an Electron that replaces Node.js with Bun and Chromium with WebView?

rounce

It seems it bundles Chromium

kevlened

It doesn't yet.

"Use the built-in system Webview (or bundle a 3rd party webview like Chromium: coming soon...)"

https://electrobun.dev/docs/guides/Getting%20Started/What%20...

rounce

Thanks, I stand corrected.

yard2010

Yoav, you are a genius. Keep up the good work.

ivanjermakov

What rendering engine does it use? Project name suggests Electron, but they never mention it

> The current Electrobun Playground app is 50.4MB in size (most of this is the bun runtime)

Seems to be more than just bun runtime.

klabb3

Electron is not a rendering engine. It’s an application bundler, which itself bundles Chromium and NodeJS.

This project uses native web views, like Tauri. They wrote that they might provide the option of bundling your own engine, ie like Electron, which I personally think it’s a bad idea. Tauri proved that you don’t need it.

But now that you mention it, agreed that 50MB is a lot.. maybe just standard JS dep bloat? That could be clarified.

Wytwwww

> Tauri proved that you don’t need it

Are there any major cross-platform apps based on it?

klabb3

Last I checked they did a pretty bad job showcasing the apps. But search for “awesome-tauri”, it’s pretty standard these days. Way past the initial hipster phase, almost boring.

A bit of self promo: you can also check out https://payload.app/ which is the project I’ve been working on for way too long now.

Daily Digest email

Get the top HN stories in your inbox every day.

Electrobun: Cross-platform desktop applications written in TypeScript - Hacker News