8 ms·

Muon: GPU Based Electron on a Diet

172 points by nateb2022 4y ago

CJefferson 4y ago
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.
mikaelsouza 4y ago
The last update seems to have happened in 2019, unfortunately.
- hbbio 4y ago
  Indeed, and as mentioned in this thread, Tauri seems a better alternative: https://tauri.app/ https://tauri.app/
bitwize 4y ago
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.
- yazzku 4y ago
  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.
  - hollerith 4y ago
    IANAL, but it makes perfect legal sense to me just like it is perfectly legal to run an open-source app on a proprietary OS.
    - bee_rider 4y ago
      I also ANAL, but is it really like running on a proprietary OS? It seems more like having a dependency on a non-free library. An open source program which requires, for example, DirectX is pretty severely hampered, right? 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.
      - hollerith 4y ago
        OK I admit that the analogy is not worthwhile on second thought. 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.
        bee_rider 4y ago
        > 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?
        yazzku 4y ago
        I do care, and in your example, it depends on what license the project uses and how "proprietary_library" is distributed. 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 https://github.com/ImVexed/muon/tree/master/ultralight [2] https://github.com/ultralight-ux/Ultralight/blob/master/license/LICENSE.txt https://github.com/ultralight-ux/Ultralight/blob/master/lice...
- trinovantes 4y ago
  There seems to be a fair amount of missing features too https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178
- adamjs 4y ago
  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.
hardwaresofton 4y ago
These days I’ve been absolutely impressed with Tauri: https://github.com/tauri-apps/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
- creatable 4y ago
  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?
  - warning26 4y ago
    Both are lightweight Electron alternatives, so it seems relevant.
  - hollerith 4y ago
    I wasn't confused: both softwares let you create a cross-platform desktop app using html, css and js.
  - hardwaresofton 4y ago
    As others have said, Tauri is exactly the same sort of tool, sorry if the mention of Rust threw you off! Some more: https://wails.app https://wails.app https://nwjs.io/ https://nwjs.io/
    - hiyer 4y ago
      I don't think it's the mention of rust so much as not providing context on what tauri is. Mentioning that it's an electron alternative would have cleared that up.
      - green_on_black 4y ago
        I would have assumed it was an Electron alternative or tooling for Electron. Either way, those kind of comments are quite annoying. Commenter didn't even click the link before replying with hostility.
yazzku 4y ago
The project has an MIT license, but its main dependency is proprietary garbage: https://ultralig.ht/#pricing https://ultralig.ht/#pricing
hamstergene 4y ago
> 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.
- Waterluvian 4y ago
  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.
  - icemelt8 4y ago
    [flagged]
    - AstralStorm 4y ago
      However most software developers prefer a well documented tool with support and user base. Heavily licensed software tends to lack the second part of this. Being able to fix bugs you hit on your own, if push comes to shove, helps too.
    - squarefoot 4y ago
      Oh please. Communism is no more since decades, except in some propaganda that sees it in everything they can't understand. Software doesn't necessarily have to be a boxed product you build and sell like a car or a pair of shoes; it can be a tool to build businesses around services (examples: Apache, MySQL, Node.js, etc), or to be integrated in other bigger products (example: the Linux kernel, Lua, etc). Not to mention that today, with personal data as a valuable asset, you can never fully trust software that goes online and is not Open Source.
deleted 4y ago
[deleted]
danielvaughn 4y ago
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.
- jmisavage 4y ago
  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.
- greggman3 4y ago
  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.
  - sanxiyn 4y ago
    Firefox now renders with WebRender, not Skia.
- adamjs 4y ago
  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/Ultralight/platform/GPUDriver.h 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 https://github.com/ultralight-ux/AppCore
  - Jasper_ 4y ago
    Tessellated path geometry? Have you stopped using the signed-distance field path implementation? If so, any reasons why or lessons learned?
hpcjoe 4y ago
Commenting on the name ... technically, a muon is (like) a heavy electron ...
- ohiovr 4y ago
  Super heavy electron hmmm
- gpderetta 4y ago
  So the lightweight electron alternative is a more massive electron...
- nuccy 4y ago
  Funny inconsistency indeed. Muon is ~206 times heavier than electron... and it is also unstable :)
