Desktop support (Electron replacement)

[vjpr]

Would be nice to have a cleaner, simpler desktop story for JS than Electron. And with easier native bindings.

Probably good to look at WebView2's innovations as it looks like Microsoft's own replacement of Electron...

https://dev.to/noseratio/some-thoughts-on-the-new-microsoft-teams-2-0-architecture-webview2-reactjs-1gf1

[vjpr]

Tauri

Might also be worth looking at https://github.com/tauri-apps/tauri.

Electron is tightly integrated with Node.js and Chromium.

Tauri is not.

If you wanted to use Node.js in Tauri, you would run a sidecar process. The comms are done via stdin/stdout though which isn't very efficient. Bun could be used here instead of Node.js.

The Tauri plan is also to make it backend-language agnostic:

Today, Tauri uses Rust for the backend - but in the not too distant future, other backends like Go, Nim, Python, Csharp, etc. will be possible. This is because we are maintaining the official Rust bindings to the webview organization and plan to let you switch out the backend for your needs. Since our API can be implemented in any language with C interop, full compliance is only a PR away.
https://tauri.app/about/intro/#polyglots-not-silos

So Zig could be ultimately used here and Bun too.

I would prefer to write a backend in TypeScript running in Bun, and then use Zig FFI.

---

"Web view"

FYI. This webview they talk about is here: https://github.com/webview/webview. The API is rather simple, it's about 10 functions.

webview.h is a header-only library that provides an abstraction across the webview controls available on different platforms (macOS, Linux, Win). When programming on each platform, the webview is the control that you would use in an app to display some web content.

Each programming language (e.g. webview_rust, webview_c) simply wraps webview.h.

There are three platforms supported:

/* WEBVIEW_GTK, WEBVIEW_COCOA, WEBVIEW_EDGE */

For Linux, it uses webkit2gtk

https://github.com/webview/webview/blob/fe765aa38d3425a55b27b1ee4df34d6a53a124d6/webview.h#L455

GtkWidget *m_window;
GtkWidget *m_webview = webkit_web_view_new();

For macOS, it uses Cocoa WKWebView

https://developer.apple.com/documentation/webkit/wkwebview

WKWebView replaces the UIWebView class in iOS 8 and later, and it replaces the WebView class in macOS 10.10 and later.

https://github.com/webview/webview/blob/fe765aa38d3425a55b27b1ee4df34d6a53a124d6/webview.h#L640

m_webview = ((id(*)(id, SEL))objc_msgSend)("WKWebView"_cls, "alloc"_sel);

For Windows, it uses Win32 API which in turn uses Edge/Chromium webview2.

https://github.com/webview/webview/blob/fe765aa38d3425a55b27b1ee4df34d6a53a124d6/webview.h#L1080

      m_window = CreateWindowW(L"webview", L"", WS_OVERLAPPEDWINDOW,
                               CW_USEDEFAULT, CW_USEDEFAULT, 640, 480, nullptr,
                               nullptr, hInstance, nullptr);

Bun + webview.h

