Web browser as GUI, with your preferred language in the backend

[lewisjoe]

This is definitely the way to go! The browser is not only good at network requests and sandboxing but comes with the most powerful layouting system and rendering engine.

So yes, leveraging browsers just for the front-end of a local-first app is such a good direction to go. Generally apps tend to bundle their own browser runtime to leverage this component. Even the lighter weight electron alternatives tend to either implement a part of the browser runtime themselves or at least need separate webview instances. But I already have a browser installed and why can't my local apps integrate with my installed browser to expose their functionality? This project looks like a good step into that direction.

[flohofwoe]

> but comes with the most powerful layouting system and rendering engine

If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM. The DOM was originally created to render static text-heavy documents, baking such a limited document-layout system into browsers was a mistake in hindsight. These days, the DOM should be "just another" on-demand loaded Javascript UI framework sitting on top of a handful lower level rendering APIs.

[keepamovin]

This is very polished and cool-looking. Inspiring. I find this project's level of polish very inspiring.

It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago: nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs

And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS Paint" on 3 platforms, haha.

Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool.

0: https://github.com/00000o1/jspaint.exe

[troupo]

> but comes with the most powerful layouting system and rendering engine.

It's not powerful by any stretch of imagination. If anything, it's the worlds most inefficient layouting and rendering system struggling to render anything beyond the most primitive things.

[croes]

Good luck running you GUI from know in a browser in ten years or maybe even five.

Not to mention that WebGUIs are slow compared to native ones.

https://news.ycombinator.com/item?id=36446933

[samstave]

It will be interesting if one could have one's webapp also be able to accept browser extensions as add-ons to functionality to the app - such that users can create their own 'packages' for your webapp just as anyone would do browser extensions? or does this sound stupid (obviously the biggest risk here is malevolent extensions (dont make medical apps out of this :-)

[huijzer]

SABnzbd agrees since 2016.

[cortesoft]

This is how Plex works

[lucasyvas]

I don't understand how this is materially better than Tauri (more generally, frameworks that bind to the platform webview).

At least with the platform webview, you can:

1. Have some knowledge about what engine versions were available on what OS versions and make compatibility decisions accordingly.

2. Know that the browser engine is always there.

When it comes to trade-offs between "static linking" (Electron) and "dynamic linking" (Tauri), this is like cowboy linking. You have literally no idea what browser will open. I guess this isn't materially different from a remotely hosted backend but I still wonder of the merits.

And why communicate over a websocket, or not have a custom protocol that you can handle and register with the OS more easily? I like the general idea but this seems inferior to a webview in almost every way.

I do see how you might get things like extensions easier, but I'd rather petition the platforms to add extension support and close other gaps directly in their webview runtimes.

And is it just localhost under the hood? If so it reminds me of this Zoom security debacle a few years ago:

https://archive.ph/3fxFS

[thisislife2]

Since I had a similar idea to build something like this, here's my opinion of the pros of this concept:

1. We web developers should always be building to a common specification, and not to the quirks of a particular web engine (which now includes webview quirks too).

2. Javascript is a shitty language. There are other better languages for application development, which allow you harness the full power of the OS platform.

3. It's more in line with unix philosophy - Write programs that do one thing and do it well, write programs to work together and write programs to handle text streams, because that is a universal interface.

4. If an application is built with point 3 in mind, a lot of old codes can be reused and / or given a new UI with this concept.

5. Really tiny as it doesn't increase the size of the application code base by much.

[sdkgames]

If I understand correctly, it's WebSocket on top of Embedded C/C++ web server (civetweb).

Also, the application must find and launch the installed browser. In my opinion, this part is very fragile. On my system, this function (webui/src/webui.c) :

   static bool _webui_browser_exist(_webui_window_t * win, size_t browser);

cannot find my browser.

[keepamovin]

Agree finding browsers can be tricky, but the node Chrome-launcher package has a fairly good approach that you can patch and extend to the other vendors.

In graderjs i solve this by searching for the installed browser, and then prompting the user to download it —obviously just the first time! — if we couldn’t find it. so the download and install happens as part of the application start up process and it’s baked into the framework. I think it’s a nice solution where the application installs any components that might need.

I think another nice solution would be to use playwright because that usually downloads all browsers that you might want and I’m sure that can be customized. playwright is a reliable source and it’ll put them in a location that easy to find.

[TheRealPomax]