jchw 4y ago
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.)
rafram 4y ago
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. [1] https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178
- adamjs 4y ago
  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).
  - mwcampbell 4y ago
    Any plans to work on accessibility (e.g. for blind people using screen readers)?
    - adamjs 4y ago
      Yes-- WebCore has an internal Accessibility API that I'm going to expose in 1.4 to be either handled by the embedder (so you can determine the best way to display / navigate that information) or handled by AppCore (we provide stock implementations of most of the platform API there).
- airtonix 4y ago
r1chardnl 4y ago
How does this compare against CEF/WebKit/Electron or any other browser security wise?
iansinnott 4y ago
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/ https://wails.io/
webmobdev 4y ago
For those who are wondering, Ultralight (the browser engine backend here) is a fork of WPE - https://webkit.org/wpe/ https://webkit.org/wpe/ - a webkit port for embedded, low powered devices. More details here - https://wpewebkit.org/ https://wpewebkit.org/ ...
- adamjs 4y ago
  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).
halotrope 4y ago
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 https://news.ycombinator.com/item?id=24304043
- seanw444 4y ago
  This is good to know. Thank you.
- adamjs 4y ago
  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.
keraf 4y ago
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. [0] https://tauri.app/ https://tauri.app/
- Aeolun 4y ago
  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 :/
- parsadotsh 4y ago
  What are the features that you find Tauri lacks?
  - stillkicking 4y ago
    A node.js back-end.
torginus 4y ago
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.
- _gabe_ 4y ago
  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.
borbulon 4y ago
I'm confused why this is a topic of discussion - the repo hasn't been updated in 3 years.
- devmor 4y ago
  From OP's submission history, this doesn't seem to be the first time they've posted an outdated repo for some reason. Maybe they just share every interesting codebase they find.
otikik 4y ago
The name is unfortunate. A muon is about 200 times heavier than an electron, not lighter.
- nominusllc 4y ago
  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.
  - otikik 4y ago
    Thank you for your hindsight, have a very nice day.
nine_k 4y ago
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?
- jcelerier 4y ago
  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).
- murermader 4y ago
  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.
dreamcompiler 4y ago
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?

172 points by nateb2022 4y ago

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.

mikaelsouza 4y ago

The last update seems to have happened in 2019, unfortunately.

hbbio 4y ago
Indeed, and as mentioned in this thread, Tauri seems a better alternative: https://tauri.app/ https://tauri.app/

bitwize 4y ago

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.

yazzku 4y ago
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.
- hollerith 4y ago
  IANAL, but it makes perfect legal sense to me just like it is perfectly legal to run an open-source app on a proprietary OS.
  - bee_rider 4y ago
    I also ANAL, but is it really like running on a proprietary OS? It seems more like having a dependency on a non-free library. An open source program which requires, for example, DirectX is pretty severely hampered, right? 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.
    - hollerith 4y ago
      OK I admit that the analogy is not worthwhile on second thought. 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.
      - bee_rider 4y ago
        > 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?
        yazzku 4y ago
        I do care, and in your example, it depends on what license the project uses and how "proprietary_library" is distributed. 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 https://github.com/ImVexed/muon/tree/master/ultralight [2] https://github.com/ultralight-ux/Ultralight/blob/master/license/LICENSE.txt https://github.com/ultralight-ux/Ultralight/blob/master/lice...
trinovantes 4y ago
There seems to be a fair amount of missing features too https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178
adamjs 4y ago
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.

hardwaresofton 4y ago

These days I’ve been absolutely impressed with Tauri: https://github.com/tauri-apps/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

creatable 4y ago
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?
- warning26 4y ago
  Both are lightweight Electron alternatives, so it seems relevant.
- hollerith 4y ago
  I wasn't confused: both softwares let you create a cross-platform desktop app using html, css and js.
- hardwaresofton 4y ago
  As others have said, Tauri is exactly the same sort of tool, sorry if the mention of Rust threw you off! Some more: https://wails.app https://wails.app https://nwjs.io/ https://nwjs.io/
  - hiyer 4y ago
    I don't think it's the mention of rust so much as not providing context on what tauri is. Mentioning that it's an electron alternative would have cleared that up.
    - green_on_black 4y ago
      I would have assumed it was an Electron alternative or tooling for Electron. Either way, those kind of comments are quite annoying. Commenter didn't even click the link before replying with hostility.

