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.
Tauri also uses the system webview and does not bundle Chromium, right?
davidmurdoch 34 days ago [-]
"it’s like Tauri in that it uses the system webview and does not bundle chromium"
bsimpson 35 days ago [-]
[flagged]
joshmanders 35 days ago [-]
> You should pick a different name.
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.
benatkin 34 days ago [-]
These comments don't solve the annoyance of false assumptions on HN, because they often contain a false assumption of their own.
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".
joshmanders 34 days ago [-]
And then when this project explodes and becomes as well known as Electron is eclipsing Google Colab (I never heard of it until today) then your argument is invalid.
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.
veidr 35 days 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 35 days 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.
veidr 35 days ago [-]
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.
klabb3 35 days ago [-]
> 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.
brailsafe 35 days ago [-]
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
zephraph 34 days 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 34 days 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.
zephraph 33 days ago [-]
Ah, cool, that’s essentially what I’m doing too. Rust binary does the system interactions. I’m just using a pretty simple json RPC over stdio though.
sshine 35 days 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 35 days 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.
yoav 35 days ago [-]
Native bindings written in c/objc and a zig binary that bun spawns.
semireg 35 days ago [-]
A: native bindings written in zig
thot_experiment 34 days 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 33 days 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.
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 34 days 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.
niutech 24 days ago [-]
You can get pretty much any layout using Qt/QML or Gtk.Builder, no need for bloated webview.
dgfitz 34 days ago [-]
> Modern apps these days often end up needing to render complex layouts and rich text
/end up needing/choosing/
rubymamis 35 days 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.
Tmpod 34 days ago [-]
If you want to use Rust, Slint[0] may be something to consider, seeing as the existing bindings for Qt and QML are not very pleasing to use (mostly talking about qmetaobject-rs and cxx-qt). If I'm not mistaken, Slint is developed by ex-QML people.
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 35 days ago [-]
I love to see projects like this, the more alternatives we have for creating cross-platform apps, the better.
bitsandboots 35 days 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 35 days ago [-]
Basically, this is an Electron that replaces Node.js with Bun and Chromium with WebView?
rounce 35 days ago [-]
It seems it bundles Chromium
kevlened 35 days ago [-]
It doesn't yet.
"Use the built-in system Webview (or bundle a 3rd party webview like Chromium: coming soon...)"
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 35 days 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.
Wytwwww 35 days ago [-]
> Tauri proved that you don’t need it
Are there any major cross-platform apps based on it?
klabb3 35 days ago [-]
Last I checked they did a pretty bad job showcasing the apps. But search for “awesome-tauri”, it’s pretty standard these days. Way past the initial hipster phase, almost boring.
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.
bobajeff 35 days 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 35 days 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.
thot_experiment 34 days ago [-]
Sure but "fast communication" is always going to be prohibitively slow if you are used to "reading the same chunk of memory".
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.
afavour 35 days ago [-]
Eh, it’ll hinder certain applications but very few, really. Assuming the webview is intended for UI and very little else.
AlfredBarnes 35 days ago [-]
Interesting to watch it grow. I'm not going to jump in right away, but this is a great project!
35 days ago [-]
dboreham 35 days ago [-]
Never understood why these things aren't done by running a local http server and use a regular browser.
whizzter 35 days 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 35 days ago [-]
Local file system access is one reason, any other native APIs needed for making a desktop app, etc
PittleyDunkin 35 days ago [-]
Any plan for supporting native toolkit access ala react-native, or is the plan to just rely on web tech?
c-smile 34 days 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.
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.
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 35 days 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.
majkinetor 35 days ago [-]
Writing good documentation is extremely hard. Even 10x engeneers can be basically illiterate.
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.
steve1977 35 days ago [-]
Not the best thing for a desktop application framework maybe.
jamager 35 days ago [-]
> Screenshots are harder to produce, maintain and publish
What, really? What am I missing? If you tell me video, yes, but a screenshot...
madeofpalk 35 days ago [-]
I don't think it's that hard, but it's easier for screenshots to drift and become out of date compared to just written text documentation.
conductr 35 days ago [-]
You’re just trying to give us the gist of things with images. It’s basically selling your thing to me as something I would want to try out. Usually if I connect with something I see in first few moments then my likelihood of trying the thing out is higher.
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.
high_na_euv 35 days ago [-]
It is literally a few minutes of effort
If you cant do such basic thing, which would significantly improve an ability to understand your product, then wtf
stiltzkin 35 days ago [-]
[dead]
teg4n_ 35 days ago [-]
i mean in this case it would be a window with any web app in it… not sure that would be particularly helpful.
34 days ago [-]
35 days ago [-]
throwaway888abc 35 days 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 ?
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
jclulow 35 days ago [-]
Wild that one would pick the only platform with a rubbish VMs and CI story as the OS to use for building software!
veidr 35 days ago [-]
What's wild about it? It's one person, and they probably mainly use a Mac. If they used Windows, it would be Windows-only at this stage. I have lots of projects that only run on Linux. Clearly, if the project succeeds and gains tractions, the other platforms will come.
gorjusborg 35 days ago [-]
It assume it will severely limit its uptake.
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.
stickfigure 35 days ago [-]
At least here in the US, the majority of developers daily drive macs on their desktop. Even (especially!) the ones that deploy exclusively on linux.
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.
nocman 35 days ago [-]
> At least here in the US, the majority of developers daily drive macs on their desktop.
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):
"Windows is the most popular operating system for developers, across both personal and professional use."
[edited to include Stack Overflow survey]
eyjafjallajokul 35 days ago [-]
They said "in the US". The data you have provided says "Worldwide" which doesnt prove the point about the US.
nocman 35 days ago [-]
fair point, however I suspect that if you narrow the scope of the data to the US (even the data from those surveys) it will not change the results much.
Out of curiosity, I'm looking for data that is limited to the US, and will respond with results if I find them.
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]
gorjusborg 35 days ago [-]
But almost nobody uses MacOS to run CI, which is usually how artifacts are built for the field. Having linux support first means people can actually use this for production (this project seems from from ready for that anyway) with some inconvenience for local dev.
MacOS only means I can work with it on my machine, but can't actually build it using CI/CD.
Klonoar 35 days ago [-]
I mean, GitHub Runners supports macOS for CI just fine.
gorjusborg 34 days ago [-]
Okay, fair.
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.
leptons 35 days ago [-]
>At least here in the US, the majority of developers daily drive macs on their desktop
Citation needed. This assertion seems very anecdotal.
kibwen 35 days ago [-]
Recently I saw someone assert that "almost nobody uses 1080p monitors anymore". Meanwhile the Steam Hardware Survey shows that 1080p is the majority resolution among PC gamers, and almost 2/3 of users have a monitor that is 1080p or smaller.
Humans have shown that we cannot even conceive of a reality outside our bubbles.
gertop 35 days ago [-]
> At least here in the US, the majority of developers daily drive macs on their desktop.
The majority of WEB developers.
fassssst 35 days ago [-]
Citation needed, Windows is probably still bigger as Macs are expensive.
rozap 35 days ago [-]
It's totally fine if it just supports one platform. Just don't say it's cross platform when it's not.
conductr 35 days ago [-]
The apps you build are cross-platform apps. The tool itself isn’t. That’s how I read it anyways, nothing misleading that I saw
jonasdoesthings 35 days ago [-]
the apps you build will be cross-platform "soon" (no specific timeframe)
It’s the HN link description that’s confusing y’all then? Because the home page, where you clicked before navigating to the compatibility page, says they “aim… to be cross-platform” says nothing of that being the current state
cardanome 35 days ago [-]
With Linux you can dockerize it and make available for all all platforms. With Mac you only reach people that have access to Mac.
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.
ramon156 35 days ago [-]
If the worst case works, the best case will follow I suppose :P
yr5teoes7s 35 days ago [-]
[flagged]
rozap 35 days ago [-]
Truly wild. I guess you can just write anything in the title for the upvotes.
veidr 35 days 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.
rob74 35 days ago [-]
Quote from the homepage: Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript.
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...
veidr 35 days ago [-]
I think the actual website is pretty clear that the project is in the very early stages; I think the HN submitter (not the project author) made the headline sound more like this project is ready (perhaps inadvertently).
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.
stevage 35 days ago [-]
"aims to be" is pretty ambiguous wording. It'd be clearer with a "aims to one day be..."
7bit 35 days ago [-]
So it is not Cross-Platform.
It will be.
But it still is not.
pragma_x 35 days 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 35 days ago [-]
Add what about macOS (intel)?
prophesi 35 days ago [-]
Here's their roadmap[0], that's later down the road as well (v0.4.0).
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
thayne 35 days ago [-]
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.
marionauta 35 days 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 35 days ago [-]
Not supporting arm is dead on arrival for anyone looking to build cross platform...
Ah that is confusing. Well, that still suffers the same problem, just in the other direction.
progforlyfe 35 days ago [-]
Funny spelling error there, too. Should be "Compatibility".
35 days ago [-]
kookamamie 35 days ago [-]
> Ship updates to your users that are tiny
What about the users that are medium or large?
Cruncharoo 35 days ago [-]
You’re gonna need a bigger boat
fbn79 35 days ago [-]
I'm quite sure is talking about "low size update packages"
user_7832 35 days ago [-]
Pretty sure it was a joke on the language used ;)
35 days ago [-]
alkonaut 35 days 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 35 days 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.
peutetre 35 days ago [-]
> it's not like VB6, which never had compatibility on any other OS
Just when you thought it was safe to go back in the water...
I was considering 16/32/64bit versions of windows as being several platforms while
arm-only MacOS is a single one.
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.
35 days ago [-]
dmazzoni 35 days 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 35 days 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).
thayne 35 days ago [-]
> 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.
Klonoar 35 days ago [-]
WebkitGTK has notoriously lagged behind Webkit on other platforms.
yoav 35 days ago [-]
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.
lolinder 35 days ago [-]
> 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?
littlestymaar 35 days ago [-]
> 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 …)
jamager 35 days ago [-]
Or email clients that only support Gmail...
ericwood 34 days ago [-]
These days it's really not bad, and it's even easier than shipping a normal web app, where there's a potentially unbounded number of browsers consuming it. Knowing exactly which clients to develop for is a luxury.
35 days ago [-]
kelvinjps10 35 days ago [-]
The other time I was thinking why this hasn't been done, here it is
35 days ago [-]
Culonavirus 35 days ago [-]
[flagged]
KameltoeLLM 35 days ago [-]
[flagged]
pluc 35 days ago [-]
I would've gone for Node++ or Node#
yr5teoes7s 35 days ago [-]
I300$
wilgertvelinga 35 days ago [-]
Is there anything Electrobun does to prevent XSS vulnerabilities?
The docs actively promote setting .innerHTML, without any warning regarding concatenating user input.
cxr 35 days 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.
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.
That would be https://news.ycombinator.com/user?id=CharlesW aka Charles Wiltgen.
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.
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.
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.
Then there’s all kinds of fancy rpc between bun and zig and between bun and browser contexts.
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.
/end up needing/choosing/
[0]: https://slint.dev
Also, still waiting for bun to work on freebsd. Patiently! But it's on my xmas wishlist :)
"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...
> 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.
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.
Are there any major cross-platform apps based on it?
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.
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.
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.
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.
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.
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.
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?
I see what you did there
I also suspect many technical authors are less “visual” so to speak, putting less emphasis on visual presentation.
What, really? What am I missing? If you tell me video, yes, but a screenshot...
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.
If you cant do such basic thing, which would significantly improve an ability to understand your product, then wtf
But, Sadly, this is mac only[0] no windows or linux ? Do I understand it correctly ?
[0] https://electrobun.dev/docs/guides/Compatability
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.
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.
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:
[edited to include Stack Overflow survey]Out of curiosity, I'm looking for data that is limited to the US, and will respond with results if I find them.
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]
MacOS only means I can work with it on my machine, but can't actually build it using CI/CD.
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.
Citation needed. This assertion seems very anecdotal.
Humans have shown that we cannot even conceive of a reality outside our bubbles.
The majority of WEB developers.
https://electrobun.dev/docs/guides/Compatability
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.
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.
It will be.
But it still is not.
[0] https://github.com/blackboardsh/electrobun/issues/2
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.
What about the users that are medium or large?
Just when you thought it was safe to go back in the water...
VB6: The Revenge - https://bandysc.github.io/AvaloniaVisualBasic6/
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.
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 …)