How do they manage the OS-specific stuff with pure TypeScript? How does it compare in benchmarks against Tauri for size and speed?
replies(2):
Given that, I was curious how their workflows folder looked but, well, that answers that question: https://github.com/blackboardsh/electrobun/tree/9ce4ed636100...
That's a pretty interesting proposal, but also a staggeringly huge amount of work.
So “no immediate plans” means check back next year after the 1.0.0 release
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.
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.
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 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 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.
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?
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'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?
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.
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 …)
But, Sadly, this is mac only[0] no windows or linux ? Do I understand it correctly ?
What about the users that are medium or large?
Also, still waiting for bun to work on freebsd. Patiently! But it's on my xmas wishlist :)
Ok, TBF they write "aims to be" and not "is", but still I think most people will get the impression that it's already cross platform and maybe some other stuff ist missing. So it would be more honest to also mention that it's currently MacOS only...
For me that first sentence made it obvious that this project isn't complete, but maybe a prominent "Preview release: Mac-only for now" would help some people.
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.
If you cant do such basic thing, which would significantly improve an ability to understand your product, then wtf
> 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.
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.
"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...
I mean for a personal project they can use whatever they want. Just and odd choice to start with if you want the project to gain traction.
If I had to pick one platform to build on, it would be linux. Pretty much every platform has the ability to run linux executables (via Docker, among others).
If this is a personal project, that's cool, but then I really don't care that much. On the other hand, I think an electron-like with something like Bun could be really useful.
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.
Having to run a docker container to get the dev env setup would be even more likely to slow adoption. Nobody wants to do that shit.
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.
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.
MacOS only means I can work with it on my machine, but can't actually build it using CI/CD.
I see what you did there
We don’t need it to be updated on every commit. Or illustrated docs but some idea of what I’m getting myself into is nice to have.
Not according to statista.com (I am not a registered user, but it looks like you could register for no cost, in order to check the source):
https://www.statista.com/statistics/869211/worldwide-softwar...
Windows is the majority OS for development, with Unix/Linux and Mac being close to equal, but both considerably less than Windows.
This is also consistent with the 2023 Stack Overflow Developer Survey (https://survey.stackoverflow.co/2023/):
Under the "Operating System" heading it says:
"Windows is the most popular operating system for developers, across both personal and professional use."
Humans have shown that we cannot even conceive of a reality outside our bubbles.
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.
Out of curiosity, I'm looking for data that is limited to the US, and will respond with results if I find them.
Just when you thought it was safe to go back in the water...
VB6: The Revenge - https://bandysc.github.io/AvaloniaVisualBasic6/
Based on my calculations from that data (extracting only the US responses, based on their entries for 'os_devenv', I get these numbers:
- Linux: 45% - Windows: 58.9 % - Mac: 51.2 %
That is conclusive enough for me to say that Windows is still the most common daily driver for developers in the US. I'm not one of those developers, as I don't use Windows as my primary development platform.
I suspect this may be a case where people tend to think that because most developers they know use a particular OS for development, that must be true everywhere.
I would not be surprised, for instance, to find out that the numbers of developers primarily using Macs at some big tech companies is much higher.
[edited for formatting]
I don't have metrics, but I bet linux is far and away the CI platform of choice.
I am not trying to bash this, but rather say that mac only is likely to limit usage. Early on that can be okay, but there are many people who will be turned off immediately.
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.
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".
And you're right, we can keep getting into this loops, so lets nip it in the bud where it all begins and shocker, not tell people to change the name of their stuff because something else exists with a similar name but completely unrelated.
Then there’s all kinds of fancy rpc between bun and zig and between bun and browser contexts.
I don't really think that's an issue for the kinds of apps people use this sort of thing for and at first blush the IPC model here is at least better than Electron which is an absolute trash fire.
[0]: https://slint.dev
It's good they have cross platform on the roadmap. Perhaps it was just unfortunate that the first thing in the headline was "Cross-platform" when that really isn't the main selling point.
Granted, it doesn't have the same support or attention or community that react-native for iOS does. But it was certainly a refreshing way to build a native app. I think some of the shine has come off it now that a lot of the ideas have been adopted into SwiftUI.
That would be https://news.ycombinator.com/user?id=CharlesW aka Charles Wiltgen.