First I've heard of WebUI, thanks. I had been looking at trying trying Tauri for an upcoming project - do you know about that and have any view on it? Interested in any opinions you have about tools in this space.
I hate to bash, but I would not recommend Tauri/webview to anybody. Here's my list of the problems:
- For Windows, it requires the MS WebView2 runtime to be installed. It's installed by default in Windows 11, but Windows 10 users will need to make sure it's installed. (not sure if there's an error popup or anything?) There's no chance of running Tauri apps on Windows 7.
- (For MacOS, it should work with no problems. NSWebView has been a thing for a very long time now.)
- For Linux, packaging is a nightmare. Since Linux has no standardized webview (or UI framework), Tauri Linux apps have to be distributed as .deb packages which users need to install with dpkg (They might support .rpms other formats now, not sure). New users installing Linux Tauri apps will most likely have to install WebKitGTK (and possibly some other deps) for the first time (around 70mb).
Either that or you can package your Tauri Linux app as an AppImage (I've seen a few Tauri apps do this), but that will include WebKitGTK in the final binary... and you end up with a binary that's on par or larger than Electron.
Also, back when I was playing with and contributing to webview I did some RAM usage tests, and WebKitGTK actually did worse than Electron. We did briefly look into Netsurf or a 'lite' version of WebKit but RAM usage ended up being the same, and WebKitGTK3 was too popular and easy to use for the devs to want to switch to anything else.
And finally for all platforms, you will probably be eating up a lot of RAM (and impacting launch times) by using WebView2/NSWebView/WebKitGTK, which is probably not the primary browser that most users use and have running and loaded into RAM. This should improve improve if you run more than 1 Tauri/electron app - but that seems unlikely to me.
WebUI doesn't solve all of these problems (users must have a compatible web browser installed) and has some quirks, but it mostly solves the RAM usage issue (checks for what browser is already loaded, starts a new instance) and compiles into very small .AppImage/.app/.exe applications as users would expect.
I would only recommend WebUI if you have a HTML/CSS/JS frontend that you absolutely can't depart with, or have some other scenario/limitation that forces you have to use a browser. Otherwise, it's so much better to just use a native framework :)
(As a side note, Tauri used to use webview as a backend, but eventually switched to a rewrite.)
These were some quirks / questions I was left with after playing around with it a few months ago, copied from a comment I made at the time:
- (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.
FWIW I maintain an app built with Tauri and generally really like it.
Together with wasm / js this can give you super lightweight 'electron-like' standalone apps in less than 2 MB. Used as such in in https://github.com/pannous/wasp/
Web servers aren't big! Browsers are huge but servers can be tiny.
I'm sure Caddy and nginx and the like are at least 2MB, but they have a lot of features. Googling around a bit for small web servers, I found this fun blog post: https://lipanski.com/posts/smallest-docker-image-static-webs... They ended up with a static web server in a 154KB Docker image.
Pet peeve: when people who haven't used Windows in 20 years write build instructions on Windows that still use the command prompt or just tell you to download MSYS or something
Let me tell you as someone who has used virtual machines, done native development, and used tools like WSL...MSYS is really nice in context.
It's not as fast as bare native, but it's leagues better than a virtual machine and plenty fast enough for daily work. It has lots of the latest tooling (just recently it updated to GCC14 a couple days after GCC14 released). It has all the nice toolchains set up with a simple pacman call instead of having to compile everything yourself or go to esoteric sources to get it installed.
Most importantly, it just works the vast majority of the time. I very rarely have to fix something because of an MSYS concern. Almost all of my time is spent actually developing.
(Although they are for different work: That is NOT true on WSL, where it feels like I spend weeks just trying to get it up and working for a few days of productive work)
Personally I'm not a fan of Unix tools. I prefer powershell to bash and I like the cmdlets from it better than gnu tools. I don't use WSL for anything.
I want more projects to have windows native instructions rather than copping out and using a kind of fake Unix environment
if you like the project enough you could contribute said instructions! it sounds like you're talking about largely linux based and linux developed projects that have still taken the time to translate their build steps into something that works on windows, whether or not it's the most windows native way of doing things.
What a hot take. Some of the latest MS stuff like Powershell is fine, and far better than it used to be.
But it just pales in comparison to the mountain of great tools, addons, plugins, packages and so on available in a Unix environment. I mean heck, what do you even do for something like clang-format?
> But it just pales in comparison to the mountain of great tools, addons, plugins, packages and so on available in a Unix environment
Visual Studio 2022 is a complete development environment that more than outdoes any Unix environment. Running, debugging, profiling, benchmarking, configuring ABI/warning options, VS 2022 has it all.
> what do you even do for something like clang-format
I've used Windows many times the last 20 years and i'd rather use MSYS2 to build a C/C++ program than MSVC as it allows me to use the exact same tools i'd prefer to use on Linux and macOS (...i don't really prefer to use macOS, but i can still use the same tools there too) than having Windows be its own special snowflake. And i find current MSVC incredibly bloated.
I see in other comments you mentioned Powershell and CMake and TBH these are two things i avoided whenever i used Windows. CMake is used too much to be able to avoid it on Linux (which is currently my main OS) but it is not a tool i'd use myself if i had the choice.
If i had to use a tool that generates build files, i'd rather use premake[0] as it is a self-contained binary with very simple Lua-based scripts (by default they look declarative but you can extend it as much as you want - i've even used a script to generate CMake files since these can be parsed by Qt Creator). The only downside is that on Unix systems it doesn't know concept of a shared library (can be "taught" with a custom script but it isn't something that is available out of the box).
What would you prefer? I think VS and friends are a whole lot more bloated and annoying to use. For reference I have been developing on both platforms for 20 years.
Cmake is pretty standard so windows users could just generate their own project files. But I mean not using .bat files or the command prompt like it's 2001. Powershell scripts are more common with Windows developers these days and is a far better syntax than batch files. But Visual Studio/MSBuild is the de facto way to compile code for MSVC (which the instructions use anyways, but bizarrely compiling the projects via CLI instead of MSBuild). The whole project just seems like it was written using 1990s build patterns. It doesn't even have a modern build system for linux, let alone windows
> The whole project just seems like it was written using 1990s build patterns. It doesn't even have a modern build system for linux, let alone windows
This project doesn't have a build system at all, nor should it: it is a single source file that you might add to your existing project and build using your build system... and even that source just includes the header, so presumably you wouldn't even do that and would just include the header from your existing code. It would be absolutely ridiculous for this header to have its own build system.
It's a wrapper. From the About at the top of the page: "Tiny cross-platform webview library for C/C++. Uses WebKit (GTK/Cocoa) and Edge WebView2 (Windows)."
It's totally fair to criticise it for being a horrible, ugly technique. But in terms of fragility, it's no worse than bundling the same DLL as a file along with your app.
(In fact, it's less fragile than a loose DLL, because you don't run the risk of your DLL failing to install/being moved/accidentally loading some other random version of the same DLL etc)
In case you're not just riffing: no, it's not statically linked.
The WebViewLoader.dll is embedded in the source code and then loaded into memory as if it was loaded via LoadLibrary() or by Windows .exe loader which loads referenced .dll automatically.
Granted, he re-implemented LoadLibrary() to load from memory, which can potentially break if Microsoft changes the details of how LoadLibrary() is implemented.
This is one of my pet peeves with Microsoft API design. LoadLibrary() only works with files from disk.
It should be implemented as a trivial wrapper around LoadLibraryFromMemory() but Microsoft didn't implement LoadLibraryFromMemory so we have to resort to re-implementing LoadLibrary when we want this very useful functionality.
I wrote this a year or two ago and have forgotten the details, but there was definitely some reason why you couldn't "just statically link" it, otherwise that's exactly what I would have done, and saved myself some hassle.
IIRC it was either because there wasn't support for it back then, or the static version didn't support older Windows versions, or somesuch Microsoft nonsense.
But for whatever reason it was, they strongly push people to use the DLL, and deploying DLLs in installers is a PITA, so...
That's about when they added the capability, yeah. They've dropped support for win 7/8, not sure if CHOC goes back that far.
I suppose this would break the "Nothing needs adding to your build system to use any of this stuff.", but that doesn't seem true now that Boost is a dependency for the server stuff.