Do you have "open URLs with a browswer" turned off in your OS? Because that's the universal way to open "whatever the user has set as their default browser".

[synergy20]

civetweb will run cross platform as a http server.

the issue is when you need write code on each OS, e.g. a cgi for windows/macos/linux/bsd, you will have to know the native API for each OS and use them, which could be hard to maintain if cross-platform is a must.

I wish there is something lower level that is truly cross platform, e.g. a C library runs on each OS and let me do filesystem/network/etc, it does not seem exist.

[ahmedfromtunis]

Zig is just one of the many backend languages this project supports.

This link is a better representation of the project as a whole: https://github.com/webui-dev/webui

[dang]

Ok, let's change the URL to that from https://github.com/webui-dev/zig-webui above. Thanks!

[Xeamek]

Is this basically Tauri, but with zig instead of Rust? Or are there some bigger, inherent differences? (Besides tauri being more mature, that is).

Pretty cool

[petabyt]

Very different. Tauri directly embeds/links to the web view runtime, and calls the APIs directly to setup the window. WebUI finds a browser installed or already running, and launches it to a localhost server hosting custom content.

[ksec]

>Is this basically Tauri, but with zig instead of Rust?

WebUI is language agnostic so I guess Tauri but not limited to Rust would be a better description.

[diggan]

Kind of but also not. Tauri uses the default on the platform it runs on, this zig-webui project seems to be able to use every major browser and every major platform. For example, Firefox, Chrome and Edge all seem to be available for Windows, Linux and macOS in zig-webui, while Tauri would use a specific engine for a specific platform (by default at least).

[troupo]

Offtopic, but: why do people insist that Edge is a meaningfully different browser from Chrome?

I'm not even going to ask about the table at the end that lists that it supports exactly two different browsers while listing 10.

[beardyw]

I would have thought at the browser level access to WebUI would not necessarily be a given as it seems that access is outside the browser engine. Glad to be corrected.

[chrisco255]

This is a good point. The only reason I can think of is that it is the default browser installed on Windows, which gives it automatic distribution.

[lolinder]

In this case it's relevant because it means that your app will run on Windows even if the user hasn't installed anything else, since it can just pick up Edge.

[pjmlp]

Mostly because what it does differently besides the rendering engine, but yeah it is still Chrome.

[c-hendricks]

I'm seeing lots of comparisons to Tauri, which is exciting because while I am using Tauri to build an app, I'm not actually that enthusiastic about Rust.

But I'm feeling a lot of comparisons are really just comparing the most straight forward, load HTML + JS in a webview, without comparing other things like:

- (Auto) Updating.

- Embedding other files (and actually distribute them).

- Plugins (I guess plugins can be made for the various language bindings and implemented via event handlers).

- Disabling Edge's annoyances (IE it looks like Edge's menu that shows up when selecting text is happening, I guess its image hover thing is there, and maybe more annoyances).

- The menu on macOS is the menu of the launched browser.

This does definitely seem to have its uses and I'll keep an eye on it.

[petabyt]

Side note, embedding files for distribution is definitely possible, just takes a little bit of work. I sent in a PR a few months ago to make it possible.

[p_l]

Reminds me of the approach of CLOG (Common Lisp Omnificent Gui[1]) and its ancestor GNOGA (The GNU Omnificent GUI for Ada[2]).

They also integrate basic components and even graphical UI editor (at least for CLOG), so you can essentially develop the whole thing from inside CL or Ada

[1] https://github.com/rabbibotton/clog

[2] https://github.com/alire-project/gnoga

[gneuromante]

The active development of GNOGA occurs in https://github.com/Blady-Com/gnoga

Don't know the relation to the official repository, which might still be: https://sourceforge.net/projects/gnoga/ but Blady-Com is the current most active developer in both.

[forgotpwd16]

Project is part of the overall WebUI project making such bindings for a number of languages. Site* gives an example in C.

*Which by the way needs a cert update.

[sph]

Off topic rant: can anyone explain why the syntax highlighting of Zig on Github turns every single word brown? I know they incorporated tree sitter, and for some reason the default syntax rules really dislike coloring identifiers in black.

Look at the code example in this project README or its source.

For a long time something bugged me about the language whenever I glanced at it, and it's all because Github and its stupid syntax coloring. I hate the rainbow vomit approach to syntax highlighting that's all the vogue these days. It should be a sprinkle on top, not the main course.

