HN Reader

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.

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.

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.

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

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.

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.

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

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.

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

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.

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 :)

>Security and Performance with isolation between the main and webview processes

That's one of the performance characteristics I'm afraid will hinder certain applications.

It sounds like you need to use a IPC bridge to share data between the main process and renderor. Which means copying all the shared data. Like if I wanted to use ffmpeg for decoding video then each frame I'm waiting for a the decoded image to be copied before rendering it.

Never understood why these things aren't done by running a local http server and use a regular browser.

Interesting to watch it grow. I'm not going to jump in right away, but this is a great project!

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

Any plan for supporting native toolkit access ala react-native, or is the plan to just rely on web tech?

Which webview does it use?

Any similar platforms using Golang?

Why do so many projects fail to include any screenshots at all?

Maybe the authors don't think it's necessary, but step 3 under `Getting Started` is called `Creating UI`. Why would they not show what the result of the tutorial looks like?

Very promising project!

"...and cross-platform desktop applications" the homepage says

But, Sadly, this is mac only[0] no windows or linux ? Do I understand it correctly ?

[0] https://electrobun.dev/docs/guides/Compatability

So it's a kind of electron apps, packaged for Arm Mac only? Hate to be that guy but that's the least cross platform thing I could imagine. I mean Windows Forms apps and VB6 apps are more cross platform than that (at least supporting one OS but a couple of architectures).

> Ship updates to your users that are tiny

What about the users that are medium or large?

Bold choice: https://electrobun.dev/docs/guides/Compatability#:~:text=No%... (that text appears right next to "macOS (arm)")

Given that, I was curious how their workflows folder looked but, well, that answers that question: https://github.com/blackboardsh/electrobun/tree/9ce4ed636100...

The other time I was thinking why this hasn't been done, here it is

I'm a fan of more frameworks for desktop apps that wrap system webview rather than embedding Chromium.

Chromium is awesome and all, but it's just way overkill for many apps, and doesn't make sense for the download size and the need to support auto-update for security features.

I300$

Is there anything Electrobun does to prevent XSS vulnerabilities? The docs actively promote setting .innerHTML, without any warning regarding concatenating user input.