The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible. A more recent development that has me very excited is Blazor Desktop:
> This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly how this will be implemented, it offers the chance to simplify the hosting model quite a bit. If everything comes together just right, it will be like using Electron without needing to learn Node.
I honestly believe this model is going to revolutionize front-end development. The productivity uplift of not having to fuck around with JSON APIs alone is worth the price of admission. We already use Blazor (server-side) for several of our webapps. I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on the wire. Need a projection involving 3 collections to produce a table? No problem. It's literally 3-5 lines of LINQ in your razor file. With a "proper" JSON API, you would probably have to fetch 3 different resources to the client or develop a special unicorn method for each unique projection.
.NET 6? Hold up, WPF was never really finished. This is demonstrated by existence of companies which sell lacking components that should otherwise have been included with WPF: Telerik, Infragistics, Syncfusion etc. Heck, creating a Report with out-of-the-box WPF is an unforgettable nightmare.
I, for one, would prefer that Microsoft, instead of pumping all these half-finished "cool new toys", ships stable, performant, feature-complete software. We either have to buy 3rd party components, or write our own components from the ground up. Sure, they provide a Button or a Combobox, but good luck if you need anything slightly more complex, like a searchable GridView, autocomplete Combobox, Charts etc.
F# has barely any dev resources behind it last I checked. Think "fits in one small conference room pre covid". They had more focus on porting F# features than developing the language.
F# will be supported out of the box insofar as it's always able to call into any .NET API.
For a more functional-friendly set of APIs, I've no doubt that the community will need about 5 minutes to put together a solid MAUI back-end for Elmish.
Fool me once shame on you, fool
me twice shame on me. Windows phone/Xamarin, Microsoft really doesn’t understand what mobile developers want. What’s the point in investing to learn something when it will be in the hospice next year.
Lately I've been using AvaloniaUI ( https://github.com/AvaloniaUI/Avalonia ) for all new projects. For most intents and purposes it is much easier to make single UI codebase work across platforms when behavior and look of components does not depend on quirks of native controls (which MAUI wraps).
This. And I'll feel like Microsoft intends a UI framework to have legs when it supports more languages than just C#. Traumatized VB .NET dev over here, who has mostly given up hope, lol.
I just want to write VB and it work on a phone or a Linux box.
> In addition, we are enabling developers to write fluent C# UI and implement the increasingly popular Model-View-Update (MVU) pattern. MVU promotes a one-way flow of data and state management, as well as a code-first development experience that rapidly updates the UI by applying only the changes necessary.
I am very interested in this. Last year I developed a .Net Win UI/UWP app and while I enjoyed the rich library of UI components, I really did not like the weird imperative/declarative hybrid model of building UI, as someone who is so used to React.
I would love to see some better layout fundamentals in this space.
I wonder and hope I can use this with Xbox Game Bar SDK on Windows :)
Any direct experiences using this? I've been looking for a good multiplatform UI for desktop that does Mac/Linux/Windows. Mobile is a nice side benefit. It would be nice to use C# again
FWIW, I'm in the same bucket and I'm leaning toward Blazor. There's a big push in .NET 6 to deliver "Blazor Desktop", which is essentially more native wrappers around Blazor Server: https://github.com/dotnet/aspnetcore/issues/27217
Might not fit your needs (it is bringing web technology to native apps, much like Electron) but I think it has more of a future than XAML. And the underlying technologies (Razor, Blazor Server) have been around for a while so you can get started now even if all the pieces aren't quite there.
edit: rereading the MAUI repo, it looks like hosting Blazor inside a MAUI app will be an option. Nice.
Does Godot the game engine count?
I've seen it used in a pixelorama and some map modeling program. Also it's cross platform with c# support and gdscript pretty easy to understand.
Basically MAUI is the next phase of Xamarin/UWP as that was not fully ported on the UI side in .NET 5 which was the merging of .NET Framework 4.x and .NET Core 3.1.
.NET 6 UI is essentially being replaced with this for .NET 6.
I use Xamarin/UWP quite a bit for apps that also have to target Surface and it is great, the ability to use Xamarin.Forms and/or use CustomRenderers per platform is nice. This should follow similar lines and be ready for .NET 6 which is really the true final step in merging the .NET branches and fully making it cross-platform to the app level.
Microsoft has truly been on the cross-platform aim for a long time now which makes developers happy, they do want to push users to use Azure which is really the new OS to them, but are open about platforms which is nice.
This will be a great way to get apps across all platforms and another iteration of Xamarin which is excellent for that.
I'm an absolute huge fan of all things .NET but I'm honestly a little hesitant about MAUI for now. Just feels a little early and duct-tapped? I also had a poor experience with Xamarin years ago...
Flutter is such a good experience for us right now. I'd love "Flutter but in C#" which I think is what they want to do with Xamarin.Forms. Is it ready?
The real "Write once, run anywhere" technology is the open web platform. Now with SIMD, WebGPU, Houdini, and more. Container queries built-in for responsive layouts. Run on touchscreens, virtual reality, desktop and more.
I expect HTML/CSS/JS performance optimization to be valued as a skill more. It is arguably great cross-platform technology (though lacking native widgets), but it has a lot of performance footguns, which we need people to be disciplined about.
If the "open web platform" stops requiring an entire Chromium engine in the app, I would agree. Or if Google wasn't the sole effective standards body for it.
Sure, but there are still reasons you might prefer a native app. For instance, maybe you're writing an application that's meant to do stuff with the file system. You _can_ just run a local Web server and use the browser, but a local app might be a better experience.
I would say I'm hopeful for this to bear fruit. MS is in a much different position today than in the past. That said, my opinion still generally stands, When I see 3 versions from MS with cross platform support, at that point I'll consider it.
For me, without a supported Linux target, it's pretty much a no-go. Having a single UI platform that gets you most of the way there is really nice. Part of why I actually like the embedded web options out there. If this gets a Linux target and shows decent output for Mac, Windows, Linux, Android and iOS, it will gain a lot of market share. For many, lack of Linux isn't even an issue, and that will likely spur some early adoption.
Those who have been burned by Silverlight or Xamarin.Forms in the past, let alone other options, will be far more cautious.
I don’t get why MSFT keep making the same thing over and over again. Who really cares about these abstraction layers. They produce junk apps by people who rarely care to keep up with them and go obsolete quickly.
It's great! Iteration in the space is greatly appreciated by me. Eventually we will get the cross platform UI layer that just works. We will not get there by just running Electron, React Native and others. I am super happy MSFT is having go after go at this!
That said, a decade ago I was not happy about .NET apps, but now they are already better than the norm --- besides the noticeably startup time, "only 2-3x more" memory consumption than the equivalent native app, and occasional pauses in the UI (GC?) they feel far more native and efficient than anything web-based.
I'm a long-time Win32 programmer, so everything else feels slow and bloated.
That thing is almost useless for the rich GUI I usually work on. I often need to integrate hardware-rendered pieces: 3D content, hardware decoded video, images computed by CUDA, etc.
Technically the web has comparable things, WebGL and video element, but they are very limited compared to native stuff. Also usability is not great, JavaScript is too different from C and all these low-level multimedia related things are essentially C APIs.
FWIW, this will be supporting Blazor in addition to XAML. So you can have a MAUI app that just handles native hosting etc. and shows your actual UI in a web view.
It's admittedly confusing and not all that well explained.
[+] [-] bob1029|4 years ago|reply
https://medium.com/young-coder/blazor-desktop-the-electron-f...
> This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly how this will be implemented, it offers the chance to simplify the hosting model quite a bit. If everything comes together just right, it will be like using Electron without needing to learn Node.
I honestly believe this model is going to revolutionize front-end development. The productivity uplift of not having to fuck around with JSON APIs alone is worth the price of admission. We already use Blazor (server-side) for several of our webapps. I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on the wire. Need a projection involving 3 collections to produce a table? No problem. It's literally 3-5 lines of LINQ in your razor file. With a "proper" JSON API, you would probably have to fetch 3 different resources to the client or develop a special unicorn method for each unique projection.
[+] [-] dt3ft|4 years ago|reply
I, for one, would prefer that Microsoft, instead of pumping all these half-finished "cool new toys", ships stable, performant, feature-complete software. We either have to buy 3rd party components, or write our own components from the ground up. Sure, they provide a Button or a Combobox, but good luck if you need anything slightly more complex, like a searchable GridView, autocomplete Combobox, Charts etc.
[+] [-] alskdj21|4 years ago|reply
I understand that this is a push for mobile but hopefully a linux support will be considered.
https://github.com/jsuarezruiz/forms-gtk-progress/issues/31
[+] [-] bokchoi|4 years ago|reply
https://github.com/dotnet/net6-mobile-samples/tree/main/fsha...
[+] [-] eyegor|4 years ago|reply
[+] [-] airstrike|4 years ago|reply
[+] [-] mumblemumble|4 years ago|reply
For a more functional-friendly set of APIs, I've no doubt that the community will need about 5 minutes to put together a solid MAUI back-end for Elmish.
[+] [-] adelarsq|4 years ago|reply
[+] [-] Ecstatify|4 years ago|reply
[+] [-] tonyedgecombe|4 years ago|reply
More churn, more abstraction, much of it feels unfinished. This is starting to make Electron look attractive.
[+] [-] zerr|4 years ago|reply
[+] [-] lostmsu|4 years ago|reply
[+] [-] tracker1|4 years ago|reply
[+] [-] cbHXBY1D|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] fartcannon|4 years ago|reply
[+] [-] ocdtrekkie|4 years ago|reply
I just want to write VB and it work on a phone or a Linux box.
[+] [-] madeofpalk|4 years ago|reply
I am very interested in this. Last year I developed a .Net Win UI/UWP app and while I enjoyed the rich library of UI components, I really did not like the weird imperative/declarative hybrid model of building UI, as someone who is so used to React.
I would love to see some better layout fundamentals in this space.
I wonder and hope I can use this with Xbox Game Bar SDK on Windows :)
[+] [-] JamesSwift|4 years ago|reply
[1] - https://github.com/dotnet/Comet
[+] [-] tomc1985|4 years ago|reply
No, I'm not interested in Electron. Blegh.
[+] [-] aidenn0|4 years ago|reply
I don't think Tk runs on iOS, which is why Tk is usually disqualified in "multiplatform" recommendations
MAUI and Xamarin.Forms both have "okay" linux support last time I checked.
[+] [-] ripley12|4 years ago|reply
Might not fit your needs (it is bringing web technology to native apps, much like Electron) but I think it has more of a future than XAML. And the underlying technologies (Razor, Blazor Server) have been around for a while so you can get started now even if all the pieces aren't quite there.
edit: rereading the MAUI repo, it looks like hosting Blazor inside a MAUI app will be an option. Nice.
[+] [-] worble|4 years ago|reply
[+] [-] miohtama|4 years ago|reply
[+] [-] kreitje|4 years ago|reply
[+] [-] tomc1985|4 years ago|reply
[+] [-] bionade24|4 years ago|reply
[+] [-] powerlogic31|4 years ago|reply
[+] [-] drawkbox|4 years ago|reply
.NET 6 UI is essentially being replaced with this for .NET 6.
I use Xamarin/UWP quite a bit for apps that also have to target Surface and it is great, the ability to use Xamarin.Forms and/or use CustomRenderers per platform is nice. This should follow similar lines and be ready for .NET 6 which is really the true final step in merging the .NET branches and fully making it cross-platform to the app level.
Microsoft has truly been on the cross-platform aim for a long time now which makes developers happy, they do want to push users to use Azure which is really the new OS to them, but are open about platforms which is nice.
This will be a great way to get apps across all platforms and another iteration of Xamarin which is excellent for that.
[+] [-] ghuntley|4 years ago|reply
[+] [-] MayeulC|4 years ago|reply
[+] [-] vyrotek|4 years ago|reply
Flutter is such a good experience for us right now. I'd love "Flutter but in C#" which I think is what they want to do with Xamarin.Forms. Is it ready?
[+] [-] crazypython|4 years ago|reply
I expect HTML/CSS/JS performance optimization to be valued as a skill more. It is arguably great cross-platform technology (though lacking native widgets), but it has a lot of performance footguns, which we need people to be disciplined about.
[+] [-] ocdtrekkie|4 years ago|reply
[+] [-] emodendroket|4 years ago|reply
[+] [-] tracker1|4 years ago|reply
For me, without a supported Linux target, it's pretty much a no-go. Having a single UI platform that gets you most of the way there is really nice. Part of why I actually like the embedded web options out there. If this gets a Linux target and shows decent output for Mac, Windows, Linux, Android and iOS, it will gain a lot of market share. For many, lack of Linux isn't even an issue, and that will likely spur some early adoption.
Those who have been burned by Silverlight or Xamarin.Forms in the past, let alone other options, will be far more cautious.
[+] [-] rubyfan|4 years ago|reply
[+] [-] monkmartinez|4 years ago|reply
[+] [-] xnyan|4 years ago|reply
I give them props for trying. There's nothing I would use (yet), but I do respect the grind and trying to move past failed attempts.
[+] [-] userbinator|4 years ago|reply
That said, a decade ago I was not happy about .NET apps, but now they are already better than the norm --- besides the noticeably startup time, "only 2-3x more" memory consumption than the equivalent native app, and occasional pauses in the UI (GC?) they feel far more native and efficient than anything web-based.
I'm a long-time Win32 programmer, so everything else feels slow and bloated.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Const-me|4 years ago|reply
Technically the web has comparable things, WebGL and video element, but they are very limited compared to native stuff. Also usability is not great, JavaScript is too different from C and all these low-level multimedia related things are essentially C APIs.
[+] [-] teryyy|4 years ago|reply
[+] [-] dnndev|4 years ago|reply
I guess I should be happy my xaml experience is still relevant...
[+] [-] stefan_|4 years ago|reply
[+] [-] the_only_law|4 years ago|reply
[+] [-] ripley12|4 years ago|reply
It's admittedly confusing and not all that well explained.
[+] [-] miguelrochefort|4 years ago|reply
https://github.com/unoplatform/uno
[+] [-] sasakrsmanovic2|4 years ago|reply