But, Sadly, this is mac only[0] no windows or linux ? Do I understand it correctly ?
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?
What about the users that are medium or large?
That's a pretty interesting proposal, but also a staggeringly huge amount of work.
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.
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.
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.
Given that, I was curious how their workflows folder looked but, well, that answers that question: https://github.com/blackboardsh/electrobun/tree/9ce4ed636100...
So “no immediate plans” means check back next year after the 1.0.0 release
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.
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.
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.
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.
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?
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 …)
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.
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.