Electrobun: Cross-platform desktop applications written in TypeScript

323 pointsposted 8 months ago
by CharlesW

74 Comments

yoav

8 months ago

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.

pmuk

8 months ago

Do you have any examples apps built on electrobun?

jacobgorm

8 months ago

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

veidr

8 months ago

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

8 months ago

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.

zephraph

8 months ago

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

8 months ago

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.

sshine

8 months ago

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

c0wb0yc0d3r

8 months ago

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.

semireg

8 months ago

A: native bindings written in zig

thot_experiment

8 months ago

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

8 months ago

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

8 months ago

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

8 months ago

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.

rubymamis

8 months ago

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

cageface

8 months ago

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

8 months ago

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

bitsandboots

8 months ago

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

8 months ago

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

rounce

8 months ago

It seems it bundles Chromium

yard2010

8 months ago

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

ivanjermakov

8 months ago

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

8 months ago

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.

bobajeff

8 months ago

>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.

yoav

8 months ago

Originally I had it going via browser -> postmessage -> zig -> bun via named pipes and then bun -> zig via named pipe -> js via evaluate js.

I’m building https://colab.sh/ with electrobun and that rpc was pretty slow when trying to load multi MB files in the code editor.

Last week I added an encrypted socket rpc option directly between bun and browser.

Loading a 2MB file went from a few seconds to 400ms.

I made it so that in contexts where CORS allows it automatically upgrades to the socket based faster RPC.

That’s via RPC though. electrobun also exposes a custom views:// scheme in the browser context that can load files directly from specific sandboxed places in the file system. More to improve there but for a very big file you’d be better off writing it to the file system that would be much faster.

afavour

8 months ago

Eh, it’ll hinder certain applications but very few, really. Assuming the webview is intended for UI and very little else.

AlfredBarnes

8 months ago

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

user

8 months ago

[deleted]

dboreham

8 months ago

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

whizzter

8 months ago

Developing for Electron you usually had a regular webpack server in the background to handle hot-reload cases and technically you could have a regular browser.

In production however you don't want a browser for 2 reasons, first should a local app really expose internals to the network(And get mucked up by firewalls)? secondly the deployment is easier the more it's self-contained.

Also since there are internal communication channels between "browser" and native/"server" parts (that are far faster than going over the network) you don't want to diverge the production and development environment to avoid having hard to debug things.

On top of it, in this case bun is also a bundler so you get the typescript transpilation for free.

So to summarize, if your app is really only a plain webapp distributed to desktop then sure you can developer everything with a local webserver and package with whatever is available, but as soon as you involve native off-browser parts you don't want to start exposing everything and using the embedding systems(be it electron or webview2/khtml,etc) built in browser<->native communication is simply the saner choice and the point of these projects is to abstract that from the developer.

dymk

8 months ago

Local file system access is one reason, any other native APIs needed for making a desktop app, etc

PittleyDunkin

8 months ago

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

c-smile

8 months ago

You can use my Sciter if you need native widgets.

Sciter is an HTML/CSS/JS engine with the ability to attach native widgets to DOM elements. So you'll benefit from two worlds: HTML/CSS layout richness and native widgets.

The major problem though is Linux family of OSes in this respect. I have version of Sciter that works directly on X11 or Wayland ( https://sciter.com/sciter-glx-generation-4/ ). Windows and MacOS have clear concept of child windows/widgets but no such things on X11 or Wayland realistically speaking.

So react-native is practically iOS/Android only thing.

surfmike

8 months ago

Which webview does it use?

jedisct1

8 months ago

Very promising project!

Carrok

8 months ago

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?

Ringz

8 months ago

Not only are screenshots often missing, but I’m also surprised by how many projects fail to describe the purpose and goals of their project in short, simple sentences. Many mistakenly assume that only users and developers visit the website or repository, not decision-makers. More ELI5 ("Explain Like I'm 5") can never hurt.

xixixao

8 months ago

Screenshots are harder to produce, maintain and publish.

I also suspect many technical authors are less “visual” so to speak, putting less emphasis on visual presentation.

teg4n_

8 months ago

i mean in this case it would be a window with any web app in it… not sure that would be particularly helpful.

user

8 months ago

[deleted]

throwaway888abc

8 months ago

"...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

NoahKAndrews

8 months ago

Looks like they're planning to only ever support building on Mac, but they plan to support running on Windows and Linux in the future

veidr

8 months ago

No, that's not the case — read this whole thread. It's starting with macOS. The cross-platform stuff will come later, if the project goes well.

pragma_x

8 months ago

That is correct. If you install the `electrobun` package via bun or npm, you get a pile of arm64 binaries. These are big enough to ship a web-browser (Electron) so that would explain why they're binaries in the first place.

auggierose

8 months ago

Add what about macOS (intel)?

user

8 months ago

[deleted]

mdaniel

8 months ago

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...

yoav

8 months ago

It’s still early and it’s just me working on it so I’m trying to get to stability and then building for (distribute apps to) windows and linux before making all the cli stuff work to let you dev on other OSes.

So “no immediate plans” means check back next year after the 1.0.0 release

marionauta

8 months ago

The current version is 0.0.13 (on the homepage), it's normal that the author is focusing on their platform at the moment. It probably was too son to post it on here.

bearjaws

8 months ago

Not supporting arm is dead on arrival for anyone looking to build cross platform...

progforlyfe

8 months ago

Funny spelling error there, too. Should be "Compatibility".

user

8 months ago

[deleted]

kookamamie

8 months ago

> Ship updates to your users that are tiny

What about the users that are medium or large?

Cruncharoo

8 months ago

You’re gonna need a bigger boat

fbn79

8 months ago

I'm quite sure is talking about "low size update packages"

user

8 months ago

[deleted]

alkonaut

8 months ago

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

jopicornell

8 months ago

Well, it's not like VB6, which never had compatibility on any other OS. They are starting out and they are confortable with that small scope, which I think is good for projects like this. They have Windows and Linux suport on their roadmap.

user

8 months ago

[deleted]

dmazzoni

8 months ago

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.

hresvelgr

8 months ago

I feel the reason the system web-view is eschewed in these frameworks is because you have no choice but to maintain compatibility with 3-4 browsers: Edge/IE on Windows, Safari on Mac, and Firefox on Linux (usually).

user

8 months ago

[deleted]

kelvinjps10

8 months ago

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

user

8 months ago

[deleted]

KameltoeLLM

8 months ago

[flagged]

pluc

8 months ago

I would've gone for Node++ or Node#

wilgertvelinga

8 months ago

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

cxr

8 months ago

What can it do? The only thing that prevents that is the programmer knowing what kinds of inputs they're dealing with and making sure unsafe input is properly escaped into safe input when the context calls for escaped input. There's no getting around this.