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

by rguiscard • 3 years ago

234 172 3 years ago

sph• 3 years ago

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.

naikrovek• 3 years ago

every single word

I’m not seeing that.

LoganDark• 3 years ago

A better name for the color would probably be orange, at least in dark theme. Look at... variable names, field accesses, basically literally everything that is not a keyword or symbol. It's not all supposed to be colored. There's no plain white text anywhere!

384• 3 years ago

yeah its awful. I fixed like this:

    /*
    ==userstyle==
    @name GitHub
    @namespace 3052
    @version 2023.10.27
    ==/userstyle==
    */
    @-moz-document domain("github.com") {
       .pl-v {
          color: var(--color-fg-default)
       }
    }

troupo14• 3 years ago

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.

chrisco255• 3 years ago

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.

beardyw• 3 years ago

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.

pjmlp4• 3 years ago

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

lolinder2• 3 years ago

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.

forgotpwd16• 3 years ago

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.

ahmedfromtunis• 3 years ago

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• 3 years ago

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

lewisjoe• 3 years ago

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.

troupo14• 3 years ago

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.

austin-cheney9• 3 years ago

I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The two big limitations from a pure processing perspective are the garbage collector and massive repaints of large data on large layouts.

flohofwoe• 3 years ago

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.

diggan5• 3 years ago

If that would be the case there wouldn't be the flurry of JS frameworks which try to "fix" the DOM

jQuery was a part of the generation that tried to "fix DOM manipulation" which browsers now have caught up to (hence you don't see jQuery as wildly used anymore).

The problem the frontend ecosystem is trying to address right now is the scale of architectures of code, and managing complicated state.

People don't chose JS framework depending on how they mutate/read the DOM, they chose JS framework depending on how it handles complexity around mutating state and that it gives them Good Enough patterns for managing bigger code bases.

Well, except when it's chosen by cargocult, which is probably most of the cases.

bobthepanda2• 3 years ago

The issue most javascript frameworks try to fix with the DOM is the fact that it is not a language and does not have very good templating support. (Even web components in their plain form are pretty bad; no one wants to write document.appendChild everywhere)

But no one has dethroned HTML and CSS as a fully baked cross platform engine, because it has been battle tested and optimized to death. And not really for lack of trying; UI is just actually very complicated.

immibis• 3 years ago

I thought flexbox solved this.

huijzer2• 3 years ago

SABnzbd agrees since 2016.

chrnola• 3 years ago

Hmmm I thought it ran its own web server instead.

samstave• 3 years ago

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 :-)

croes5• 3 years ago

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

zamadatix• 3 years ago

Browsers have extremely good backwards compatibility, five or ten years should really not net you any problems. They do carry quite a bit of bloat however, though so do most native toolkits these days.

bobthepanda2• 3 years ago

The problem with native has always been that

* Users expect consistency within their apps, and will complain loudly if platform A has something that platform B has not

* the native platforms’ rendering technologies are so different that you basically need a developer or team dedicated to each platform, with their own test infrastructure, etc.

* even if you can afford to do the above, herding four teams using different technologies to do a coordinated feature release schedule is like herding cats

In any case the native platforms hardly do much better. There are plenty of Windows, Mac, Android, iOS applications from ten years ago that don’t work well today, for instance.

keepamovin2• 3 years ago

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

cortesoft• 3 years ago

This is how Plex works

retrochameleon• 3 years ago

Wow I had no idea and I'm a web dev. Have they published about that anywhere?

Yaina• 3 years ago

Is it just me or does their logo look very similar to the Waterfox logo?

jnrk• 3 years ago

No you’re right. It’s the same logo with a color shift and droplets removed:

https://commons.wikimedia.org/wiki/File:Waterfox_logo_2019.p...

lolinder2• 3 years ago

Looks like it is—they started out with the same color scheme just without the splashes [0], then changed the colors when someone recognized it. From the thread it sounds like an honest mistake (though one that probably warranted stronger corrective action than just changing the colors). They seem to have assumed that everything on icons8 [1] was up for grabs, when in fact a lot of trademarks are on there.

