[HN Gopher] Electrobun: Cross-platform desktop applications writ...
___________________________________________________________________
Electrobun: Cross-platform desktop applications written in
TypeScript
Author : CharlesW
Score : 267 points
Date : 2024-11-20 23:58 UTC (23 hours ago)
(HTM) web link (electrobun.dev)
(TXT) w3m dump (electrobun.dev)
| sshine wrote:
| How do they manage the OS-specific stuff with pure TypeScript?
| How does it compare in benchmarks against Tauri for size and
| speed?
| semireg wrote:
| A: native bindings written in zig
| c0wb0yc0d3r wrote:
| 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 wrote:
| Native bindings written in c/objc and a zig binary that bun
| spawns.
| mdaniel wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bearjaws wrote:
| Not supporting arm is dead on arrival for anyone looking to
| build cross platform...
| sschueller wrote:
| It's the other way around, they only support arm at the
| moment: https://github.com/blackboardsh/electrobun/issues/10#
| issueco...
| bearjaws wrote:
| Ah that is confusing. Well, that still suffers the same
| problem, just in the other direction.
| marionauta wrote:
| 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.
| progforlyfe wrote:
| Funny spelling error there, too. Should be "Compatibility".
| veidr wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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
| bobajeff wrote:
| >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.
| afavour wrote:
| Eh, it'll hinder certain applications but very few, really.
| Assuming the webview is intended for UI and very little else.
| yoav wrote:
| 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.
| dmazzoni wrote:
| 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 wrote:
| 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).
| yoav wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| Or email clients that only support Gmail...
| thayne wrote:
| > 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 wrote:
| WebkitGTK has notoriously lagged behind Webkit on other
| platforms.
| Carrok wrote:
| 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 wrote:
| 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 wrote:
| Writing good documentation is extremely hard. Even 10x
| engeneers can be basically illiterate.
| metalliqaz wrote:
| > Even 10x engeneers can be basically illiterate.
|
| I see what you did there
| TripleChecker wrote:
| There's certainly a persistent issue of typos: (34 here
| that we found:
| https://triplechecker.com/s/689196/electrobun.dev).
| xixixao wrote:
| 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 wrote:
| Not the best thing for a desktop application framework maybe.
| jamager wrote:
| > Screenshots are harder to produce, maintain and publish
|
| What, really? What am I missing? If you tell me video, yes,
| but a screenshot...
| madeofpalk wrote:
| 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.
| high_na_euv wrote:
| 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
| conductr wrote:
| 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.
| teg4n_ wrote:
| i mean in this case it would be a window with any web app in
| it... not sure that would be particularly helpful.
| throwaway888abc wrote:
| "...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
| auggierose wrote:
| Add what about macOS (intel)?
| prophesi wrote:
| Here's their roadmap[0], that's later down the road as well
| (v0.4.0).
|
| [0] https://github.com/blackboardsh/electrobun/issues/2
| NoahKAndrews wrote:
| 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 wrote:
| Wild that one would pick the only platform with a rubbish VMs
| and CI story as the OS to use for building software!
| ramon156 wrote:
| If the worst case works, the best case will follow I
| suppose :P
| veidr wrote:
| 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.
| cardanome wrote:
| 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.
| gorjusborg wrote:
| 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 wrote:
| 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.
| gertop wrote:
| > At least here in the US, the majority of developers
| daily drive macs on their desktop.
|
| The majority of WEB developers.
| gorjusborg wrote:
| 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 wrote:
| I mean, GitHub Runners supports macOS for CI just fine.
| fassssst wrote:
| Citation needed, Windows is probably still bigger as Macs
| are expensive.
| leptons wrote:
| >At least here in the US, the majority of developers
| daily drive macs on their desktop
|
| Citation needed. This assertion seems very anecdotal.
| kibwen wrote:
| 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.
| nocman wrote:
| > 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):
|
| 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."
|
| [edited to include Stack Overflow survey]
| eyjafjallajokul wrote:
| They said "in the US". The data you have provided says
| "Worldwide" which doesnt prove the point about the US.
| nocman wrote:
| 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.
| nocman wrote:
| JetBrains makes their survey data available here (
| https://www.jetbrains.com/lp/devecosystem-2023/ ):
|
| 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]
| rozap wrote:
| It's totally fine if it just supports one platform. Just
| don't say it's cross platform when it's not.
| conductr wrote:
| 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 wrote:
| the apps you build _will be_ cross-platform "soon" (no
| specific timeframe)
|
| https://electrobun.dev/docs/guides/Compatability
| conductr wrote:
| 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
| rozap wrote:
| Truly wild. I guess you can just write anything in the title
| for the upvotes.
| veidr wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "aims to be" is pretty ambiguous wording. It'd be clearer
| with a "aims to one day be..."
| 7bit wrote:
| So it is not Cross-Platform.
|
| It will be.
|
| But it still is not.
| pragma_x wrote:
| 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.
| kookamamie wrote:
| > Ship updates to your users that are tiny
|
| What about the users that are medium or large?
| fbn79 wrote:
| I'm quite sure is talking about "low size update packages"
| user_7832 wrote:
| Pretty sure it was a joke on the language used ;)
| Cruncharoo wrote:
| You're gonna need a bigger boat
| schneehertz wrote:
| Basically, this is an Electron that replaces Node.js with Bun and
| Chromium with WebView?
| rounce wrote:
| It seems it bundles Chromium
| kevlened wrote:
| It doesn't yet.
|
| "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.
| ..
| surfmike wrote:
| Which webview does it use?
| bitsandboots wrote:
| 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 :)
| yard2010 wrote:
| Yoav, you are a genius. Keep up the good work.
| alkonaut wrote:
| 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 wrote:
| 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 wrote:
| > _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...
|
| VB6: The Revenge -
| https://bandysc.github.io/AvaloniaVisualBasic6/
| wilgertvelinga wrote:
| Is there anything Electrobun does to prevent XSS vulnerabilities?
| The docs actively promote setting .innerHTML, without any warning
| regarding concatenating user input.
| cxr wrote:
| 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.
| dboreham wrote:
| Never understood why these things aren't done by running a local
| http server and use a regular browser.
| whizzter wrote:
| 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 wrote:
| Local file system access is one reason, any other native APIs
| needed for making a desktop app, etc
| PittleyDunkin wrote:
| Any plan for supporting native toolkit access ala react-native,
| or is the plan to just rely on web tech?
| yr5teoes7s wrote:
| I300$
| ivanjermakov wrote:
| 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 wrote:
| 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 wrote:
| > Tauri proved that you don't need it
|
| Are there any major cross-platform apps based on it?
| klabb3 wrote:
| 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.
| yoav wrote:
| 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.
| jacobgorm wrote:
| Tauri also uses the system webview and does not bundle
| Chromium, right?
| pmuk wrote:
| Do you have any examples apps built on electrobun?
| yoav wrote:
| https://www.eggbun.sh/ is built with Electrobun.
| barbequeer wrote:
| I love to see projects like this, the more alternatives we have
| for creating cross-platform apps, the better.
| jedisct1 wrote:
| Very promising project!
| niutech wrote:
| 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.
| rubymamis wrote:
| Couldn't agree more, QML with C++ for the logic (or Rust or
| whatever other bindings you want to use), is the best imo.
| golanggeek wrote:
| Any similar platforms using Golang?
| jrop wrote:
| Wails, if I'm not mistaken: https://wails.io/
| AlfredBarnes wrote:
| Interesting to watch it grow. I'm not going to jump in right
| away, but this is a great project!
| kelvinjps10 wrote:
| The other time I was thinking why this hasn't been done, here it
| is
___________________________________________________________________
(page generated 2024-11-21 23:00 UTC)