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.
> 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.
> 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.
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.
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.
> 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.
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.
* 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.
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.
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 :-)
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:
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.
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) :
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.
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".
> 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.
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.
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.
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).
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.
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.
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.
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.
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
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.
Readit News
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.
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.
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.
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.
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
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.
Not to mention that WebGUIs are slow compared to native ones.
https://news.ycombinator.com/item?id=36446933
* 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.
Dead Comment
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
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.
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) :
cannot find my browser.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.
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.
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.
Uh, stdlib and friends? No?
This link is a better representation of the project as a whole: https://github.com/webui-dev/webui
Pretty cool
WebUI is language agnostic so I guess Tauri but not limited to Rust would be a better description.
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.
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.
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
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.