hckrnws

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

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?

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.

> Ship updates to your users that are tiny

What about the users that are medium or large?

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.

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.

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.

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

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

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

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

It's the other way around, they only support arm at the moment: https://github.com/blackboardsh/electrobun/issues/10#issueco...

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

What does "not supported" mean?

Does it mean "you can probably get this to work, but it's not my OS so I won't go out of my way to help you" or "the build process depends on something only available on macs"?

There isn't an obvious reason it wouldn't be possible to build on linux or WSL at least on windows.

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.

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

> Firefox on Linux (usually).

No, linux is usually webkit (which is also what safari is based on). Both Gtk and Qt have webkit-based widgets.

I'm not aware of a gecko based webview for desktop. Unfortunately, Firefox's technology is even more poorly suited for embedding than chromium's.

The number 1 request I get from people is to add the ability to optionally bundle chromium.

I personally prefer the system webview because you don’t have to rush update your app for every chromium security update. And on the web making things cross browser is a normal part of the job and instinct imo.

But there are a ton of early startups that only have bandwidth to support chrome/chromium in their complex webapps and want a quick way to port their web app to desktop app. For them taking on the security burden and increasing bundle size is a good tradeoff to getting that consistency.

Luckily electrobun has a custom zig bsdiff implementation that generates update diffs as small as 4KB and self extracting executable that uses zstd so at least the file size is less relevant of a concern compared to electron.

> you don’t have to rush update your app for every chromium security update

I'm interested to hear more about this—if you're using security-sensitive features in a WebView, aren't you then at the mercy of the OS to patch them whenever they see fit? And if you're not using features that have security implications, why do you need the latest version of Chromium at all times?

> But there are a ton of early startups that only have bandwidth to support chrome/chromium in their complex webapps and want a quick way to port their web app to desktop app.

Ugh!

People writing web apps without supporting anything else than Chrome should burn in hell. (And that's a pretty useless decision anyway since “supporting chrome” really means supporting two engines: Chromium and WebKit, because Chrome on iOS uses WebKit internally …)

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

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.

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

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

A: native bindings written in zig

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.

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