It's always nice to see cross platform UI solutions, even though in general there are always some quirks. Also there's just something nice about being able to preview the supported components online, in a webpage, for example: https://xamlcontrolsgallery.platform.uno/
It even seems to generate proper HTML, instead of using a canvas like some other solutions, which sidesteps a plethora of issues.
That said, loading the gallery meant 24 MB of assets, 6 MB with compression still, which does feel kind of heavy. That said, I kind of understand why, seeing as dotnet.wasm was about 12 MB of that (a bit above 2 MB when compressed).
So in a sense, we're getting close to being the same size as React, Angular and Vue applications, though still an order of magnitude off, which may not be good enough for some.
That said, loading the front page of Reddit (new design) is also about 7 MB of content, so clearly people prioritize the content/looks over download sizes, though the overhead of WASM solutions still cannot be ignored.
On the desktop, however? It feels to me like more non-packaged-webapp options are nice, even like JavaFX/OpenJFX since the performance and resource usage of those can still be better than that of a packaged browser. One might also suggest to always try to use the native options, but I'll take what I can get.
Uno Platform CTO here - About the Xaml Controls Gallery on Wasm, the issue is on our side and we'll update our websites. This specific demo webapp has not been updated in a very long while, and a very recent one to try Uno out is https://gallery.platform.uno for a more accurate representation of the perf/size/features characteristics.
About the payload size of the app, this is still very much a work in progress on all fronts, whether it being missing WebAssembly features, size optimizations on the dotnet front, or linking/trimming (IL and native) opportunities on Uno's generated code side.
On the performance side, threading is coming, AOT (IL to Wasm) is improving significantly in .NET 7 and more coming in .NET 8 to reduce the size of the payload by using newer WebAssembly features (albeit at the expense of older browsers).
We know that Wasm-only apps will still be at a disadvantage for while when compared to JS frameworks simply because browsers are offering a lot out of the box (standard JS library, GC, Runtime, HTML layouting/rendering, more advanced JIT, etc...) but that gap may eventually narrow down as Wasm evolves, making the porting and development of webapp using many established language ecosystems an attractive choice.
One would think the visuals of WinUI would lend itself to a lean implementaion in HTML.
I think the problem with XAML is, that it is not really declarative. Declarative would be: "I want a list/detail view, and the detail view has the following actions." and then you apply a theme for look&feel. Rather, you quite explicitly place rectangles, borders, and so on, in a scene. In UNO, a button doesn't translate to a HTML button, but to four nested <div>s and a <p>.
Every 6 months or so, I take a quick tour through all of the various cross-platform UI frameworks out there. Most of which, with the notable exception of Flutter, are C# and .NET Core based.
I'm just wondering... does anyone actually have success using any of these frameworks from a context other than Visual Studio on Microsoft Windows?
I'm on a Mac, install .NET through Homebrew, and use Rider when I dabble with C# stuff, and I've just never had a smooth experience getting ANY of these things to work. Even for "Hello World" test apps. MAUI, Avalonia, Uno, I'm probably forgetting another one. None of them actually work on my machine.
I always get the feeling that someone, somewhere, at one point got "Hello World" working on a Mac... wrote up a doc saying that it's supported... and then the doc immediately fell out of date. I feel like the only Mac user on earth touching any of these things every time I experiment with them.
I actually got Avalonia working with VSCode in Linux, but neither with Hot Reload nor any other bells or whistles. Just compile and run. It's okay, but it's clearly a second class experience.
I was able to get through the .NET install, and "uno-check" process without much issue.
However, the screenshots on this page show a Solution file with a "MyApp.macOS" project inside. I generated the "MyApp" skeleton project using the verbatim bootstrap command "dotnet new unoapp -o MyApp"... but the generated solution does not include a "MyApp.macOS" project inside.
After a lot of experimenting, I discovered that the WASM-based implementation actually does run. Even though it requires me to enter my root password every time it starts the development HTTP server (WTF?).
I mean... a fresh install, following the published instructions step-by-step verbatim, should produce a "Hello World" skeleton project that matches the doc. Just saying.
I'm not aware of any 3rd party that can afford to both offer an open core product and keep up with Microsoft, a company infamous for "fire and motion" - attracting developers to the next new thing.
I feel like this is a muscle-memory comment, reflexively farming for upvotes without reading what I actually said. I didn't raise an issue about keeping up with Microsoft, I raised an issue about support for non-Microsoft platforms.
Of course I'm farming for upvotes, isn't that what HN is all about? ;)
Sorry if I wasn't clear -- as you mentioned, Microsoft and others are barely supporting non-Microsoft platforms.
> then the doc immediately fell out of date
Not sure how I can be responding more directly to what you wrote... there's a lot of motion right now! No one will keep up (polished DX) without significant funding. This means non-Microsoft platforms don't get the love they need (not priority #1 for Microsoft, and no one else is close).
I’m a Net developer since 1.0 (and before that), but Silverlight really burned me on XAML. I want to like it, but inevitably end up thinking JS/HTML are better in most cases. For all its faults, JS is something more developers can understand. My typical stack is c# backend, JS/html (ie vue, angular, alpine,etc) front end, and ionic framework for cross plat mobile. MS is pushing MAUI pretty hard, which is also XAML based. Would love to hear some counter opinions as to why XAML > JS+HTML.
There is the Blazor Hybrid option with .NET MAUI. You write your UI using Razor (HTML + C#) and can use native controls and features when needed. As a .NET dev who prefers HTML to XAML, this feels more natural to me for a lot of apps.
I have been doing GUIs since the Windows 3.x days, and Web since around 1996.
With XAML I can make the page actually look how I want, master styles control templates and so one
on, with Web I have given up on that, better leave the designers turn a div soup into a combo box with the right behaviours, assuming enough CSS magic is added to the potion. Then rince and repeat for every browser on the support matrix.
Uno CTO here - We're always chasing performance issues in WebAssembly and I'm curious, are you still seeing the 5 second delay when the app has been loaded once and refreshing? We know that mobile browsers are not particularly efficient with Wasm on mobile devices (particularly iOS), but you may be in a different scenario and/or device.
On a desktop in Chrome, with a fairly powerful processor, its taking ~4 seconds to show the calculator after it makes the call to Uno_UI_Windows_UI_Xaml_Application_Start_Windows_UI_Xaml_ApplicationInitializationCallback.
It takes 5-7 seconds to load in Safari on a M1 Max Macbook Pro, whether on first load or after refreshing. The reason is simple: you have to download all/most of dotnet in wasm form before anything can even begin to run.
I doubt there's anything you can do. It will probably work fine for corporate intranet sites and back office apps with some aggressive caching.
I'm on a Fairphone 4 using Firefox Mobile. Probably not the most common use case, but it looked like things were failing and I nearly gave up. I'd recommend keeping a few not-cutting-edge CPU devices around and run them with both Chrome and Firefox.
Thanks for the details! We do have lower-end devices to try with, and it's definitely not the best experience. We're currently pinning on the JIT, but troubleshooting is still difficult... much to do in that area.
The native app version of the app generally fares better, even we still have some improvements to make here (the new Android 13 JNI improvements are likely to help us a lot).
Firefox Mobile on a Samsung Galaxy S21 FE 5G with 8GB of ram, I've now been waiting for over 9 minutes for the gallery.platform.uno to load... The bar pretty much stopped moving at about 55% - 60% at minute 2 or so...
THis is where I give up.
Edit: I reloaded right after posting the above, and the gallery loaded immediately as a result. Something's wrong with the loader.
I'm on a (wired) multi-gigabit internet connection, and saw some kind of splash screen in Safari. Gave up after 15 seconds while thinking "this has the same qualities as all the other XAML-based platforms".
MAUI is Microsoft's attempt to fix the mess that is Xamarin Forms. The "evolution of Xamarin Forms" means it was rebranded to disassociate itself with the historical baggage. However, it is bug driven development at its worst. Use Flutter if you want something cross-platform that actually works.
Uno seems great. What surprised me is that it seems more successful than Codename One which has been around longer and works with Java/Kotlin.
If Java is more popular than C# (which pretty much every survey confirms), how come Codename One didn't pick up more traction. What did Codename One do wrong?
Probably the #1 most popular, mature, and likely-to-actually-work-on-your-machine cross platform UI framework today is Flutter. And there are very few programmers out there who would otherwise be touching Dart (its implementation language) with a ten foot pole.
I understand that Hacker News is a place where "... written in Rust!" is often a sure technique for making a post reach the front page. But the reality is that implementation language has very loose coupling with real-life success.
Dart, if I remember rightly, was originally Google's attempt at replacing JavaScript. Embedding it in Chrome didn't happen so that's where the pivot to powering Flutter happened. I think it's one of those cases where it's less that there's anything wrong with the language, so much as it doesn't really have a reason to exist yet other than the one framework it is used in.
As far as these cross-platform frameworks go, being written in a popular language guarantees nothing. I've pointed out before there's a bunch of random obscure frameworks out there that use Python that have fairly low traction. Which always made me wonder why they were being created in the first place.
I'm not sure I would say Java is native on Android. Sure, most Android apps run on the JVM, but it's not strictly necessary. Google has even released a Native Development Kit that lets you write code in C/C++.
This works through JNI. It will work fine as long as you don't use Java/Kotlin stuff. Then you will need to traverse back into the running VM. That has a serious overhead of going in/out of the VM. Since the Android UI is built in Java C code that tries to work with it is slower.
Notice that this isn't true for games which interact with the hardware directly in C. Only for high level UI stuff.
Sure. My point is, the hardware is not directly executing Java bytecode, so I don't think I would say Java is native to Android in the traditional sense of the word. Google themselves make the distinction between Java code and native code.
It's more comparable to Flutter than MAUI. Since all the controls are custom rendered to be "look-a-likes" rather than genuinely native. Naturally, the look-a-like approach to cross-platform apps does have some drawbacks - namely that it is always lagging behind the bleeding edge of the native platform controls. But for certain categories of app this is not a major issue.
.NET MAUI is an evolution of Xamarin.Forms developed by Microsoft. The Uno Platform and also Avalonia are third-party solutions. All three use slightly different flavors of XAML, to my knowledge.
MAUI looks promising. I just hope that microsoft address the crazy anount of bugs that xamarin had. To this day I’m still not sure if they’re lack of resource or prioritisation for xamarin.
I have a pretty non trivial commercial app in Xamarin Forms (currently just Android) and we really never found any showstoppers. (Talks to other devices via usb/ble, talks to the cloud and does realtime display state and live mapping etc.)
if you have been following bugs in xamarin you would have known. It's good that you haven't encounter any that's blocking, but for those who did it's very frustrating
it seems like it's catching up to MAUI as well, look at the number of issues that's growing for the past 4 months...
I don't know the advantages, but a big disadvantage for me is the lack of Linux support, whereas Flutter has a steady growth in this field. Well, the last time I checked at least, this was my perspective.
It even seems to generate proper HTML, instead of using a canvas like some other solutions, which sidesteps a plethora of issues.
That said, loading the gallery meant 24 MB of assets, 6 MB with compression still, which does feel kind of heavy. That said, I kind of understand why, seeing as dotnet.wasm was about 12 MB of that (a bit above 2 MB when compressed).
So in a sense, we're getting close to being the same size as React, Angular and Vue applications, though still an order of magnitude off, which may not be good enough for some.
That said, loading the front page of Reddit (new design) is also about 7 MB of content, so clearly people prioritize the content/looks over download sizes, though the overhead of WASM solutions still cannot be ignored.
On the desktop, however? It feels to me like more non-packaged-webapp options are nice, even like JavaFX/OpenJFX since the performance and resource usage of those can still be better than that of a packaged browser. One might also suggest to always try to use the native options, but I'll take what I can get.