▲ 172 points
back
105 comments
> Ultralight is free for non-commercial use, educational use, and also free for commercial use by small indie developers making less than US$100,000 a year.
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.
Ultralight dev here-- I've been on the dev-tool side of this equation for the past 13 years so I have insight into why people are actually using HTML/JS/CSS over proprietary UI tech on the desktop.
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.
I was skeptical but curious that this tool might be a good candidate for some of my problems where a web app doesn’t quite work (commissioning robots at locales without Internet).
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.
Nah, we ended up with Electron because we have more front-end devs than C++/C#/ObjC devs and because doing layout in HTML + CSS is a million times easier than in native frameworks (AppKit and UIKit aside, those are nice).
It being cross-platform is probably secondary.
If you’d asked me a couple years ago my bet would’ve been on Microsoft’s fork of React Native for desktop. They’re clearly actively developing it and using it for their own purposes. But its relative obscurity isn’t a great sign.
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.
> 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 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.
I work at a university/research lab. We always fall between the chairs with those licencing rules, although we are non-profit. Also if you add 9000 ppl you easily pass 100k. Same with Docker Desktop btw. I guess there are so many more cases also outside of large enterprises are hesitant to use software with complicated licenses.
Add to it that contrary to every other profession, ours is full with people that refuse to pay for the tools on their toolbox.
So they get the tools that are available on the flea market, one gets what they are willing to pay for.
Electron wins because it allows a single language to do what java failed: write on e, run everywhere.
These days I’ve been absolutely impressed with Tauri:
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
I am very confused as to why you are discussing a completely unrelated piece of software without even mentioning the software this post is about?
The list of missing features [1] makes it clear that this is unusable for any realistic desktop app. No local file selection, no platform drag-and-drop… no CSS filters for UI effects, even. Nowhere near production ready.
Ultralight dev here-- most work has gone into porting Ultralight to various platforms (game consoles and ARM64) the past 2 years. The main focus is less to replace Electron and more to get modern HTML/JS/CSS running everywhere.
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).
While I'm always excited to see Electron alternatives, they all try to address the same issues and fall short on the exact same areas.
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.
Nw.js has so far had everything I needed in terms of features, but their packaging story seems 4 years out of date.
I just want to build native installers for all platforms :/
What are the features that you find Tauri lacks?
Please keep in mind that this is based on Ultralight wich is not open source and kind of abandoned. Been a commercial customer before, promised arm version never shipped. UL worked well but the lack of support/development means I will never use it again.
Apparently the same happened with the previous project of the author too: https://news.ycombinator.com/item?id=24304043
Ultralight is definitely not abandoned, 1.3-beta will be released end of this week (nightly builds have been available for the past year) and ARM64 support will be available in the 1.4-dev branch later this year.
Feel free to contact me at adam {at} ultralig.ht if you need support or want a refund.
This is good to know. Thank you.
Commenting on the name ... technically, a muon is (like) a heavy electron ...
Funny inconsistency indeed. Muon is ~206 times heavier than electron... and it is also unstable :)
So the lightweight electron alternative is a more massive electron...
Super heavy electron hmmm
Be aware that Muon depends upon a nonfree WebKit replacement.
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.
Ultralight dev here-- I remember the KDE days too and have released a fair amount of my software free and open-source.
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.
We raced to comment on this. I'm not even sure licensing the project as MIT is even relevant given the non-free dependency. Doesn't make much legal or practical sense.
There seems to be a fair amount of missing features too
While at it: can somebody please tell me what makes the modern Web so heavyweight? Why is my Firefox process consuming so many hundreds of megs? Why GMail can peg a whole CPU core?
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?
Why do you consider Telegram heavy, if it takes 400MB of memory? Isn't memory there to be used? I just checked my telegram client, and it takes up 600MB of memory, but the system has almost 4GB of free memory. Why should telegram limit itself to using only, lets say, 50MB of memory, if there is much more available?
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.
hmmm, just opened Strawberry in Heaptrack. Here it uses 46 megabytes at most. 20 megabytes of those are icons it seems, and 5 megabytes seem to be some kerfuffle with Qt's stylesheets which don't seem to be super optimized (although I wouldn't be surprised if it's image loading here too).
These Github-based branding exercises leave a bad taste in my mouth.
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.
I completely agree. This should be called:
"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.
At this point, whenever I see an "electron replacement" I look for discussion of accessibility.
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.
The last update seems to have happened in 2019, unfortunately.
Indeed, and as mentioned in this thread, Tauri seems a better alternative:
This is also true of some other solutions, but with regards to it as an alternative to Electron, remember to be careful with licensing. While many open source licenses are compatible in one direction, Ultralight is commercial software, and thus it is incompatible with a lot of copyleft licenses. (Disclaimer: IANAL.)
The name is unfortunate.
A muon is about 200 times heavier than an electron, not lighter.
the majority of people don't know this, or care in a context that influences them using this or not. you'll have to make a choice whether to stop bothering yourself.
For those who are wondering, Ultralight (the browser engine backend here) is a fork of WPE - https://webkit.org/wpe/ - a webkit port for embedded, low powered devices. More details here - https://wpewebkit.org/ ...
Definitely not a fork of WPE (which is primarily tied to *nix), Ultralight is built on a platform-agnostic fork of WebCore/JavaScriptCore I started back in 2015.
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).
I'm mostly asking this question out of ignorance, so forgive me. But I'm a web dev and it's always been my understanding that browsers mostly use the CPU to render CSS, only utilizing the GPU in certain scenarios. Is Muon stating that they're entirely leveraging the GPU? If so that sounds super interesting.
Yes-- Ultralight (the renderer underneath) has two modes: pure-CPU or pure-GPU. The GPU renderer does all drawing on the GPU using tesselated path geometry and pixel shaders.
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
For anyone evaluating electron alternatives you might also check out Wails[1] which similarly gives you Go<->JS/TS interop.
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/
I still don't understand why these projects have to include a browser at all. Don't all five major operating systems (MacOS, Windows, Linux, IOS, and Android) have builtin webviews available?
I'm confused why this is a topic of discussion - the repo hasn't been updated in 3 years.
How does this compare against CEF/WebKit/Electron or any other browser security wise?
The project has an MIT license, but its main dependency is proprietary garbage: