Uno Platform 4
platform.uno
platform.uno
> 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
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.
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.
I was, actually, having written a Reversi game in the past. So thanks! :)
If you are already locked-in to .NET, then it's a different question.
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.
No wonder that MAUI isn't being used on the VS for Mac rewrite.
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).
That can't be the reason. These kinds of projects don't address that problem. In the ordinary case, it's usually made worse by a factor of 2–10.
> Lots more devs, documentation, industry-use, etc. in the React world. Serious question.
Don't forget that C#/.NET has its own rich ecosystem.
Besides it’s finicky, cumbersome, and unstable.
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?
Not defending or excusing it, or doubting your results - I guess mostly lamenting we don't have more consistent performance across platforms...
35.8 mb of ressources
for a calculator...
how can people be fine with that and press the publish button?
kaz 22301 0.0 0.0 25188 7264 pts/2 Ss+ Nov03 0:02 bash
kaz 25976 0.0 0.1 27268 9632 pts/1 Ss Nov16 0:08 bash
kaz 27179 0.0 0.0 24368 6704 pts/0 Ss Nov16 0:01 bash
^^^^^ ??
EMACS = Eight Megabytes and Constantly Swapping used to be a ha-ha only not funny joke. PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2048 REDACTED 20 0 12852 1844 1816 S 0.0 0.0 0:00.01 │ bash
Ubuntu 20.04 with latest patchesI 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.
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.
Steps to reproduce: click “C“ with the mouse, then type on numeric keypad 2 * 2 {enter}
Expected result 4, actual: 0.
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).
Here is a good high level of Uno: https://www.youtube.com/watch?v=fyo2BI4rn0g
edit: it looks like xaml is optional with the community toolkits https://devblogs.microsoft.com/dotnet/introducing-the-net-ma...
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.
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.
* 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.
I have no involvement in this project however, so this is just speculation.
Blazor is two things at the moment:
- 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!
It appears everyone is competing for the GUI stack to rule them all, while appearing to be good old friends to the outside.