yazzku 4y ago

The project has an MIT license, but its main dependency is proprietary garbage: https://ultralig.ht/#pricing https://ultralig.ht/#pricing

hamstergene 4y ago

> 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.

Waterluvian 4y ago
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.
- icemelt8 4y ago
  [flagged]
  - AstralStorm 4y ago
    However most software developers prefer a well documented tool with support and user base. Heavily licensed software tends to lack the second part of this. Being able to fix bugs you hit on your own, if push comes to shove, helps too.
  - squarefoot 4y ago
    Oh please. Communism is no more since decades, except in some propaganda that sees it in everything they can't understand. Software doesn't necessarily have to be a boxed product you build and sell like a car or a pair of shoes; it can be a tool to build businesses around services (examples: Apache, MySQL, Node.js, etc), or to be integrated in other bigger products (example: the Linux kernel, Lua, etc). Not to mention that today, with personal data as a valuable asset, you can never fully trust software that goes online and is not Open Source.

deleted 4y ago

[deleted]

danielvaughn 4y ago

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.

jmisavage 4y ago
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.
greggman3 4y ago
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.
- sanxiyn 4y ago
  Firefox now renders with WebRender, not Skia.
adamjs 4y ago
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/Ultralight/platform/GPUDriver.h 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 https://github.com/ultralight-ux/AppCore
- Jasper_ 4y ago
  Tessellated path geometry? Have you stopped using the signed-distance field path implementation? If so, any reasons why or lessons learned?

hpcjoe 4y ago

Commenting on the name ... technically, a muon is (like) a heavy electron ...

ohiovr 4y ago
Super heavy electron hmmm
gpderetta 4y ago
So the lightweight electron alternative is a more massive electron...
nuccy 4y ago
Funny inconsistency indeed. Muon is ~206 times heavier than electron... and it is also unstable :)

jchw 4y ago

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.)

rafram 4y ago

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. [1] https://github.com/ultralight-ux/Ultralight/issues/178 https://github.com/ultralight-ux/Ultralight/issues/178

adamjs 4y ago
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).
- mwcampbell 4y ago
  Any plans to work on accessibility (e.g. for blind people using screen readers)?
  - adamjs 4y ago
    Yes-- WebCore has an internal Accessibility API that I'm going to expose in 1.4 to be either handled by the embedder (so you can determine the best way to display / navigate that information) or handled by AppCore (we provide stock implementations of most of the platform API there).
airtonix 4y ago

r1chardnl 4y ago

How does this compare against CEF/WebKit/Electron or any other browser security wise?

iansinnott 4y ago

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/ https://wails.io/

webmobdev 4y ago

For those who are wondering, Ultralight (the browser engine backend here) is a fork of WPE - https://webkit.org/wpe/ https://webkit.org/wpe/ - a webkit port for embedded, low powered devices. More details here - https://wpewebkit.org/ https://wpewebkit.org/ ...

adamjs 4y ago
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).

halotrope 4y ago

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 https://news.ycombinator.com/item?id=24304043

seanw444 4y ago
This is good to know. Thank you.
adamjs 4y ago
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.

keraf 4y ago

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. [0] https://tauri.app/ https://tauri.app/

Aeolun 4y ago
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 :/
parsadotsh 4y ago
What are the features that you find Tauri lacks?
- stillkicking 4y ago
  A node.js back-end.

torginus 4y ago

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.

_gabe_ 4y ago
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.

borbulon 4y ago

I'm confused why this is a topic of discussion - the repo hasn't been updated in 3 years.

devmor 4y ago
From OP's submission history, this doesn't seem to be the first time they've posted an outdated repo for some reason. Maybe they just share every interesting codebase they find.

otikik 4y ago

The name is unfortunate. A muon is about 200 times heavier than an electron, not lighter.

nominusllc 4y ago
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.
- otikik 4y ago
  Thank you for your hindsight, have a very nice day.

nine_k 4y ago

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?

jcelerier 4y ago
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).
murermader 4y ago
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.

dreamcompiler 4y ago

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?