Doesn't Dart+Flutter cover all those platforms as well? Also Delphi is 90% way there (still ways to go on wasm I believe). So not really "first and only"...
Yes but Dart although an OK language is clearly not up to C# brilliance.
A lot of libraries don't exist in Dart or are platform specific (for example you can do SFTP only on Android and iOS, but not on desktop).
On the other hand, Flutter as a UI framework is much better than anything Microsoft makes (and they make a lot!). It's way more easy to build something beautiful with flutter.
Is Flutter Desktop not still in beta? I'm not sure, the dart website looks like it would be finally released as stable, but we all know how it works with the big G and their projects ;)
Missing lib's are a big point, but we have to take the age of both languages, the size of their communities and the intended purpose into consideration.
C# was released around 2000 massively pushed by Microsoft with Desktop as primary target. Dart was released around 2010 or 2011 and was more or less intended to be a web language like JS/TS IIRC.
What's the point of going this route when things like React native exist for cross-platform dev? Lots more devs, documentation, industry-use, etc. in the React world. Serious question. Is it just performance?
Web dev allergy in my case. You probably don't see it anymore, but for someone that didn't start with it, it's very convoluted and seems very brittle.
I want a compiler that colors my code red when I make a mistake, not an environment that behaves like nothing happened.
I don't want to juggle 3 different languages, need to download the whole internet when I want a simple function like left pad.
Although I despise what MS stands for, C# is a joy to use. I can't comment on Uno, I chose Flutter for my mobile needs, mainly because MS still hasn't got its shit together as far as UI are concerned.
> I want a compiler that colors my code red when I make a mistake, not an environment that behaves like nothing happened.
This is what any half-decent React and TypeScript app will do for you. I write fully typed applications in TS & React and any typo, call site update, interface change, or other mistake you can imagine surfaces a TS error, in my text editor, with helpful text editor highlighting 90% of the time (sometimes the IDE is slightly different than the console).
I went directly with Flutter so I don't have any experience with Xamarin. However I have read a lot of bad comments about it, they say it's buggy and frustrating.
Xamarin.Forms is buggy and frustrating, Xamarin.Native (i.e. just native bindings without a huge opinionated framework on top) is really nice. If you know native dev already its a huge productivity boost (with the occasional hiccup).
I don’t think Xamarin Native supports SwiftUI and Jetpack Compose? The thing about the new declarations UIs is they lend themselves really well to something like Xamarin Native. I wish Xamarin would support them.
No, those are new frameworks entirely vs the traditional SDKs. I'm not sure if there currently _is_ a way to generate bindings or not, or if they rely on compiler magic to do their things.
Their way to provide macOS support is to make use of Catalyst, hardly the way to sell having macOS support to anyone that knows the ecosystem, but apparently they act surprised when we point out this to them.
No wonder that MAUI isn't being used on the VS for Mac rewrite.
Ive been pretty disappointed being a fly on the wall of Github during the MAUI transition. I dont see a lot of "lessons learned" from Xamarin coming through in the effort and there are several issues similar to yours where they seem to be disconnected from the dev community on large issues.
I didn’t begin learning coding with web dev. It was C Python Java. I tried web dev later. Both personally and professionally. I just despise it. Maybe because I don’t “grok” it, but that’s how it is. I have noticed this - people who didn’t start with it simply not getting the point of things it does and in the ways it does. Mere mention of word “react” brings disinterest and nausea. I get panic attacks when see those projects’ loooong dependency list and then yarn or whatever else downloading them.
I'm not the OP, but I would guess he was coming at it from an app point of view rather than an implementation environment point of view -- as in, "why should I write an app this way (assuming I could use any language/tools)?"
If you are already locked-in to .NET, then it's a different question.
At a high level there are pros/cons to JS-based frameworks and "compiles to native" frameworks. Performance is one part of that, but also ability to bind to existing native code also, among other things.
I tried the windows calculator app in my browser[1]. My experience was similar to many webasm apps in the browser; it took a large fraction of a second for input to cause a response in the app.
I'd like to try the linux version, but the only linux binaries are for snap, and my distro doesn't support snapd, so can't do that. Anyone know if Uno is married to snap, or if I'd be able to build non-snap binaries on my own?
That's odd - I tried the same page, and felt it was very responsive, up until I did 7+ square root operations. This is in Vivaldi, on a Windows 10 (2.5 year old fairly beefy "gaming") laptop, with a bunch of tabs and Spotify running. I do have uBlock Origin enabled, though even with it disabled that page seems fine to me.
Not defending or excusing it, or doubting your results - I guess mostly lamenting we don't have more consistent performance across platforms...
Firefox on linux, Ryzen 7 2700. Sometimes it's very responsive, but most of the time there's at least a quarter-second lag from when I hit a number to it appearing on the display. I wouldn't be surprised if chromium based browsers are more consistent.
I tried the calculator and it had an even worse version of the iPhone calculator bug for me. The iPhone bug was that the buttons had a cool-down period where they didn’t work after being pressed so if you pressed a button too many times in a short time it wouldn’t work. The bug here was that after pressing a button, everything would lock out for a while, but maybe it’s just a web standards thing or my device being slow.
I don’t know why Uno continues to advertise WASM as a target. It’s a great framework for desktop and mobile but it’s obvious how slow their web demos are. They really shouldn’t advertise it, it’s not suitable for production…
Hi, Uno Platform dev here. We're not fine with the current payload size of the application, really.
It's definitely too large, and that is the current state of .NET running on WebAssembly, where missing WebAssembly features (like exception handling) are forcing the compiler to generate a lot of code to compensate.
Still, we have one issue in this build where the PWA webworker doubles parts the payload, but even at ~25MB, it is still too big even if it is downloaded once and cached. For reference, the original windows version is around 13MB on disk for x86.
The point of the Calculator exercise is to show the ability to port the Windows calculator as-is (though translated from C++ to C#) to multiple non-Windows platforms. We continue working on that to improve the payload size and performance further, following WebAssembly, browsers and the .NET runtime advances.
Then maybe don't showcase it so prominently. I bet this demo is what about 90% of people interested in Uno check out and my perception was certainly "wow, this performs badly", tainting my perception of the whole thing.
I remember a moment from 1994 or so. I was using a friend's machine, which was running X on top of Linux. It was some model of 486. I had some image viewing windows open (xv program), and was editing a complex figure in XFig, and had some audio playing.
I was thinking, "man, this is nicely responsive and usable; how much RAM is in this thing?"
I drop to the shell to run "free" ... 6 megs!
Remembering these things is important, kind of like remembering rivers full of fish, frozen polar ice caps, or the song of an extinct bird.
To supplement the other reply, a big difference is how they approach the cross platform UI.
Xamarin Forms/MAUI is effectively an abstraction layer on top of the Android UI Toolkit and CocoaTouch.
Uno is its own implementation of a UWP compatible UI that renders everything onto the screen using Skia.
You get the same affordances of cross platform .NET, C#, and XAML. Uno gives you pixel perfect cross platform UIs, but loses the native feel, which MAUI preserves, at the cost of writing more platform specific renderers.
I had no idea it also rendered components with Skia I’ll have to give it a go. I gave up C# on mobile for Flutter and I kind of miss C#. The Xamarin experience left a sour taste for me.
Not sure about Avalonia, but for Uno vs MAUI here is a previous comment of mine (in this context Xamarin and MAUI are identical):
Uno is sort of an alternative to Xamarin.Forms aimed at windows developers that aren't happy that Xamarin.Forms uses a non-standard XAML. Uno uses UWP XAML, which is preferred by these users.
The way I like to think of the two frameworks is that Uno is a cross-platform framework that aims to align systems to the Windows way of doing things, while Xamarin.Forms is more of a "do iOS/Android" in same codebase and just happens to also support windows. There is unique value props in each framework (e.g. Uno also targets WASM and Xamarin.Forms targets Samsung Tizen).
Youre right, platform support on MAUI is different than Xamarin so that part isnt necessarily accurate.
A large segment of the community uses XAML yeah. I think it just tends to be those that came to it through .net or those that came to it through native app dev. I prefer C#, and it seems MAUI has a better story around that with its partial focus on MVU style dev.
* Uno is a vendor-led Windows/WinUI inspired and based UI platform that was originally concieved as a way to port modern Windows Apps to other platforms. Since then, it's evolved a lot of different capabilities and paradigms, but ultimately is basically cross-plat WinUI with extensions.
* Avalonia is a OSS platform concieved as WPF with some of the warts removed, and cross platform. It uses a lookless theming and drawing primites instead of native APIs/Controls to render it's UI.
* Maui is a .NET/Msft-blessed platform that is basically a rebranding of Xamarin.Forms with some improvements and renewed investment. It also largely uses native APIs/controls, and has a contruction style that is kind of a mix between WPF and WinForms.
Uno is a product that targets a specific portion of the dev community, i.e. devs who want UWP XAML. It (theoretically) allows you to take an existing UWP app and run it cross platform.
I assume paid development and tangential consulting. I know the owners are a consulting shop and Uno came out of that work. This is all speculation though, I only know of Uno by way of it coming up in conversations about cross platform.
Probably because its origins are as a UWP-first framework which runs natively on platforms that support it. Skia for Linux was likely added on later to allow the original app to run on other platforms.
I think probably because Linux has no true native UI toolkit, and the two that are closest (GTK and Qt) both bring their own sets of challenges that skew the cost:benefit ratio negative, while this isn’t true for the toolkits for other platforms.
I have no involvement in this project however, so this is just speculation.
- Blazor Webassembly: C# + .Net runtime + Razor components, all of this compiled to web assembly, running on the browser as a Single Page Application
- Blazor Server: C# + .Net runtime on the server, + a SignalR (i.e: socket.io alternative) connection between the server, + Razor components (rendered server-side, diff are sent to the client to update the DOM)
But that's not all! To make it even more complicated, Blazor Hybrid (or .Net MAUI BLazor? Names I've seen aren't consistent) has been announced: a .Net MAUI application + an embedded web view + a local interop channel!
> Pixel-Perfect Multi-Platform Applications with C# and WinUI
> The first and only UI Platform for single-codebase applications for Windows, WebAssembly, iOS, macOS, Android and Linux
In case anyone else was confused as to why a card game was launching a platform, or thought it had something to do with Arduino