> 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).
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.
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.
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.
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.
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.
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).
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 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/ ...
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.
Most browsers render nearly everything with the GPU. Chrome and Firefox render most of the browser via Skia and Skia can render with many different native GPU APIs or fallback to software rendering. Safari renders via Core Graphics which is also GPU based.
It really depends on the CSS rule you are using. The majority of the older/simpler properties are traditionally tied to the CPU, but things like transform, filters, or any 3D effect will push you over into the GPU.
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?
[+] [-] hamstergene|3 years ago|reply
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.
[+] [-] adamjs|3 years ago|reply
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.
[+] [-] Waterluvian|3 years ago|reply
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.
[+] [-] 0x457|3 years ago|reply
It being cross-platform is probably secondary.
[+] [-] eyelidlessness|3 years ago|reply
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.
[+] [-] lucideer|3 years ago|reply
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.
[+] [-] riedel|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
So they get the tools that are available on the flea market, one gets what they are willing to pay for.
[+] [-] cyanydeez|3 years ago|reply
[+] [-] hardwaresofton|3 years ago|reply
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
[+] [-] creatable|3 years ago|reply
[+] [-] rafram|3 years ago|reply
[1] https://github.com/ultralight-ux/Ultralight/issues/178
[+] [-] adamjs|3 years ago|reply
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).
[+] [-] airtonix|3 years ago|reply
[deleted]
[+] [-] keraf|3 years ago|reply
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.
[0] https://tauri.app/
[+] [-] Aeolun|3 years ago|reply
I just want to build native installers for all platforms :/
[+] [-] parsadotsh|3 years ago|reply
[+] [-] halotrope|3 years ago|reply
Apparently the same happened with the previous project of the author too: https://news.ycombinator.com/item?id=24304043
[+] [-] adamjs|3 years ago|reply
Feel free to contact me at adam {at} ultralig.ht if you need support or want a refund.
[+] [-] seanw444|3 years ago|reply
[+] [-] hpcjoe|3 years ago|reply
[+] [-] nuccy|3 years ago|reply
[+] [-] bitwize|3 years ago|reply
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.
[+] [-] adamjs|3 years ago|reply
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.
[+] [-] yazzku|3 years ago|reply
[+] [-] trinovantes|3 years ago|reply
https://github.com/ultralight-ux/Ultralight/issues/178
[+] [-] nine_k|3 years ago|reply
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?
[+] [-] murermader|3 years ago|reply
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.
[+] [-] jcelerier|3 years ago|reply
[+] [-] torginus|3 years ago|reply
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.
[+] [-] CJefferson|3 years ago|reply
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.
[+] [-] mikaelsouza|3 years ago|reply
[+] [-] hbbio|3 years ago|reply
https://tauri.app/
[+] [-] jchw|3 years ago|reply
[+] [-] otikik|3 years ago|reply
A muon is about 200 times heavier than an electron, not lighter.
[+] [-] nominusllc|3 years ago|reply
[+] [-] webmobdev|3 years ago|reply
[+] [-] danielvaughn|3 years ago|reply
[+] [-] adamjs|3 years ago|reply
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
[+] [-] greggman3|3 years ago|reply
[+] [-] jmisavage|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] iansinnott|3 years ago|reply
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/
[+] [-] dreamcompiler|3 years ago|reply
[+] [-] borbulon|3 years ago|reply
[+] [-] devmor|3 years ago|reply
Maybe they just share every interesting codebase they find.
[+] [-] r1chardnl|3 years ago|reply