> 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.
WebKit is BSD but has sub-modules with LGPL code (specifically WebCore, JavaScriptCore, and WTF).
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.
Adam, we hung way back I was working on an on device search tool called Orbit that could’ve used Ultralight, I think at bespoke. Been keeping tabs on it since, congrats on the release.
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.
>>> Ultralight can emit raw GPU geometry / low-level draw calls to paint directly on the GPU without an intermediate CPU bitmap. We recommend this integration method for best performance
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!
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.
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.
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).
I was a mobile dev, mostly native iOS and some android/kotlin, for better than 10 years. I still maintain a dozen apps from my days as a full time consultant.
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.
I agree with the first part, but not with the second. Doing layout in e.g. WPF or QML was way easier than anything we had in HTML until flexbox became a thing - which is to say, for many years. Simply because those frameworks were designed from the ground up around laying out widgets, while HTML was oriented more towards document-like flow for a very long time.
Yeah, but flexbox came around 2012 and Electron came around 2013. Web UI weren't that popular until electron.
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.
I agree with your first bit, but so far have been unable to find layout tools for HTML/CSS that compare to the ease of the VB6-era drag-n-drop component editor. I'd love to know of one, though.
Those tools didn't work well for things that need to adjust to different screen/window sizes or even for localization causing text elements to change size. For that kind of stuff you need some kind of dynamic layout like springs & struts, flexbox, etc. I think Qt and XCode have drag and drop UI designers for layout systems that work that way, instead of picking an exact position for things you pick their location and size relative to their contents and things around them. I find just using CSS to be easier to think about than those but they're nice for trying things out.
I find it's hard to rat-wrestle your way to a GUI that adapts nicely to different window sizes, resolutions, etc. Xcode probably comes the closest but I haven't tried it in years. I know there are purists who think "well, it's a VISUAL interface so you have to lay it out VISUALLY!" but this is actually trickier than you might think when you have to render the UI in a different context from when you created it.
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.
> doing layout in HTML + CSS is a million times easier than in native frameworks
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.
> doing layout in HTML + CSS is a million times easier than in native frameworks
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.
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.
Yeah, React Native for Desktop seems really like it's be great (and the apps that use it like messenger for desktop are great). Unfortunately there hasn't been a stable mac release for several versions, and there's no linux version.
Every word in this sentence is the opposite of my experience and understanding. RN feels like a half maintained backwater compared to react for web. Lots of out of date docs, awful debugging experience, inconsistencies between ios and android, fidgety and flakey all the time. And it has all felt like that for a while. So I would beg to differ with "maturing" and would definitely call bs on anyone characterizing it as "mature".
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.
Sort of related, is there a project out there that reimplements enough of dom/css in the canvas to where you could theoretically run a lot of react projects with the canvas as the target instead of the dom itself?
> 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.
This is not not paying for tools. A lot of people pay, say, for JetBrains IDEs.
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.
If other professions had the option to pick up free toolboxes that aren't necessarily the best quality in the world, but are decent enough, then I'm sure many of them would be pretty damn happy about it.
Even paying for tools at existing 1€ shops is more than many currently do.
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.
My point is that it's not exactly a moral failing of a software developer compared to another professional, if the other professional doesn't even have the opportunity to make such a decision
Electron doesn't actually do this. Most Electron apps you know have a native iOS and native Android counterpart for mobile. React Native and Flutter do allow you to do this, though. They are the true Electron heir. Flutter / RN even run on stuff like Car infotainment systems, tvOS, watchOS and so on. They've got Flutter running on embedded too.
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.
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.
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).
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).
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.
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.
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.
> 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:
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.
I don't think it's the same thing. That program may be cross-platform and not actually need the proprietary OS, for example. This, on the other hand, has a core dependency that is non-free.
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).
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.
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/ ...
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.
Hah I could write a whole post on this topic but ultimately after experimenting with many different approaches on real-world hardware, tesselating the paths and using multi-sampling for AA (you can limit the MSAA to a single area via offscreen buffer) was the most reliable performer.
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).
Despite being a noob in this space, I'm very interested in it. Have you come across Ralph Linus? I've seen him pop up in a few HN threads that discuss SVG rendering with the GPU, and he's doing some interesting things: https://raphlinus.github.io/
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?
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.