💾 Archived View for dioskouroi.xyz › thread › 29405909 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
➡️ Next capture (2021-12-05)
-=-=-=-=-=-=-
________________________________________________________________________________
From their home page:
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
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.
> In case anyone else was confused as to why a card game was launching a platform
I was, actually, having written a Reversi game in the past. So thanks! :)
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).
Not sure why you're getting downvoted. This is the whole point of typescript in my eyes. Those red squiggles before you even save the file.
People are displeased when you inform them their 5 year old view of JS and React is indeed outdated, I suppose.
> need to download the whole internet when I want a simple function like left pad
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.
Xamarin (soon to be MAUI) is the best option in my opinion, especially if you enjoy C#.
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.
Every "native feeling but glitchy mess" app I've had the displeasure to use turned out to be RN.
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.
Besides it’s finicky, cumbersome, and unstable.
React native desktop is still experimental, the current version is 0.66 and not really that stable.
A huge strength of Xamarin is how easy it is to use the native platform APIs and things like real multithreading in C#.
> Lots more devs, documentation, industry-use, etc. in the React world. Serious question.
Don't forget that C#/.NET has its own rich ecosystem.
Not sure what React has to do with anything, this is a UI framework for .NET.
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?
1:
https://calculator.platform.uno/
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…
It has worse problems than performance. It’s not a calculator, it’s random number generator.
Steps to reproduce: click “C“ with the mouse, then type on numeric keypad 2 * 2 {enter}
Expected result 4, actual: 0.
6 seconds to load
35.8 mb of ressources
for a calculator...
how can people be fine with that and press the publish button?
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.
The same way they can be fine with a bash processes having 24 megabyte VM footprints.
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.
That does seem weird. Just checked my bash processes and none exceed 13 megabytes of virtual memory
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 patches
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.
The same that would otherwise create a react app to display static text or an image gallery.
What’s the difference between this, Avalonia, and MAUI?
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.
Thank you this helped a lot.
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).
Here is a good high level of Uno:
https://www.youtube.com/watch?v=fyo2BI4rn0g
Doesn't maui also support mac/linux? Do a lot of people use xaml? I would have thought you could write the ui's directly in C#.
edit: it looks like xaml is optional with the community toolkits
https://devblogs.microsoft.com/dotnet/introducing-the-net-ma...
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.
Maui does not (at present) offer Linux support. There's a community effort, but AFIAK it hasn't gotten a lot of steam yet.
TL;DR:
* 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.
I've been wondering who's developping Uno, what's their business plan? Is it like Red Hat, people are paying for support agreements?
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.
Do you know how they make money? Qt also started being free and open-source, and that, of course, changed over the years.
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.
You can see the team and some background here:
https://platform.uno/about-us/
It says it's using Skia for Linux. I am wondering since Skia isn't bound to any platform, why not just use it for all 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.
What's the difference between this and Blazor?
Blazor is a way to run native code in your browser. Uno is a way to run UWP code as a cross-platform app.
It's slightly more complicated now that we also have Blazor Hybrid:
https://devblogs.microsoft.com/dotnet/hybrid-blazor-apps-in-...
.
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!
I really hate how Blazor grew into yet another GUI stack war at Microsoft.
It appears everyone is competing for the GUI stack to rule them all, while appearing to be good old friends to the outside.
Complete lack of direction and vision, for sure
Came into this thinking it was some game platform for the Uno card game, left disappointed.