Bun just needs to implement this, and then a window management library (like https://github.com/tauri-apps/tao) and you could have a nice lightweight desktop app platform.

With desktop apps, download size and memory usage are usually the biggest concerns.

Compared to Electron:

• With webview.h you don't need to bundle Chromium as you use the native platforms web control.
• No longer need Node.js, only bun.js.
• Could you use the system's JavaScriptCore as a shared library on macOS?

[vjpr]

Update

https://twitter.com/jarredsumner/status/1599662060744626176

Related Discussions

https://discord.com/channels/876711213126520882/903845031230713857/1048892113586225182

[jaymakes11]

Related: Gluon is working on experimental Bun support.

Gluon is different than other Electron alternatives in that it uses the Chrome/Chromium/Firefox version installed on the system (rather than shipping a duplicate one, like Electron, or using the native Webview (which results in potential bugs in your app due to browser differences).

[iSuslov]

Dead gluon-framework/gluon#78

[beorn]

Webview integrations for Bun already exist:
https://github.com/theseyan/bunview
https://github.com/evanwashere/webview
https://github.com/tr1ckydev/webview-bun (thx @tr1ckydev)

(I guess it might also be possible to wrap/extract stuff from Playwright to support many more web runtimes.)

But, you also need another set of APIs for more app-like feel and OS integrations (menus, app lifecycle, app store etc).

It'd be great for bun build --compile to be all you need need to build mobile & desktop apps :)

[vjpr]

Implementation notes:

https://github.com/theseyan/bunview

Spawns and talks to a child process (written in Zig) via stdio, that then talks to webview.h (https://github.com/webview/webview) which uses Apple's WKWebView control.

Inspired by https://github.com/ziglibs/positron

https://github.com/evanwashere/webview

Uses dlopen from bun:ffi to call a Zig library, which spawns a Rust executable, that uses Tauri's wry library (https://github.com/tauri-apps/wry).

[tr1ckydev]

Might be worth checking out https://github.com/tr1ckydev/webview-bun

[amritk]

@tr1ckydev how far along is it, might consider using it for a production app. Is it ready?

[tr1ckydev]

@tr1ckydev how far along is it, might consider using it for a production app. Is it ready?

haven't updated the repo since months, but i do have plans to update it by end of next week. I wonder if the repo still works.

[jaymakes11]

Recently learned about Socket Supply.

[SimonMeskens]

Webview type stuff is nothing like Electron though. The whole point of Electron is that I know exactly which version of Chromium I'm receiving and therefore no longer need to worry about which technologies are available on the user's computer.

[vjpr]

The WKWebView macOS control is open-source in the WebKit tree.

So Bun could just ship that if it likes.

---

Also, Microsoft's new WebView2 Control (Windows for now, Linux and Mac coming...apparently).

They deploy it as a Runtime. https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution

Can share a previously installed library, or ship a fixed version.

[SimonMeskens]

Thanks! That's cool.

[vjpr]

Just want to add some more notes from my research.

The source code for WKWebView is open-source in the WebKit tree here https://github.com/WebKit/webkit/blob/main/Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm.

webkit.h solutions (like Tauri) just use this control, but as a shared lib shipped with macOS.

An example of a fully-fledged browser running WebKit is here: https://browser.kagi.com/.

In the WebKit source tree, there are many examples of building browsers with WKWebView:

• https://github.com/WebKit/WebKit/tree/main/Tools/MiniBrowserSwiftUI
  • MS Windows - ongoing work to use Swift on Windows also used by Arc Browser too: https://www.swift.org/blog/swift-on-windows/
• https://github.com/WebKit/WebKit/tree/main/Tools/MiniBrowser
  • MS Windows - has a Windows target: https://github.com/WebKit/WebKit/tree/main/Tools/MiniBrowser/win
• https://github.com/WebKit/WebKit/tree/main/Tools/MobileMiniBrowser
  • For mobile

---

What this means is that Bun can:

• ship a fixed verison of the WKWebView control
• patch WKWebView to work around complaints or lack of flexibility in the API
• ship a Bun Desktop Runtime analgous to the WebView2 Runtime.

Since Electron 20 they are sanboxing by default. Which means all comms are via IPC. So I'm not sure if there is much benefit to deeply integrating the JS Runtime with the renderer anymore.

• https://www.electronjs.org/docs/latest/tutorial/sandbox
• https://code.visualstudio.com/blogs/2022/11/28/vscode-sandbox

WebView2 Runtime

Chrome released a forked WebKit version in 2008 with a multiprocess architecture.

WebKit2 was announced in 2010 with its own multiprocess architecture (inspired by and improving on Chrome's).

Details here: https://trac.webkit.org/wiki/WebKit2

It looks like there are some good foundations there for building a shared runtime like Microsoft is doing with WebView2 Runtime (https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution).

The only downside is there is no browser built with WebKit running on Windows so I don't know how viable WebKit is for windows. But I guess people need to be able to test iOS browser apps so Windows needs to be able to run a proper WebKit.

Also, https://github.com/ultralight-ux/Ultralight is commercial WebKit-based librart that works cross-platform. So it definitely is doable.

JS + WebView2

WebView2 Web/native interop

WebView2 is designed to interop with C# and C++. Not JavaScript.

So WebView2 still needs its own "Electron"-style project if we want to use JS code for the logic in the "main process".

The WebView2 API is here:

• https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/overview-features-apis?tabs=dotnetcsharp
• https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2
• https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/javascript/
  • JS APIs available in the web-side script via window.chrome.webview

Seems like there are two main ones dealing with exposing native objects to the web-side code...

• AddHostObjectToScript
  • The objects are exposed as proxy objects (that use IPC in the background?)
• PostSharedBufferToScript
  • Exposes to the web-side an ArrayBuffer of shared memory with with host...I think.

Perhaps Bun Desktop could wrap WebView2 and expose+abstract these APIs in TypeScript from a Bun process.

The APIs would be abstracted so they work with WKWebView on macOS.

And potentially, things that are not possible in WKWebView like this shared buffer stuff could be patched, and a Bun Desktop Runtime could be shipped with the patched WKWebView.

When WebView2 releases for macOS, then this patch can be deprecated. Or perhaps there are cool macOS/Linux specific features that could be kept.

Electron's history with Chromium

https://www.electronjs.org/blog/electron-internals-building-chromium-as-a-library:

• They used to use CEF (Chromium Embedded Framework).
• The CEF API was too high-level and made it too tricky to integrate Node.js into webpages.
• The core browser interface was called the "Content Module" (i.e. the content/ directory of chromium)
• Building it would take 5+ hours, and block contributors.
• Decided to build as a shared lib and link into Electron
  • This project was called: libchromiumcontent.
  • brightray project wrapped libchromiumcontent for convenience

Incredible to see the hoops they jump through to use Chromium as a library...whereas WebKit has always been designed to be an embeddable control. The WebView control code was first added 2001/12/07, 4 months after the WebKit project was kicked off. This made sense for Apple because they built an OS, whereas Google did not.

[cztomsik]

I am using zig + webview in my project, the macos part was super-easy (except the SwiftUI compile/linking step, but maybe bun would be fine with objective-c which can be compiled & linked by zig) but the windows part was way trickier because of COM and you still need to distribute WebView2Loader.dll with your project.

Here's respective source-code if anyone want to take stab into that
https://github.com/cztomsik/ava/blob/main/src/windows/winmain.zig#L145
https://github.com/cztomsik/ava/blob/main/src/windows/com.zig

But as noted before, webview-based solution is very different from electron. I could afford that but there are many cases where you really need to have control, because different versions behave differently. BTW: even in my case, there's a (JS) bug only happening in macOS Monterey which I couldn't find easily so I left it for later.

[YoavCodes]

I really wanted this to exist so I've been cranking away at something I'm calling Electrobun over at https://github.com/blackboardsh/electrobun for the last month or so. I plan to spend at least the next two years building this and some related open source things.

Aiming for something like a rust-less Tauri (Bun + zig + system webview) with an option to bundle and include a cross-platform webview like CEF, where you as a developer only need to write typescript, with an easy to use typed RPC mechanism between bun and webviews.

Some project goals:

• use system webview by default to benefit from security updates, good for building browsers
• allow bundling a custom webview like CEF, good for shipping predictable renderers for local or remote app views you control.
• built-in code signing, notarization, bundling, and update mechanism
• updates should decouple bun runtime, custom webview, and app code, so you can ship changes to your app code and users just download what's changed. The example app's app code is < 200KB so changes that just involve app code would just download that. Bun runtime and cef version bumps would only download when those are changed.
• developers should just write typescript for both bun process and webview processes without having to think about it

Current build sizes:

• arm mac bundle for the example app zipped 18MB
• the bun runtime zipped 17MB
• the example bundle without the bun runtime zipped 200KB

Current status:

It's very early, I'm currently pushing directly to main but will switch to a more stable PR-based flow that's open to code contribution and more thorough documentation once the major churn and initial mechanisms like updating and intel-mac builds are working in a month or two. In the meantime if you want star, follow, join the discord, etc.

General architecture is implemented. It gives you a config file to describe typescript entrypoints for bun and each webview and copy other assets into the bundle to be exposed by a views:// scheme to webviews, bundles bun and webview typescript using bun build and constructs a macos bundle. Typescript apis for bun process and webviews. It uses objc statically linked into a zig process. The zig layer will provide cross platform native functionality wrapper for webview, system tray, etc. In dev mode it uses a bun single-file-executable cli both inside the bundle as a launcher and outside the macos bundle as a debug tool to stream logs and provide future advanced debugging abilities. in canary and stable builds of your app it uses a smol zig launcher in the bundle instead. It uses typescript typed RPC to communicate between bun and webviews and bun and zig. I've implemented typed rpc in zig for under-the-hood bun <-> zig rpc with a promise-like behaviour to power exposing things like a will-navigate handler (where under the hood an objc handler needs to "wait" for bun javascript response to allow/cancel navigation) where all you do is add a listener on the bun typescript side and it just works. On the zig side the main thread efficiently sleeps until there's a response, on the bun side there's a custom event emitter and event system for returning a value across global and webview specific will-navigate listeners, overriding previous handler's responses, etc.

Example app

Currently the example in the repo opens two windows.

1. first window to a random wikipedia page with an example preload script written in typescript, using the electrobun webview api to implement RPC with bun, and bundled by the electrobun cli, served over a custom scheme from the app bundle, bun rpc asks the webview to get the title of the page and the bun process console.logs the result.
2. the other window loads a local html file (the html has a script tag that loads a js file that was written as ts bundled with electrobun cli/bun and served over custom scheme from app bundle), they rpc ask eachother to do math and return the result. The windows also have a navigation handler written in bun typescript.

up next:

• code signing and notarization (in-progress)
• update mechanism (in-progress)
• builds for intel macs
• optionally use cef instead of system webview
• start building out the api to get closer to tauri/electron parity
• linux builds (if/when people ask)
• windows builds (once bun itself runs on windows and is stabilized a bit)

[amritk]

This is awesome!

[KaKi87]

linux builds (if/when people ask)

I am hereby doing so. :)

Thanks !

[YoavCodes]

I am hereby doing so. :)

👍 blackboardsh/electrobun#4

[vjpr]

Awesome! This definitely needs to exist.

The zig layer will provide cross platform native functionality wrapper

I would really like to have a Zig equivalent of Rust/Tauri's https://github.com/tauri-apps/wry (webview wrapper) and https://github.com/tauri-apps/tao (windowing) as separate packages.

[hisbvdis]

I will be waiting for Windows builds.
I are doing a great job