[0] https://github.com/webui-dev/webui/issues/100#issuecomment-1...

[1] https://icons8.com/

shellcoders3• 3 years ago

This is funny =)

Xeamek13• 3 years ago

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

diggan5• 3 years ago

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).

twen_ty• 3 years ago

Tauri can use a separate browser runtime if required. The use default is a space saving mechanism.

ksec• 3 years ago

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.

petabyt4• 3 years ago

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.

lloydjones• 3 years ago

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

hdaz0017• 3 years ago

Cert expired -- Sunday, 24 December 2023 at 23:07:23

thecodewindow5• 3 years ago

It's working now!

sdkgames2• 3 years ago

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.

TheRealPomax2• 3 years ago

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".

Gys• 3 years ago

The default browser on MacOS is often safari, which is not supported (yet) according to the docs.

sdkgames2• 3 years ago

Do you have "open URLs with a browswer" turned off in your OS?

But the application works differently. It needs the browser in kiosk mode, which means it should be able to run the browser binary with specific arguments.

synergy202• 3 years ago

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.

fallat• 3 years ago

a C library runs on each OS and let me do filesystem/network/etc, it does not seem exist.

Uh, stdlib and friends? No?

keepamovin2• 3 years ago

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.

d3w4s93• 3 years ago

Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compatibility issues. Then you realize you cannot just rely on a random browser version on any platform and think a minimum wrapper works well. That's why Electron bundles a browser and people create applications targeting specific Electron versions.

synergy202• 3 years ago

very true, which is why Electronjs still prevails in practice.

In the meantime if your WEBUI is not complex, and you just use the common features that all browsers have, this approach might work fine.

Xeamek13• 3 years ago

I've never worked on big enough project to hit such issues.

Could you provide some examples?

Not that I doubt your claims, just curious

codelikeawolf4• 3 years ago

I can provide an example. I work on spaceflight mission planning software that runs in Electron. We're using a lot of cutting edge Web APIs like WebGPU, SharedWorker, OffscreenCanvas, and Atomics. There's no way we would be able to ship something that would reliably work cross-platform if we used the OS's webview or whichever browser they prefer.

There's other considerations as well. The biggest advantage Electron provides over other libs that use OS webview (e.g. Tauri) is I can use whichever newer features I want (e.g. CSS nesting) as long as they're supported by whichever version of Chrome Electron ships with.

That being said, I get why Electron gets a lot of hate. I've been developing Electron apps professionally for the last 4 years. I can't use VS Code because I'm _accutely_ aware that it's Electron. I think 80% of Electron apps in the wild should probably just run in the browser. If you don't need to do stuff like access the filesystem, spawn processes, or interact with the OS in a way that the browser doesn't provide, you should probably just stick with the web app.

Fire-Dragon-DoL2• 3 years ago

Most of electron apps have compatible website version.

A website has the same problem as non electron: the browser is always different, so this doesn't seem that dramatic as a downside

TheRealPomax2• 3 years ago

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.

shellcoders3• 3 years ago

Yesterday the website was down, now is up !!

thecodewindow5• 3 years ago

You never saw a website down before or what? :D

Fire-Dragon-DoL2• 3 years ago

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?

rco8786• 3 years ago

What am I missing here? Web browsers are already GUIs, and any backend with an api supports it.

windmark• 3 years ago

Reading the “How Does it Work?” section of the readme, I interpret it as WebUI being a way of embedding a web view into your existing program, being a sort of proxy for the existing browser of the system.

https://github.com/webui-dev/webui#how-does-it-work

samspenc• 3 years ago

Don't frameworks like Electron (and Tauri) already allow us to do this today?

I couldn't tell from their docs what makes their project unique compared to these existing and more popular solutions.

orenlindsey• 3 years ago

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.

maybeezuuuyy• 3 years ago

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

thecodewindow5• 3 years ago

Microsoft WebView: Say that again?

apatheticonion2• 3 years ago

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.

384• 3 years ago

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)
    }

blululu• 3 years ago

This is serious? Generally your app should aspire to having a better user experience than a low end phishing scam. Normal people really don't want to copy/paste a series of random looking computery numbers from one application into their web browser. At best it feels broken and more likely it feels like you are about to get hacked.