[petabyt]

I did a basic C demo where I compared this to Tauri/webview: https://github.com/petabyt/webui-demo I'm not planning to make any apps in HTML/CSS, but if I had to, WebUI would be my choice.

[TheRealPomax]

It's not confidence-inspiring that https://webui.me throws security warnings. I'd want folks to make applications "that make applications" to take security a little more seriously.

[teleforce]

Wow, couple with WasmGC this cross-platform GUI approach can be the way to go for cloud enabled local-first application [1][2].

Personally will love to see D language supporting these two features since the fact that D has GC by default and still does not has a polished cross-platform GUI framework.

[1] WasmGC – Run GC languages such as Kotlin, Java in Chrome browser

https://news.ycombinator.com/item?id=38109020

[2] WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome

https://developer.chrome.com/blog/wasmgc/

[lloydjones]

FYI: The website (webui.me) has a TLS / certificate issue and can only be viewed in Chrome (iPhone) after accepting the unsafe warning.

[schemescape]

Is there a document describing the architecture and security model?

Edit: There's an image that mentions WebSockets. Is it using the same one-time token approach to security as NeutralinoJS[1]?

[1] https://neutralino.js.org/docs/contributing/security/

[orenlindsey]

This seems like way too much work when people have been doing things like this in different ways for years (just look at Replit, it runs a full IDE and runs on 4gb Chromebooks).

Maybe I'm misunderstanding this project, but you don't have to reinvent the wheel.

[Fire-Dragon-DoL]

This seems amazing, there is another similar project called tauri but it uses webgtk, which has its rough edges. Something integrated in the user preferred browser sounds amazing.

Is there any plan for mobile?

Does it open the user default browser with all extensions loaded?

[o11c]

"Your preferred language" except for the frontend-touching parts you have to write in JS yourself, of course.

UI really can't be moved entirely to the backend.

[thecodewindow]

I guess you forgot the project name, "WEB - UI", So, non-web developers (HTML/CSS/JS) should not use this library or WebView based libraries either.

[stjohnswarts]

web assembly?

[apatheticonion]

I wish that Apple and Microsoft would work together towards making it easier for people to make cross platform desktop applications.

It's largely uneconomical for most companies to develop and maintain separate apps using two different teams with minimally interchangeable skills.

Tools like Electron are, essentially, not a choice

I also wish that wasm would come sooner so we could have more memory and CPU efficient (threaded, statically compiled) web applications (for apps like Slack, messengers, Jira and so forth).

I know people keep saying "wasm is not a replacement for JavaScript" - but perhaps it could be an alternative. I know I'd like to write a web application in Rust but as it stands now there is little advantage to that, particularly without threads and DOM access.

[armchairhacker]

We have good cross-platform desktop UI solutions: Java Swing/JavaFX, C++ GTK/Qt/wxWidgets, Rust egui/iced/Slint, and of course HTML/CSS/JS Electron/Sciter.

The problem is that cross-platform UI will never look as well as native UI because it’s not native UI: control sizes are different, colors and elements don’t blend the same way, and some things (like menu bars) are completely different in mac, Windows, and Linux. It’s not a slowness issue (if your UI isn’t responsive on today’s computers, you’re doing something very wrong), it’s not a usability issue, it’s not even an appearance issue (even Java UI can be made to look OK fairly easily in embedded systems). It’s an “I’m accustomed to native UIs and everything else is native UI, so any non-native UI looks out of place” issue.

[nanaian]

Wasm threads via SharedArrayBuffer have been a thing for like 5 years. In Rust you can use wasm-bindgen-rayon, for instance. DOM access is and has always been easily achieved through imports. It's performant, too: https://youtu.be/4KtotxNAwME

[38]

> Tools like Electron are, essentially, not a choice

yeah, they really are. people seem to forget that you can simply start a local web server, and direct the user to visit http://localhost:8080. here is one in Go, literally 8 lines of code:

    package main
    import "net/http"
    func main() {
       http.HandleFunc("/", func(w http.ResponseWriter, _ *http.Request) {
          w.Write([]byte("hello world"))
       })
       http.ListenAndServe(":8080", nil)
    }

[hit8run]

Isn’t that what Flutter is solving?

[maybeezuuuyy]

Can't wait for someone to reinvent java applets or flash and we will have gone full circle.

[thecodewindow]

Microsoft WebView: Say that again?