hckrnws
Some questions that aren't in the FAQ:
- What is the license? Apparently Apache 2.0 [1].
- What is the minimum web bundle size and startup time?
- On desktop, what is the minimum RAM usage? Binary size?
- Is there a WYSIWYG editor?
[1] https://github.com/unoplatform/uno/blob/master/License.md
- Yes, Apache 2.0 - Web is meant for WebApps, not websites. Including Uno+DotNet runtime it's about 4mb compressed. - No WYSIWG editor, yet, but Hot Reload works really well.
Is the website wrong? The repository for the toolkit is MIT, but the website says free for under $1million...
https://github.com/unoplatform/uno.toolkit.ui/blob/main/LICE...
https://platform.uno/uno-toolkit/
DEV FRIENDLY LICENSING
Uno Toolkit License
Uno Toolkit is available for free for individual developers and businesses with revenue of less than USD 1,000,000. If your revenue exceeds this threshold, please reach out to us to obtain a license for Uno Toolkit and access the complete suite of development accelerators.
One thing I don't understand about Uno is how do they make money. Everything looks very well done and I have been following them for a few years but I don't see how they will survive without selling anything.
Sustainability explained here: https://platform.uno/blog/sustaining-the-open-source-uno-pla...
We're also building products of Uno with licensing, first one being the Figma plugin for Design-To-Code: https://platform.uno/unofigma/
They offer paid support plans. That actually may explain why everything looks so polished.
Any company that is giving away open source software for free seems to eventually go down the route of open core or restricting commercial use of their open source product.
Uno seem to be starting to go down the enterprise support route - plus open core with their recent Figma plugin release. At least the Figma plugin is very tangential to the core product so it's hard to imagine it competing for features at this stage.
Though with the recent spate of open source company rug-pulls, and I'd struggle to justify using it. It seems like open source is increasingly just being used to build market share, then the VC/PEs come in, make a "contact us" enterprise pricing page, and suddenly issues and PRs start getting rejected because they compete with the paid add-ons.
I really hope the same won't happen with Uno, because it looks like a great library, and something that's missing from the dotnet world. Their sustainability blog post gives me hope, but... sadly it would not be the first time that founders with good intentions find out that running an open source company is nearly impossible, end up taking funding to keep up, then the rest is history.
Uno founder here.
Uno as a UI framework is and will remain FOSS. It's been our strategy from day one and core to how we operate.
We see real opportunities to build productivity-focused products on top of it that will bring licensing revenues. Our Figma Design-Code plugin is a proof point and we have a lot more to come.
Thank you for caring and for the insights.
I appreciate your statement here, but I think part of the reason the GP commented on this is that we hear this from companies all the time. We all recognize that you're speaking the truth of today, but things change. This may be important to you, but unless Uno is your lifestyle business and you maintain control despite external pressures from board members brought on as capital sources, you're not capable of providing a guarantee in perpetuity, let alone for any well defined metric of time.
It's fair for us to be gunshy. There's simply too many examples of OSS projects highly used across the web that made these kind of promises earlier on in the product's lifecycle, many if not most of them with the best of intentions at the time the promise was made. I trust that what you're saying is true today. Until we start to see more OSS projects with sustainability models that are both successful at staving off negative influence from funding partners, and those sustainability models leading to companies making good on the declarations of altruism they made when they were younger, I think we're going to remain unsure and unconfident in promises like this.
Don't think it's going to stop us from checking out your product or potentially building really cool stuff with it. But until you prove to us that you'll keep this ethos, we will start using this really cool framework with one hand while we keep another hand free to stabilize ourselves in what feels like an inevitable rugpull that isn't a matter of if, but when.
I wonder if your point of view, which I describe as "open source absolutist/optimist", has any facts to prove that your point of view is actually a thing that exists, or is fantasy...no offense. Maybe even the biggest open source projects are currently on "borrowed time"?
I'm sorry I wrote this as I didn't actually review the project and see if the source code is available. It appears to be closed source. Your concerns are definitely valid.
My comment was more directed to open source, and I would say to you that the only in-perpetuity guarantee is to fork it.
Looks awesome. How easy is it to use other libraries together with Uno? Say OpenGL for iOS and Android. Any examples? Looks very interesting.
You can embed any native component per platform.
We're actively working on bringing an unified OpenGL control in our Toolkit so it works on all platforms and be ready-to-use. Stay tuned!
It's .NET, mentions Windows and native, yet none of the screenshots look anything like native Windows controls.
Uno wants applications to look the same across platforms (as Flutter does) but still wants to use native controls. So their approach[0] is to have default styling applied to every control which makes the native controls look the same on each device [0].
I think the main benefit with this approach is expected-behaviour (like how different desktop operating systems have different textbox behaviour), and that whatever accessibility you get by default with native controls is there. [1]
I don't really find their approach to GUI development compelling though, with them choosing a middle ground between "wrapper around native controls" and "implement everything yourself".
[0] Except on Linux and web, where Uno draws everything itself, imitating controls that look like GTK (on Linux) or UWP/WinUI (on web). These are the platforms I briefly tested on and I didn't have an enjoyable experience with the output due to non-native/non-expected behaviours.
[1] Page on accessibility: https://platform.uno/docs/articles/features/working-with-acc...
Uno Maintainer here - Thanks for trying out Uno! At this time, the default render mode is provide a uniform look across platforms, and it's possible to alter the theme using Material, Fluent or Cupertino, or to design your own theme using control template styling, or even use native controls directly where applicable.
On Linux, we've just released our support for X11, removing the need for GTK. As we're drawing the whole app surface, we're always interested in adjust the UX of our controls on individual platforms. If you have examples, let us know.
Finally, for WebAssembly, our current rendering backend is using the HTML DOM, which means that accessibility and other native behaviors are functional. Same here, if anything accessibility related is missing, we're all ears!
Hi there. Appreciate the response!
I didn't know that the HTML DOM is being used for Uno's web output but that's good to hear. I was under the impression that things were being drawn to canvas (like how Flutter's web output works) but functionality like Ctrl-F (text search) works on https://gallery.platform.uno/, showing that's not the case.
I'm not sure why I had the impression that the web output used HTML canvas, but maybe that was something that changed since I last looked a few years ago or there might be another reason I was mistaken.
I think one misleading thing that gives the wrong impression is that text isn't selectable on Uno's web output (like https://gallery.platform.uno/), similar to how text isn't selectable on HTML canvas.
I think it's worth having a discussion about that with other employees, because it's one divergence from user expectations about how the web usually works (but application developers may also prefer to make text not selectable so it may be the behaviour you want in some cases after all).
Indeed, text selection is a specific behavior that was chosen to be disabled by default in order to be closer to the original behavior of WinUI on desktop. This is a configurable behavior on the TextBlock control, though.
That's the choice people face: "native" (different on all platforms) vs "synthetic" (looks the same but loses true native functionality).
Correct - and with Uno you get to chose either one of those approaches - https://platform.uno/pixel-perfect/
Uno is based on UWP, on Windows it uses the native UWP stack.
Uno Platform maintainer here - Uno is compatible with both WinAppSDK/WinUI and UWP API sets. Our default project templates have been on WinUI for two years now, UWP mainly being supported for temporary upgrade scenarios to WinUI.
Nope it is not.
[flagged]
[flagged]
Uno is a third-party open-source project. It is not related to UWP beyond the fact of being a .NET GUI framework.
It's like complaining that a particular Yamaha bike is bad because a Yamaha digital piano of particular model is bad.
Do take pills before posting, thanks.
[flagged]
I don’t think native here refers to the control styling being similar to Win32 on Windows.
I could be wrong, but it might be able to host native components or draw your own.
Indeed, an Uno app is a native app, it uses UIKit on iOS, Views on Android, HTML on Web, except on Linux where you only have access to our Skia renderer.
Therefore you can embed native controls.
"on Linux where you only have access to our Skia renderer" ... means what? Can I make a basic GUI app on Linux with Uno. If yes how ?
Yes, on Linux it behaves similar to Flutter and draws directly to a Skia Canvas.
It used to have a dependency on GTK but no more since the 5.2 release.
There's just no notion of "native controls" that you can embed in an Uno Linux app like you could have if you wanted to embed a 3rd party native UIKit control on iOS.
Is there a "gallery" where I can try out one or two apps developed using this, on different platforms?
Uno Platform maintainer here - We're maintaining production apps ourselves, like NuGet Package Explorer [1], or Uno Calculator [2], and many third-party apps are in production, with some shown in case studies [3]. You can also find some other tech Wasm demos [4] on our repo.
2: https://calculator.platform.uno
I just learned about this thing today, so take this with a grain of salt: there are links out to two apps, Simple Calc and Tube Player, at the bottom of the home page. These are tutorials and source code, not a finished product. There is also a "gallery" on the top right, and you can play with the UI components rendered in the web: https://gallery.platform.uno/.
Uno has been around for over 4 years. Wondering why this hasn't picked up so far, albeit being a very flexible platform/framework.
Presumably because, much like the half-dozen other flexible cross-platform frameworks Microsoft and friends have gotten one-third of the way to a viable product before abandoning to chase the next shiny thing, it's riddled with bugs, about ten years behind the documentation of a more usable framework from the 2010s, and has basically zero third party support from the likes of Infragistics and SyncFusion.
UWP left behind a shockingly large number of perfectly serviceable pieces of WPF, at a time when the emergent UI experience on Windows 8 was being written off by almost everyone, Windows Phone was DoA, and people were starting to realize they could just write web pages and run GUIs in the browser instead. It's been a long, bumpy, downhill ride ever since. The fact that Electron.NET and Blazor is a serious UI suggestion from Microsoft these days should tell you everything you need to know.
I'm sure with enough effort it's usable and maybe even nice in some ways. I did some proof-of-concept work with it two years ago and got maybe 50% of the way to where I wanted to be in 8 hours, but got stuck at styling issues for which there was limited documentation. In the end, I'm more confident these days in WPF + Avalonia if I really need cross-platform - even if there's comparable bugs and limited documentation, there's at least some momentum still behind the project. UWP, all three busted half-finished versions of WinUI, MAUI, Blazor + Webview2, Blazor + Electron.NET... even Avalonia, thanks to the weird decision to change styles to behave more like CSS... it all still struggles to be as usable as WPF.
Why do people always complain about the lack of mature cross platform desktop GUI development options for .Net? Most other programming languages and ecosystems don't even have viable options for desktop GUI development. When was the last time a new version of Elixir, Ruby, Go or Rust was released and top comment was complaining about the state of desktop GUI development options?
The whole industry is unfortunately moving towards web interfaces being the default. That is unfortunate but it is an industry wide trend.
Elixir, Ruby, Go?? Maybe because the C/C++ and JavaScript/Typescript user bases are about 10000 times larger and we have relatively robust cross platform UI solutions for both in the forms of QT and Electron. C# is a weird outlier for having a very large user base but very few decent cross-platform GUI support.
Python's user base is pretty large, it's the most popular programming language by some metrics, and yet the situation there still sucks.
You can use tkinter, which doesn't work well with native platform features and forces you to rewrite your app from scratch in something else when you finally need to do accessibility. QT is free for noncommercial use only. WX kinda sorta works, but WX apps on Mac feel like they were on Windows, and the naming conventions are extremely unpythonic. Toga looks like a nice option, but it's still pretty young, I'm not sure how far I'd trust it.
> QT is free for noncommercial use only.
How so? It’s LGPL.
LGPL is very problematic when distributing for things like iOS, what with the user re-linking requirements. On Windows, Mac and Linux it can be quite easy to solve.
There are, and have never been any issues distributing LGPL applications on iOS. You might be confusing it with AGPL?
No
C#'s user base was historically tied to Windows, and there are many C# GUI frameworks for Windows.
I, being a .NET developer since v1.1, won't touch most of them.
WPF, a framework from 2006, and Avalonia, a 3rd party framework, are the only two worth considering.
Six months ago I would have argued with you, but currently doing a MAUI transition from a Xamarin Forms app, and you are very right.
I wish Avalonia UI's mobile solution had had Navigation sorted a year ago when I proposed that we needed to do something with the XF EOL announcement. I had a POC with it working well enough, but sadly it was "too much work" to migrate the rest of the app. Now with MAUI we have realised that we are probably doing just as much work anyway, and it is seriously half baked as an ecosystem.
Thank you for this comment. Trying to sort through the mess of GUI frameworks for .NET and other languages is difficult.
Exactly this. Anecdata, but the vast majority of the C# developers I know not only don't use anything but Windows, they are actively HOSTILE to non-Windows systems. Many of them view non-Windows systems as either toys ("MacOS is for graphic designers") or too spartan to be worth their time ("Linux is for sys admins").
As well with the rise of new tech/stacks that has displaced C# in a few places, the people who stay in C# tend to bristle at other OSes as that's what the people who are using the other techs use (and us vs. them type attitude).
So in the grand scheme of things, it's unsurprising that this happens.
I think this is an outdated view. I run a dev shop which develops applications in . Net + Angular. We have always given devs freedom to buy whatever laptop they want and put whatever OS they want on it, as long as they can work with everyone else. 5 or 6 years ago, we had 1 person using Ubuntu, another person using Mac, and everyone else used windows. Right now, roughly 40% are on windows, 30% develop on Mac and 30% develop on Linux (Linux has recent grown at the expense of Mac actually).
Our production environment where all applications are run is based on Debian (though we test on Windows Server as well) in a kubernetes cluster, running in Azure.
C# is decent language for writing line of business application logic, and these days .Net is a completely cross platform, open source framework.
I remember using a bunch of C#/Mono applications (F Spot, Banshee, etc, they were all the rage once) on my Linux desktop over 20 years ago.
I've worked with a team that used Rider + macOS combo in the past and have friends who had a similar experience. There are those who choose to use Neovim + csharp-ls instead, or any other combination besides the historical Windows + Visual Studio.
Keep in mind that .NET has "inherited" a huge ecosystem and developer community that existed and still exists within the confines of .NET Framework. It roughly splits into two groups - the one that is moving or has moved on to .NET and left the legacy in the past and the one that harms the ecosystem by refusing to do so. Luckily, the former is in the minority compared to the latter especially as the time goes by.
It is also helped by new generations of developers who came into working with the tech after .NET Core and .NET became the mainstay or developers who moved on to .NET from other languages and ecosystems.
You're correct about that sentiment from .NET developers historically but things have changed. At Skype, a company that's been under MS for a decade, more than half the devs use Macs.
C# is still my favorite language and I haven't used Windows since 2017. JetBrains Rider is my IDE of choice on a Mac. It was pretty rough during the early releases of it, but for years now it's working well enough. Also .NET Core 1.0, 1.1 and 2.0 was a ride. project.json anyone?
Fastforward to .NET 5, 6, 7, 8.. it's just doing great x-plat life and innovation
I'm sure that is true. I just know the C# developers I work with now and recently fall into the camp I mention.
Maybe we have different circles.
I'm one amongst many using Net on other systems (Mac & Linux) as well as Windows. Larger enterprises which use VS on Windows often deploy the results onto Linux servers too (especially with microservices), which is hardly being hostile.
Though to address the issue of GUIs in Net-land, I've given up as nothing since WinForms (and possibly WPF) has lasted. They are 'supported' in many cases, but it always feels half-hearted or half-dead.
> C# is a weird outlier for having a very large user base but very few decent cross-platform GUI support.
MAUI is pretty decent.
That's not what people say when the daily poster in r/dotnet asks what framework they should use for a GUI app.
MAUI is not ready. I started a Greenfield project this year. Having tried a serious project in Xamarin Forms, I reached for WPF. The app is almost ready and the speed at which I was able to get stuff working (and beautifully so) has resulted in our company being able to win new business. WPF has no limits. It just works. Tons of community support.
My hope is that MAUI gets to WPF level soon. Refactoring away from WPF to MAUI should be almost trivial, if desired.
Okay - this is not going to happen. WPF lets you do really complicated binding tricks that XF was just not capable of. Maui is just an evolution of XF, but so far I think iit is a step back from what we had before. We have some stuff working, but it was painful to make it work and some of the WPF tricks we used in XF with binding are broken in Maui so far. I'm sure we will fix most of them, but it feels like we will just refactor a lot of it away to simple properties rather than complicated multitrigger bindings. I echo "Maui is not ready".
Microsoft had remarkable native frameworks that they just decided to ditch. Many Forms and WPF applications still work and run entire businesses, but because of Microsoft's unnecessary churn, they are stuck with the legacy .Net Framework.
Yes. Many FOSS ecosystems don't even have adequate GUIs, but they never had them. Microsoft had them but then lost them. Every "modern" replacement requires you to import a whole browser in some form or another with all the baggage that comes with it, both in terms of development, runtime and security.
> they are stuck with the legacy .Net Framework.
I develop WinForms applications at work and we use .NET Framework by choice, to aim for long-term stability and not the 'new thing'. We are not stuck we're loose. It's important to understand that MS Windows will never be able to get rid of the ability to run .NET Framework apps. Also, even though the new .NET supports WinForms, it's not a 1 : 1 port yet and we've done extensive testing on this. Not using .NET Framework would mean degrading the performance of the app (~30%). Try it out for yourself with a controls heavy application. I'm talking 100+ controls on a single app with real-time data fed through it. We use 3rd-party WinForms controls that's been in development for over 15 years. The GUI is modern and the performance excellent.
Words like 'legacy', in our case, means better stability and higher performance, and frankly, we neither trust nor care about Microsoft's opinion.
That said, I can understand that the new .NET is useful and an upgrade for those who wants cross-platform support among other things.
If you were to fire up your IDE and start a new greenfield C# project, would .Net Framework be your first choice?
Absolutely. Main reasons being 1) that we don't need any of the new features modern .NET can offer and 2) we specialize in mission critical, high performance apps
For example, recently a customer wanted a security solution, a filesystem journaling application, powered by a low-level FS kernel driver (C/C++) together with a managed .NET assembly to interop with our unmanaged driver DLL. Running on the highest altitude - on top of the driver stack - means handling, filtering, and intercepting a huge amount of filesystem requests before it reaches other system components. Therefore, performance is key.
In that scenario, using modern .NET we experienced nonstop deadlocks which froze the whole system. .NET Framework had no issues keeping up.
I can also think of other examples e.g. issues working with custom virtual filesystems.
So yes, NET Framework would be my first choice for standard Windows-only desktop applications.
In what scenarios can you make .NET Framework perform faster than .NET 8? The expected performance difference is 2 to 10x in favor of the latter. It’s not even a choice. If you can reproduce the issue, please consider submitting it to dotnet/runtime rather than choosing obsolete target.
I already gave two examples 1) large-scale WinForms app with third-party controls and libraries and 2) Interop with FS kernel driver under heavy load
We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).
Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.
Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.
Would be interesting to learn more. It seems like you know your stuff well, but could it be that your ported code doesn't do things like it should be done in modern .net?
Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.
> could it be that your ported code doesn't do things like it should be done in modern .net?
I'm actually curious myself after this discussion. I didn't port it, my coworker did it and I'd have to ask him. I did take part in the benchmark though and watched all the deadlocks happening.
Found this old screenshot of our internal FS driver debugging tool - to give you an idea of what I mean by needing high performance: https://postimg.cc/mc6YQFbC
24,654 filesystem events in C:\Windows\ in just 1 minute and 30 seconds on idle. 814 read operations (36,7MB) + 948 write operations (66,9MB). Now imagine this system-wide (not just the Windows dir) under heavier load. This is where modern .NET could not keep up leading to the aforementioned deadlocks.
Sorry that I can't provide more specific info at this time. I can find out more on Monday.
Interesting, that is a good load test indeed. If it turns out to be a regression in .net core, it would certainly make sense to file a bug on github.
If there is an issue, chances are it's in the for-new-.NET implementation of WinForms. Any regressions in the GC or CoreLib themselves are definitely not expected and can be submitted as issues to be fixed.
There can be latency differences in edge cases of interaction between threadpool used by specific version and Overlapped IO on Windows, but that's likely about all there can be.
It's important to note that .NET Core 3.1 -> .NET 5 -> 6 -> 7 -> 8 is a huge difference in compiler and corelib internals (less so in GC, with major steps in 6, 7 and 8 in regards to regions and now DATAS), so an issue that could have existed in one of the previous versions is likely to be fixed by now.
That would be an exceedingly poor choice. Libraries have even started to drop NS2.0 target as it is too limiting or requires if-defs and extra maintenance effort for obsolete targets.
Both Win Forms and WPF work with .NET 6+ though.
Lots of asterixes and special cases. It's not just a drop-in replacement.
If Microsoft said "Windows-only, good luck with cross platform," I'd accept it and move on. It's their prerogative to spend their resources enhancing their own platform.
Instead, I've been told a half-dozen times that there's a new cross-platfotm GUI option, and had I bought into any such endeavor, I would have been rugpulled by sudden deprecation or loss of focus. I think people who did buy into any cross-platfotm GUI frameworks from Microsoft in the last ten years are justifiably feeling like they've been hung out to dry, sometimes multiple times.
I don't complain about Elixir, Ruby, Go, or Rust GUI development because I don't try to use these languages for GUI development, because their core leadership and marketing doesn't promote this as one of the primary use cases. C#, and the .NET ecosystem at large, are THE premier Windows GUI development tools. When their marketing pivots to cross-platform GUI development, and they rugpull you a half-dozen times in a decade with half-finished and baffling experiments, it kinda smarts.
Most people developing desktop apps are probably okay with switching to web-based options, including potentially running their own standalone rendering executable on top of a web view or chromium instance. But there's a significant minority that are building desktop apps because they want better performance and native visual integration/theming, who don't benefit from browser process isolation and the hairy JS event loop situation, who don't want to serialize every user action in the GUI, who saw what XAML set out to accomplish (GUI style templates that convert to framework code that could equally be hand-written, modified, or extended) and ran marathons with it. Maybe this will get better with WASM improvements in the next few years, but it doesn't change that the approach to GUI design is fundamentally different, and in a lot of ways needlessly harder, when you have to pretend your GUI isn't all running on the same machine.
> When was the last time a new version of Elixir, Ruby, Go or Rust was released and top comment was complaining about the state of desktop GUI development options?
Because no one in their right mind would write anything GUI related in those languages.
That doesn’t really answer the question though.
.. because there isn't a framework!
…and they’re okay with it, because historically GUIs are written in platform native languages.
[dead]
There are also people complaining that Electron is slow and bloated - but in reality there is no alternative for open cross platform GUI.
Sure there is. You can use JavaFX from any language that runs on the JVM (so that includes Python) and it's been steadily matured over more than a decade. It's maintained by a mix of corporate and community developers, and you can buy support from multiple vendors.
It doesn't get much love on HN but it's there, it works, I've used it to ship real apps.
How does Hydraulic Conveyor improve the distribution of cross-platform JavaFX applications, especially compared to the standard jlink/jpackage workflow?
Our website https://hydraulic.dev/ covers the most important points but compared to jlink/jpackage:
• Delta software updates without code changes. On Windows apps update in the background even when not running.
• It can do web-style synchronous updates on app launch.
• Can build for every platform from any platform. Linux cloud CI workers can be 10x cheaper than Mac workers, so this feature can save you a lot of money!
• Lots of usability work and features around code signing/notarization. It can do signing without MS/Apple tools and it knows how to use cloud signing services, remote HSMs, local HSMs, the Mac keychain (protected from other apps), custom enterprise signing services that can only be accessed via scripts, it can check for many kinds of mistakes (a particular weakness of vendor tools), it will help you buy certificates by generating CSRs for you.
• Generates a download HTML page that detects your user's OS and CPU to give them a big green download button, it can upload all the artifacts to S3 or GitHub Pages/Releases or any other server via SFTP. It renders icons for you, etc.
• Deployment by Windows IT is easy and installation doesn't require users to have admin rights on their system.
• It can publish to the MS Store which lets you avoid needing to buy signing certificates for a one off $19 fee.
• It comes with commercial support. With other tools if you get stuck you're on your own.
----
All the above works for Electron and native apps too. For JVM users specifically:
• It figures out which JDK modules you need using jdeps and bundles a minimized JDK.
• It provides a Gradle plugin that can read config out from your build configuration automatically.
• Easily bundle JCEF if you want an embedded Chromium.
• (soon) It will provide an API that lets you check for updates and trigger them manually. This is done, it just needs to be fully documented and published to Maven Central.
• It has way better support for native code than jpackage. It will dig through your JARs to find native libraries that don't match the target machine and delete them, it will sign them in-place, it can extract them ahead of time and then set up your system properties to make them be loaded from the right places and so on.
• It can bundle custom TLS root certificates into your JVM trust store. That's especially useful for enterprise settings.
That's not even a complete list by any means. Conveyor is packaged with itself and is a JVM app written mostly in Kotlin, so the above features get dogfooded by us.
I wrote this tool partly because I really wanted to close the gap between web and desktop dev, to let developers have more freedom around frameworks and languages than they do today. It's not right for everyone but if you aren't hog-tied to the browser then the pain of distribution is really removed by this thing, and that lets you focus on building your app.
Thank you. Your software has indeed a decent feature set. I will definitely try it out as soon as possible. I wish you the best of luck with the business!
Can you use it on Android/iOS?
Actually, yes:
https://gluonhq.com/products/mobile/
Although it's not a mapping over the native UI toolkits so it has the same issues as Flutter etc.
No it is not, it is just like QT, damn shady all over the page Creative Commons where framework code is not even on github but their docs and landing page is.
Electron is just using HTML/CSS/Javascript that are open, Electron alone is MIT licensed and there are no tricks like "2 developers - well you have to buy $900 a year license".
I don't expect everything to be free as in beer but JavaFX looks shady. I would never build my business on their platform, would rather go with QT.
What are you talking about? It’s GPL v2 with classpath exception.
It is owned by for profit company.
I don’t see how that is relevant especially when comparing to electron which is just Chrome.
And Electron depends on Chromium from the web killer Google
> There are also people complaining that Electron is slow and bloated - but in reality there is no alternative for open cross platform GUI.
What's wrong with Qt? There's also Lazarus (https://www.lazarus-ide.org/) with almost transparent interoperability with C.
They may not be perfect, but in light of their existence, it's hard to argue that there is no real open and cross-platform GUI.
If you relax your definition of "open" a little bit, there's still things like flutter.
HTML and CSS are open standards that are governed by W3C and JavaScript by Ecma. Electron is MIT licensed and OpenJs foundation seem like it is not going to do rug pull from under your feet.
- I don't mind GPL or LGPL and I don't believe everything should be free as in beer -
Still QT company pushy marketing is making it hard to just build stuff on their free offering is a huge turn down, to do a build I need to login to an account, crazy (well the same for Apple, but not the case for javascript/html/css).
Last but not least Lazarus/QT - how long will it take and how much will it cost to build a team of 5 developers to build and maintain product on these. When I put an ad for JS dev I am pretty much flooded, for QT/Lazarus I never posted an ad, but my gut feeling is I will be lucky to get any CV in 3 months.
> When I put an ad for JS dev I am pretty much flooded, for QT/Lazarus I never posted an ad, but my gut feeling is I will be lucky to get any CV in 3 months.
Things like staffing for specific skills is a different issue.
The comment I responded to did not say "There are simply no other Js+Html+Css browser-based alternative to electron".
If they did I would not have responded, because then they would be correct: there are few browser-based alternatives to Electron.
They said that there are no open alternatives, which is what I did respond to.
Because, to be honest, if you're in a company and a team, you are all probably going to use the most popular tech (whether electron or something else depending on the platform).
For all other types of developers, stack popularity may not be a factor at all. From the question asked, there was no context around the type of development or team.
For example, I'm an independent developer, writing custom software. It's faster for me to deliver a cross-platform desktop GUI in Lazarus than in Electron (the delivery speed of the GUI is not even in the same order of magnitude for the type of projects a solo developer can do).
OTOH, if the client needs the type of fancy CSS animation, theming, etc that only a browser can do, then you have no choice but to use the browser.
Show me where the ad is, you'll have my CV in a trice.
Java still ships and supports Swing/AWT - which is still what most desktop applications use to render a UI, even IntelliJ. I haven't worked with it in a very long time, but there used to be tooling support for alternative platforms like web browsers. Angular feels a bit like a spiritual successor to Swing.
These days I feel like React Native is your best bet for open cross-platform GUI. Its a nifty idea: your app still runs in JavaScript but the rendering layer is replaced with something platform specific. There are some big warts (performance is NOT uniform) but its probably the best way for someone with frontend chops to leverage their skills for other platforms at this point. (Although for desktop Electron might actually be just as good or better, too.)
I tried to use swing a year or so ago. It wasn’t a great time. I’d probably go with JavaFX or compose multi platform if I did it again.
Well sure it takes a bit of time and study to learn it but it's a totally viable cross-platform UI toolkit.
Oh I agree it’s viable! It just wasn’t pleasurable to work in. I’m looking forward to trying JavaFX when the time comes :)
I hope you tried it with the NetBeans visual designer. That is basically Java's Visual Studio.
FX is not flushed out. Though it does have some data binding, which is all manual in Swing.
Other than the already mentioned JavaFX which now goes by OpenFX due to Oracle’s TM license changes, there’s also
- Swing with FlatLaf look and feel, just exactly like the JetBrains IDEs, there’s a kitchen sink app JAR you can download from FlatLaf, there’s some nice extensions for the layout too, not for mobile though as far as I’m aware
- Vaadin and their 2nd framework whose name I forget, directly integrated with Spring and Quarkus
- Kotlin Multiplatform and Jetpack Compose Multiplatform, a very promising and awesome tech, works fine for my requirements, would be happy for them taking the lead, I love the syntax and their compositional semantics, similar to SwiftUI
- React Native worked great for me, can reuse some React.js stuff
- NativeScript, never tried
- Ionic Capacitor, never tried
I think it might make sense to watch a couple YouTube live coding showcase sessions with the respective developers.
Avalonia also has a kitchen sink app btw. And I really like Uno’s calculator app, though I recall having had a weird bug once in the calculation logic.
And as for Blazor, there’s always been JSF which have long had great UI components. To me Blazor is about replicating JSF.
Yeah, well, I wish there were just 1-2 really good choices to be made, but there’s a myriad of caveats in each framework, more so in some of them. Well, Qt comes closest I think.
https://fyne.io/ for golang (no accessibility yet).
As someone that went from a strong advocate of UWP, into a strong critic of UWP.
They really messed up WinRT.
Although not perfect at Windows 8 launch, its evolution until Project Reunion came to be had potential.
It was .NET as it should have been from day one, a proper developer friendly wrapper on top of COM, and Microsoft had finally provided something comparable to C++ Builder for the C++ crowd.
Instead they never delivered feature parity to WPF, killed .NET Native, C++/CX, the designer, and then started from scratch on Win32 side, while expecting everyone jump to put up with them, and follow for the ride.
I consider that an ultimately lack of respect for paying customers.
C++ Builder fan from my early career. Did they add designer/XAML support for C++ and then kill it? Do you have to do C++ dev with code only now?
It's become a morass. Did they ever get back to atleast where Xamarin was like 5 years ago? Why exactly is Microsoft doing this, it all sounds very shambolic, the approach they chose and the outcomes.
I think this space needs some stability, and Microsoft seems keen on inducing volatility for some reason.
Here’s the reason: the LPA cycle, unfortunately. https://twitter.com/buccocapital/status/1576909546164928513
I think Avalonia is finally emerging as a partial way out of the morass, a qt-for.net. And why? Because it’s from the ground up, and not from Microsoft.
As someone who seriously tried pretty much all the mentioned tools to develop modern windows applications I feel this comment sums up everything perfectly. WPF is still the most usable solution.
I really wanted to like UWP, then WinUI, but for anything that isn’t a simple demo project you end up spending all your time fighting the framework and facing broken/unpolished parts that make you feel pain and frustration.
Avalonia isn’t perfect and has some rough edges but I would still consider it for cross platform support over anything else.
This project is not related to UWP.
Is there actionable feedback you could provide to it?
For Uno specifically: I do like the attempt to build out a WASM target, it looks usable. Uno looks to be in a lot better state internally than even two years ago, which is promising - that's one thing I can't get out of either WPF or Avalonia.
Key things that need to improve: - Documentation appears to have gotten better in the last few years, but still many sparse or underdocumented corners. This is my biggest reservation today. - When I last used it (a few years ago), a lot of things weren't fully implemented - maybe this has changed? But it added a lot of friction.
WPF is a joy.
All cross-platform frameworks are somewhat underdelivering on their promises. Even if you get an app going quickly, you end up in some kind of maintenance hell a few months down the road.
This is a 3rd party framework on top of .NET (which itself is a 3rd party on mobile) which is 2 layers of abstraction on top of the actual thing that will run on the user's device. Microsoft takes a full year to update their GitHub runners with the latest macOS and Xcode versions, can you imagine the risk of having to wait for so many parties to update/fix their things?
Flutter and RN are not immune to this effect, every year when there is a new iOS or Android release, existing apps just break and tooling takes quite some time to catchup. It's so many side quests suddenly appearing without added value for the developer or the user.
So far I have found this to be much less the case with Flutter than RN. With RN I came to dread upgrading anything more than a few months after starting a new app.
The rather prominent XML on the front page might scare folks off.
Interestingly enough, in practice, there are various declarative SwiftUI-style nuget packages for Avalonia[0][1][2] and Uno[3]. You don't actually have to touch XML if you don't want to.
Edit: as someone else noted, the website itself links to a built-in option to do so as well - https://platform.uno/c-markup/
[0] https://github.com/AvaloniaUI/Avalonia.Markup.Declarative
[1] https://github.com/wieslawsoltes/NXUI
Plenty of folks that criticise XML, have no issues dealing with JSON and YAML spaghetti, ironically.
I agree. It's just quite a lot of verbose-looking XML. "I have to write that much XML" is probably not the first impression you want to give. I did scroll down and see that you don't actually have to write such XML by hand, but many will not.
Good feedback. C# and XAML are on parity. But if you are seeing too much of one and not the other, it needs to be adjusted
Has anyone tried Uno with F#?
You can create an F# class library and use it with Uno, it's all .NET. We just don't have a dotnet Template for it just yet.
Isn't Avalonia better?
Seeing several comments about Avalonia made go have a look at their website. Then I found the price page, and wow - that's a price!
€19,500 For the 1st app. Second app only €4,500
Just to clarify what is what: Avalonia UI is free, what is expensive is their XPF solution, which allows you to get free cross-platform features for your existing WPF app. So this is very much targeted at companies with legacy code that they want to make cross-platform without even more expensive rewriting.
As others have said, this only for a particularly hairy product called XPF, not Avalonia, so the price point is probably warranted, lol. Basically, they remimplemented WPF itself, the whole shebang as far as they could, to make a transition towards cross-platform support. Microsoft never even attempted this. It's for people mainly having a large, legacy WPF product so they probably already are a business and a desperate one at that to look at these fixes.
But if you're making something from scratch, just use the free Avalonia.
By the way, Avalonia also supports NativeAOT, unlike WPF, if used with the compiled bindings feature. Pretty cool!
Oh wow they re-implemented WPF? Madness. I seem to recall not wanting to make WPF cross platform was one of the reasons visual studio on Apple is based on monodevelop.
I worked at a shop that wouldn't hesitate to spend the 20k in a second if they had to.
There are two Avalonia products: free and open-source Avalonia UI and paid Avalonia XPF. Looks like [1] XPF allows making existing WPF apps cross-platform while Avalonia UI is more for developing from scratch.
[1] https://avaloniaui.net/Blog/migrating-wpf-applications-avalo...
That's for Avalonia XPF, their product that runs WPF apps on Linux and Mac. Avalonia UI is free and licensed under the MIT license.
Their website is
Where did you go?
[Edit] Sorry, I see that you are talking about the "XPF". I didn't use that before.
Comment was deleted :(
Used it for a couple of internal applications for a former client, zero cost.
I was confused by the name, because I remember 'Uno' as part of OpenOffice.
I presumed that this was OpenOffice internals that support cross-platform UI and OpenOffice scripting.
But apparently, the 'Uno' internals in OpenOffice are just the internal object message bus and don't have anything that is visible to the user.
How does this compare to Avalonia?
The right question, as Avalonia is the gold standard for the cross-platform .net ecosystem.
Maybe this opinion piece might help: https://www.codeproject.com/Articles/5366945/Multiplatform-X...
His conclusions:
«Now what I mean by "better" - it (ed: Avalonia) allows considerably faster development, maintenance and support of the products. In particular:
- It is a more powerful UI package allowing much more re-use and creating shorter code faster to achieve the same functionality. Part of the reason for that is that it is not confined to WinUI/UWP bounds - it is actually more powerful than WPF which is in turn better than WinUI or UWP. Another reason is that it has a better implementation with a lot of code re-usable across all of the platforms while Uno and MAUI essentially have completely different implementations for each of their platforms.
- There are many features in Avalonia that are not implemented in Uno or MAUI, while I do not know a single feature implemented for Uno or MAUI that would not work in Avalonia. If someone knows a single feature available in Uno or MAUI but not available in Avalonia, please mention it in the comments and I will refer to it in this article.
- Avalonia covers all the same platforms as Uno and more than MAUI does and has considerably fewer differences between behaviors on various platforms.
- Avalonia is easier to switch to for an expert WPF developer than to Uno or to MAUI.»I would not call it a gold standard. It doesn't have a WebView control, and its TextEditor control is slow as molasses.
Can I also create aesthetically neutral apps faster with this?
Yes, it's all simply a matter of styling.
You can leverage some of our existing design systems like Material/Fluent and customize them: https://platform.uno/docs/articles/external/uno.themes/doc/t...
Or you can start from scratch and define your own styles.
By default, they will be pixel-perfect and look the same on all platforms.
Is this just me or does Firefox become completely unusable when opening the homepage platform.uno?
Works almost perfectly fine for me with Windows 11 + Firefox 125.0.2 (64-bit), besides the top menu item icons not rendering. Reason for the icon rendering issues seems to be ill-configured cross-resource sharing, so should be the same for everyone else with a properly configured browser.
Using Firefox (Developer edition here, the blue one), and I don't see any issue.
How long have Uno being FOSS ??
Uno was open-sourced in 2018.
Has been in development since 2013.
Killing XUL was a huge mistake.
What's the difference between the NativeScript UI library and this?
Many differences. To begin, NativeScript is JS based, where Uno is .NET Based (therefore C# and XAML).
Fun fact, I worked on NativeScript team, and now on Uno team.
Cross-platform development, the scam that never ends.
Why? Seems like a flaming comment without any substance to back it up. Could you elaborate please?
It's flaming but I can relate. Every cross platform UI describes itself as the second coming of Christ. In reality there is always a tradeoff and impedance mismatch. Of course there are more polite ways to point this out.
It's not flaming. An astonishing amount of money has been wasted on the promise of cross-platform mobile development. At this point, anyone continuing to push it is complicit in the scam.
this roughly reminds me of Xamarin? Is there a similar philosophy behind it?
Uno achieves similar goals to Xamarin.Forms/MAUI. It's also based on .NET.
Main differences are that it also targets Linux+WebAssembly, and it's meant to be Pixel-Perfect so it would look and behave the same on all platforms by default.
It also offers a variety of additional packages out of the box and aims to be an end-end platform instead of solely a UI framework: Hot Reload, C# Markup alternative, a toolkit of mobile-first controls, design systems, reactive state management (MVU-like), recipes for Authentication/Navigation/Logging/DI/...
These "additional packages out of the box" , particularly the Auth/Nav/Log etc ... also have FOSS licensing??
Yes
[dead]
[flagged]
Problem with it? It's good enough for the millions of web pages out there.
If you scroll down there is support for a pure C# builder API too which looks quite nice.
Comment was deleted :(
Crafted by Rajat
Source Code