mgerullis• 3 years ago

Wow thanks, I really needed to see a hello world server example

hit8run• 3 years ago

Isn’t that what Flutter is solving?

nanaian• 3 years ago

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

apatheticonion2• 3 years ago

It's __doable__ but I can't yet in earnest recommend it for a serious project (outside of canvas controlled GUIs).

The SharedArrayBuffer implementation requires spawning the same wasm module multiple times and passing the SAB to each instance. This works but is no replacement for thread management by the module/process itself.

It also requires restrictive "Cross-Origin-Opener-Policy" and "Cross-Origin-Embedder-Policy" headers - making it largely impossible for applications with multiple subdomains (for instance apps that have their API on api.myapp.com, or assets on cdn.myapp.com). Not an easy change for an established enterprise application.

Glue code might be performant but I really just want to go

cargo build --target wasm

and

<script src="app.wasm" type="application/wasm"></script>

armchairhacker• 3 years ago

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.

mbirth• 3 years ago

This! I hate when an app's GUI is following Windows-principles (if at all) and the macOS version is basically the same with a macOS theme slapped on top of it.

About 10 years ago I've experimented with an early version of appcelerator Titanium for mobile app development. It was JavaScript but GUI rendering was transcoded to either Android-Java or Apple-ObjectiveC and the respective code was compiled natively (while running your main code via a JavaScript engine). With a bit of if-then-else you could make one app that compiled for both platforms and looked and felt native on both.

tsimionescu• 3 years ago

If that were the problem, then Electron wouldn't help in any way either. In fact, Electron is even less interested in platform conventions than something like Swing. There isn't even default styling that tries to copy MacOS/Windows that you can apply.

The bigger problem is actually desktop-mobile compatibility today. No one writes apps only for Windows and MacOS. You want an app that works on iOS, Android, Windows and MacOS, and typically on the web as well so people can occasionally access it from an unfamiliar computer. So, the only viable option unless you want to have 4 dedicated UI teams or so is to write it in the lowest common denominator of HTML/CSS/JS, and use Electron and WebView to distribute it.

To a very good approximation, no one whatsoever cares about platform look and feel. In fact, most people actively prefer if they're using an app for it to have the same look and feel across all systems where they use it, including the web.

squarefoot• 3 years ago

Technically interesting, but no thanks. Imagine a Firefox user downloading the latest LibreOffice and being greeted with the warning "Better run through Chrome", or writing a dashboard on a small embedded system, and the memory footprint goes like 20x because now you need a browser in between in place of native controls. The idea is interesting but there are so many caveats, and the industry is famous for choosing the simplest and cheapest development methods rather than the most efficient ones.

petabyt4• 3 years ago

This is a replacement for electron/tauri, and should be able to use much less RAM

petabyt4• 3 years ago

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.

hellsten• 3 years ago

The fact that the only thing WebUI needs is a web browser is a bit of a problem for me, so I decided to go with Tauri, which uses the system's webview, for my HTML-based application: https://github.com/christianhellsten/ollama-html-ui/

The biggest problem with HTML/CSS apps is that their look and feel are different from native GUIs. This is less of a problem for chat and document-based applications (Slack, Word, etc.), IMO. With Tauri, I can also customize the window and integrate native features to mitigate this. I'm not sure WebUI can do this.

schemescape• 3 years ago

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/

c-hendricks2• 3 years ago

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.

petabyt4• 3 years ago

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.

o11c• 3 years ago

"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.

stjohnswarts• 3 years ago

web assembly?

thecodewindow5• 3 years ago

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.

lucasyvas• 3 years ago

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• 3 years ago

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.

teleforce• 3 years ago

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/

winrid2• 3 years ago

So can I deploy a Django app with this with sqlite?

thecodewindow5• 3 years ago

Yes you can!

winrid2• 3 years ago

Nice, the Django ORM + https://www.django-unicorn.com/ makes for very quick prototyping of UIs.

p_l• 3 years ago

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• 3 years ago

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.

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

Related Stories