Muon: GPU Based Electron on a Diet
github.com
github.com
I feel like the reason we have ended up with Electron is that well-funded developments from large companies (like WPF, SwiftUI) always seek to lock-in developers to their single platform, well-funded from independent ones (like Qt) cost $$, and the rest just stays permanently underdeveloped from lacking dev resources.
The result is that the lowest common denominator wins: free and standardized web tech, repackaged as desktop apps. I haven't seen any older desktop UI developer who'd like Electron, yet I bet every one of us has at least a couple of Electron apps installed as they're reading this.
Let me ask this question: what is the luckiest, ideal scenario for a project with such license, if it takes off and everyone loves it and everything goes well? Probably displacing Qt and taking over their market share? That doesn't sound anywhere close to Electron killer potential to me.
But once I got to the “this isn’t FOSS, here’s a pricing structure” I sighed and closed the tab.
I don’t dislike Electron the way some do. But I always prefer better tools if they’re available. Unfortunately this ain’t it.
It being cross-platform is probably secondary.
I've found it easier just to do declarative layout. Tcl/Tk does this real well, and has since the early/mid 90s. I know that Tk uses imperative commands to build out the UI scene graph but it's effectively declarative. Tcl/Tk is pretty much VB done Unix style.
Before consulting I did web dev in early 2000s when the stack was LAMP and JavaScript felt like something that would never mature into anything. Hell, I was in my late teens so the feeling was likely mutual.
All this to say, good god, autolayout and storyboards and stack views. Last Friday I spent TWO HOURS troubleshooting why a UILabel wouldn’t word wrap inside two UIStackViews.
I’m so grateful for electron. It’s allowed me to become an indie dev and embrace/leverage react and the entire JS ecosystem to bootstrap a successful company.
My indie success would never have been possible if it wasn’t for these “inefficient” dev/deployment desktop stacks. And if they allow lowly old me to sell software to thousands of users around the world then they are doing something right. I hate to say it, but they really allow me to be 10x of what I’d be solo on mobile. Electron/React has that much potential when focused on solving a few painful tasks for my end users.
Just want to say thanks for this gem ;)
I agree with your comment, except here: Doing layout in GTK is much easier than using HTML. Especially using Blueprint[0] you don't even have to touch .ui files. And constructing the GUI using code is possible, too.
At least the few things I did in HTML were a lot more difficult than they would have been in GTK.
Nonsense. Doing layout in Qt is much, much nicer than HTML/CSS. If you could just push a button and get executables for all the major platforms, by default, like you can with Electron, it would be winning.
To make an electron app, you only care about that your chrome runtime support.
WPF is well, windows only. QML is C++ or python and didn't look native at all, but it also didn't look very pretty either. With HTML + CSS you can easily make an eye candy.
Luckiest ideal scenario: something like React Native that really does compile to actual UI APIs for the compile target. Doesn’t have to be JavaScript, but it probably will be because inertia.
Every time I see “native” and “UI” RN is still the only real option which means native. I’d really love to see more options in this space.
About Flutter, I've never personally used it but last I read its marketshare was continuing to grow fast as RN's plateaued. I love TS and the react ecosystem but RN itself is so crappy that I'm considering dart (did I just say that???). I think architecturally Flutter made the right call to just implement their own components on skia to get perfect consistency across platforms and totally control their own destiny. Sadly they also chose a weird shitty language.
It's several things-- tons of mature web development frameworks and ecosystems (React, Angular, et al), tons of developers with experience creating and maintaining them, and tons of debugging and support resources (Chrome Dev Tools, Stack Overflow, etc.).
Very difficult to compete against a content creation pipeline like that-- hence why I've made it my mission to get modern HTML UI running performantly everywhere without requiring web developers to learn some new language or toolset.
Also, FWIW, Ultralight does allow you to mix both HTML and native UI (the library can paint offscreen) so you can choose where/when to use each in your app.
Ultralight is not WebKit (we have a totally different API and use our own renderer, compositor, and event-management code) but we do use a fork of WebCore and JavaScriptCore.
Our fork of WebCore is available under LGPL here: https://github.com/ultralight-ux/WebCore
The steps WebKit have made the last few years have been incredible and your further parallelization and optimization work would be so slick, can’t wait to try it out.
I’d love to use it with Tamagui and Vite running all bundling for RN. Silky smooth desktop app, web apps, sites, and mobile apps all easy to design together and deploy nicely to their respective platforms.
For sure, feel free to hit me up on Discord if you want to chat.
This is sort of where I am, and a lot of people are doing similar explorations, in developing custom GUIs inside the browser that leverage WASM for high performance graphics. I'm using a hybrid bespoke GLSL translations and raw pixel manipulated bitmaps to Canvas2D, eventually targeting a custom webgpu renderer. Main issue is simply browser fragmentation. And, of course, ever larger data visualizations!
The latter half of your comment asks some good questions, but I don't buy this initial assumption. As in: "The reason we have Electron is <truth>, <truth> and <unsubstantiated>" and then the rest of your comment is based on the 3rd part.
I don't think that's why we have Electron either way - the reasons for that are much broader & more complex but two large components of it are (a) the proliferation of web-technology due to the incredible success of the open web & (b) the overall development story of KHTML->WebKit->Blink prioritising their embedding API.
So they get the tools that are available on the flea market, one gets what they are willing to pay for.
ToolHub would need at very least to pay electricity and materials for their replicator devices, and when the bill becomes too high, the shop would close doors.
This is more about a critical piece that you want to be always, universally available and known through and through. Choosing a non-FOSS option for a critical piece is now rare, and only works for things which were on the market for ages, and are guaranteed to not go away, such as MS Excel.
https://github.com/tauri-apps/tauri
The documentation needed a little bit of work last time I looked but they’ve made so much progress in such a small amount of time.
Also having Rust underneath it all is a huge plus
Some more:
Their comment has a link to the Tauri GitHub repo.
The desktop layer (AppCore) is indeed missing some support but I have some cycles allotted to finish them in the next dev branch (1.4).
Yes, Electron eats a lot of resources and generates big distributables. I would love to give my users snappier and lighter desktop applications while still being able to build them with front-end web tech. On the other hand, what keeps attracting me to Electron is how feature complete and well documented it is. I tried many alternatives but there is always a point where I can't do something because the API is missing.
I wish all Electron alternatives would join their efforts to make one good framework that can compete, not only in terms of performance, but features too.
So far, I've been working with Tauri[0] for a small project and found it to be working really well despite missing a few features that I needed (and that Electron has). I have high hopes that Tauri will become the best Electron alternative out there and to use it for all my future desktop projects.
I just want to build native installers for all platforms :/
Apparently the same happened with the previous project of the author too: https://news.ycombinator.com/item?id=24304043
Feel free to contact me at adam {at} ultralig.ht if you need support or want a refund.
As someone who remembers when KDE 1.0 dropped, based on Qt which was nonfree at the time, and the crapstorm that caused, that stimulates some old and unpleasant tingling feelings.
Of course this one is a little bit more grey-area because it seems that it is easy to get free individual licenses for this code.
But if you have the legal right to run a proprietary OS the of course you can run open-source apps on it. Similarly if you acquire somehow the legal right to run Ultralight then you can legally run Muon.
For sure, it is definitely legal. Sorry, I used "grey area" in my previous comment which is basically incorrect because "legal grey area" is a really common expression. I'm just thinking it is less useful. Like hypothetically in the absurd case you could release an open source project that is:
#include "proprietary_library.h"
int main()
{
run_proprietary_code();
}
which is open source but who cares, right?
In this specific case, if Muon distributed a copy of Ultralight (which it doesn't seem to; I'm not sure why I'm spending so much time on this), the it could not be GPL'ed, for example, because Ultralight has a proprietary (incompatible) license [2]. For a license like MIT or BSD, I think applying that license is technically valid, but again, not very practical. I doubt Muon would make it into the OpenBSD repos, for example. Its distribution is hindered by the depedency.
Basically, "open source" doesn't really mean anything in this context; you need to consider specific licenses and circumstances.
[1] https://github.com/ImVexed/muon/tree/master/ultralight
[2] https://github.com/ultralight-ux/Ultralight/blob/master/lice...
I had indeed contemplated making Ultralight fully LGPL and charging for support but decided that the incentives really didn't align with making a quality product (quite the opposite-- there would be some motivation to make the product difficult to use to increase revenue which is not something I would ever want to do).
The current license (free for most, but a license is needed past a certain revenue threshold) is my best compromise at making the software free and accessible while still making sure I can keep the lights on and ensure the product continues to be developed into the future.
If you have any concerns about licensing you can always hit me up in our Discord.
Apparently Qt is not significantly better: a Telegram client consumes about 400 MB, and a Qt-based music player Strawberry, about 100 MB.
I can imagine that GPU-based compositing can consume a lot of RAM for the textures used in rendering, but frankly an entire 4K screen at 32bpp is less than 32 MB, while both Telegram and Strawberry take up a small portion of it.
Or, from another angle: can a modern GUI be made to consume little RAM while remaining performant and using a GPU for rendering on larger / high-DPI surfaces?
I just started telegram inside a Windows 10 VM, to check if Telegram actually needs that much memory. In my VM with 1024MB of RAM, the Telegram client uses only around 45MB. If the system gets 2048MB of RAM, Telegram will use around 160MB, if available. The client still works fine. Probably a lot slower, but it works fine.
I think your comment is misguided. The Telegram client is not heavy-weight. It just uses the ressources you machine provides it, giving you better performance.
This is nothing more than a third-party (nonfree) browser engine embedded in a basic event loop, with a catchy name, and a pretty logo.
A more accurate description would be that these are Go bindings for Ultralight.
"Project Template for Ultralight in Go"
It looks like the 300LoC simply wrap around ultralight and add a few boilerplate pieces. All the hard work of making "a lightweight alternative to Electron" is done by Ultralight, not whatever this repo is.
I haven't heard of Ultralight until 5 minutes ago, but it annoys me when some developers think they can build a tiny react app project template and then claim they created react. Or in this case, add a tiny wrapper around Ultralight and then claim they created a "lightweight alternative to electron". This repo doesn't do that.
Without fail, the answer is always "Well yes, we haven't done it yet, but we will do it soon, honest!". Weirdly, it never seems to get done.
A muon is about 200 times heavier than an electron, not lighter.
The goal is actually more ambitious than WPE since we run on every platform and in environments where embedders may provide custom platform functionality (such as games).
All painting is actually emitted as virtual GPU draw calls, interface is here: https://github.com/ultralight-ux/Ultralight-API/blob/master/...
Platform-specific implementations (D3D11 / D3D12 / Metal / OpenGL) are provided in the AppCore repo: https://github.com/ultralight-ux/AppCore
Real-time SDFs on the GPU still have a definite advantage when it comes to performing strokes, fills, glows, pseudo-blurs and other complex effects in a fill shader but older hardware (especially older integrated graphics) had unacceptable performance when evaluating the bezier.
The alternative is to cache the SDF (precompute on CPU or GPU then upload to VRAM) but then you start running into memory bandwidth and texture memory concerns.
I may still bring it back and lock it to certain hardware but I think we are still a generation or two away from using / abusing shaders for vector paths.
I should also mention that I spent the last two years rewriting our CPU renderer which now has pretty amazing performance across a wide range of hardware (no GPU required, can run it on a headless server or other device). I started by forking Skia’s core rasterizer and wrote a parallel dispatch layer on top (CPU core counts keep increasing so we can start treating them like GPUs for certain ops, see Intel ISPC).
Not sure how it compares to this project, but I've enjoyed working with auto-generated TS types to interact with a Go backend.
[1]: https://wails.io/
Maybe they just share every interesting codebase they find.