.NET MAUI: .NET Multi-Platform App UI
github.com
github.com
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.
I can’t comment on your specific circumstances because I don’t know the details, but this reads like someone who is drinking the blazer coolaid.
It’s a technology like any other, with specific trade offs.
If you have a front end team who lacks the basic competence to do something that takes four hours in blazor in less than 4 weeks, then maybe it’s a good trade off.
...but in most cases, for most people, that won’t be the case.
It’s also quite slow, hard to integrate with existing js technology (ie bridge) and very difficult to debug production issues with in my experience.
We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc.
There is little-to-no context switching when operating with one of these codebases. The notion of "front-end" and "back-end" is completely meaningless here. The "back-end" is literally an F12 keystroke away from the "front-end".
> and very difficult to debug production issues with in my experience
What sort of production issues have you been encountering that were difficult to track down? I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.
So to start with, a disclaimer: I carry some baggage here, from working occasionally on 10+ year old GWT app that's developed into quite a tangled mess.
Having said that -- this sort of thing doesn't seem like an obvious win to me. The notion of "front end" and "back end" represents a real-world distinction that you want to pay attention to. Making it too hard to see, or too easy to communicate across, brings some risk of losing track of which is which, and putting logic that belongs on the server into the client or vice versa. Or having the two communicate with each other much too often, which may not cause any noticeable problems during development, but, in production, can cripple the site for users with higher-latency Internet connections.
Blazor server-side has no distinction though because everything is running on the server, and the UI is just a thin stream of HTML updates.
The model you choose is up to you based on resources, latency requirements, payload size, etc. Blazor just gives you more ways to get things done.
OurApp.exe:
SQLite <-> C# Services <-> Razor Components
I would not currently argue for developing blazor server apps as a replacement for 100% of web applications. But, there are situations where you have a constrained user base and predictable performance characteristics which provides enough confidence to go all-in on a single fast box.
Now, you certainly can run LINQ client-side if you were on a Blazor WASM (or hypothetically, Desktop) application. This is kind of the entire point of the stack.
That’s a local development environment.
Have you had similar experiences when dealing with deployed applications? How did you do it? It’s rather more difficult when, eg. You can’t have a copy of visual studio there to use on your production deployments.
The productivity improvements are real. Not having to design and expose an API for the frontend and instead just reuse the same classes and services is a massive shortcut. Running Blazor on the server is even easier because there's no serialization at all and you can directly call database queries in response to UI events.
I suggest watching some of the Blazor presentations to see just how much complexity can be built in minutes compared to more traditional frontend frameworks: https://www.youtube.com/watch?v=CEjqhTGrqDY
Different teams is a business organization problem, and if you have that problem, you just aren’t going to choose the kind of server-side-code-with-generated-frontend framework that Blazor is (and of which there are several besides Blazor), so it doesn’t solve any problem there.
Different languages without different teams is a much smaller problem.
I think the killer feature is that it will work on any platform with a decent webview control (Windows will finally be joining that club soon when WebView2 ships in-box), including MAUI; so you can use the native hosting bits of MAUI and the web UI bits of Blazor, no XAML required. And then you can reuse that same UI on another platform or a web browser, trivially.
Hot reload for Blazor dropped in the recent .NET 6 preview 3 so this is a really good time to get started with it. It blows XAML Hot Reload out of the water because it can reload many C# changes in addition to HTML/CSS changes; XAML Hot Reload breaks down as soon as you need to change any C# code that touches your UI.
You make it sound like it's Microsoft's fault your customers won't move off of Windows 7.
Extended support by MS for Windows 7 means the only reason you're not supporting it yourself is your lack of motivation, and so to your customers (and your own upper management), for a big contract that's not going to wash.
You might even find that their contract even says something to that effect.
And it does not specifically require any paid extended support contract from Microsoft to actually install and run.
After winforms, silverlight, wpf, webforms and WinUI I don't want energy, I want to see them focus for more than 5 minutes. The only stable UI tech from MS with any long term support has been Win32 that came out 25 years ago.
I predict blazor will be quietly dropped (they won't actually admit it for 5 years), just like the others and you'll be forced to rewrite your software in a few years.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
Then you've got things like hiring concerns, $nextJob will want people with $nextTech on their resume, it doesn't matter if something is still technically supported because hiring people willing to work on dead platforms is a tough ask, moreso when the tech is a couple of generations old. This churn isn't happening in a vacuum.
Do you expect software to stand still for decades? Please show which other language stack comes anywhere close to this kind of stability because several of them (go, nodejs, rust) didn't even exist when .NET was first released and running critical systems in major companies.
You can still find COBOL and Fortran jobs if you want to avoid anything new, no need to complain about the industry moving on.
- File Handling, IO, Streams - Data Storage, ADO.NET - Generics, Collections - Linq, Lambdas - Threading, Tasks - Cryptography
I’d just build console apps, which you can do on Windows, Linux, or MacOS.
Just install dotnet-core.
And you want to .NET and not the .NET Framework :).
What tutorial is best, depends a lot on your experience and target.
But for now it doesn't work as well as a classic SPA architecture. The server-side mode works not very well on poor connections (mobile), and the client-side WASM builds are extremely slow. Especially on first load, this takes seconds.
Blazor may be well suited for Intranet apps already, where quick&cheap development is very important, and connections are fast and stable. Blazor Desktop is an example for that use case (no latency between frontend and backend).
For internet apps, something like Gmail or Instagram, it seems to be not very well suited. Especially not for websites with interactive content, for example a comment-box inside a blog. Nobody wants to wait multiple seconds until the content is responsive, or the "reconnecting to server" overlay disappears
Blazor Server: On a broken/poor connection there is no interactivity anymore
Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow
classic SPA: Keeps working with lost connection and is fast.
Why should it be slow? Once Blazor WASM is loaded, it doesn't need a connection to the server anymore.
For example binding select inputs to object is not possible while it has been working in other Javascript frameworks for years. Ofcourse you can use workarounds but it always feels like a step back.
And for some project that use custom auth it can be difficult to auth both Blazor and Controllers if you need some.
But overall it is a great experience. And I think frameworks like Blazor and Liveview are the future.
My rant towards Microsoft:
Get some average students and let them build a real world demo application. Write down all the stupid questions they have and all the problems they struggle with. Consider them as bugs or bad design choices and solve them. Do that before you release stuff.
Microsoft delivers amazing quality in some fields, language design (c# and f#), ASP.NET Core and everything in Micrsoft.Extsions.* is amazing. Also .NET Core was a very successful project (after the hell of PCL and .NET Standard).
But WHY can't you build a proper and usable UI framework?!?!?!!!
I like the shared code. I like that it borrows ideas from VueJS. I like that the recent hot reload efforts have put plugins on the table. I like the VSCode support and debugging experience once I got it working.
I don't like the thought of all the js interopt I will need to do. I don't like thinking about how shimming jointjs is going to go. I don't like the lack of pipeline for working alongside an npm/typescript project for the inevitable js bits that need to be written. I don't like the lack of a preprocessor, bundling, and asset pipeline..
P.S. I hope the culmination of the hot reload work in asp.net will result in official guidance for creating proper plugins (controllers, services, models, assets, Blazor, etc) ala Grails. It feels close with the low level infra gaps being closed.
This is true for Blazor Server as well. I just love the fact that you can generate HTML on the server and have the productivity boost of having to work with a React like component system.
https://devblogs.microsoft.com/surface-duo/flutter-dual-scre...
For me, as a .NET fanboy, they are a year or two late.
BTW, there's a very interesting (and amusing) bug that advocated "dumping Maui for Flutter"
Flutter with its Dart language and an own VM is not a goal for .NET. This is the .NET team building a UI framework for C#/CLR/.NET developers. Flutter is different from WebAssembly (which is more a CPU architecture) in that regards. From a .NET team perspective, they see themselves (most likely rightfully) as a full stack competitor to JavaScript and Java and that requires Browser, Apps/Desktop, Server, Web Pages and native Cloud in the portfolio. Dart, Go and even mighty Python are not in the place were .NET, Java and JavaScript is in this regards (yet and from a non-hacky perspective ;)).
It's the business practices why people generally have bad memories of them.
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.
I love that it isn't created like the old RAD frameworks where you are supposed to easily drop a datagrid in, connect to a DB and basically have some Line of Business CRUD on your screen within minutes. The Telerik/Syncfusion et.al. components are massive bloated and geared exactly towards that, and in order to do that they need to make a ton of assumptions about the MVVM/MVP/whetever architecture of the app. There are a few small omissions from WPF but I wouldn't say that the huge suites from Telerik and similar show that it's lacking.
It's 2021, we're expected to deliver amazing, feature rich software in very little time, without buying 3rd party libraries.
Meanwhile, there's Microsoft, using the funds from our subscriptions and building stuff like Xamarin Forms and abandoning it half-way through. I wish they'd spend less time fooling around, and more time improving the tools that have become bread and butter.
Eh? I've worked on projects using Xamarin Forms, and they turned out just fine.
Yes, it would be nice if there were a few more controls in the main Xamarin Forms library, but I don't see a problem with the community picking up some of the slack (which they have).
Same here, but it is my experience with Xamarin that has led me to conclude that it's the wrong choice almost 100% of the time. Sure, it can be made to work but at the end of the day you're coercing C# to do something it was not designed to do. For mobile I am convinced that PWA/hybrid mobile is the correct choice 95% of the time with the remaining 5% being platform native apps written in Android Studio with Kotline or Java (or Xcode with Swift or Obj-C). Anything else is just an exercise in sticking non-round pegs into a round hole.
Hmm, not sure I can agree with this statement, as I don't see what would make C# itself unsuitable here.
> For mobile I am convinced that PWA/hybrid mobile is the correct choice 95% of the time
But this I fully agree with :)
While the Xamarin Forms projects I've worked on turned out well, I feel like the whole experience of developing, experimenting, building, debugging and testing would all have been so much easier with a PWA. A PWA would also make it much easier to build what your UI designer really wants, instead of having to compromise all the time with what is readily available - having CSS at your fingertips makes all the difference.
If you mean I expect to compose my own complex controls out of less complex building blocks, then yes that's what I want and expect.
> Meanwhile, there's Microsoft, using the funds from our subscriptions and building stuff like Xamarin Forms and abandoning it half-way through
I agree WPF and others have been backbenched for 10 years. Microsoft panicked and needed a strategy for cloud and mobile, while they weren't exactly being threatened on desktop. So from a business perspective it made perfect sense: leave desktop for 10 years. Now they are slowly coming back to it with .NET 5 which is nice, but it wasn't very pleasant to be a Windows desktop dev between 2010 and 2020.
It's also why no-one used WPF: without a grid it was worse than Visual Basic 6 for Microsoft's bread-and-butter business customers. This was a huge strategic misstep, as instead of hiring "WPF" developer you had to hire a "Telerik" or (shudder) "Infragistics" developer or spend a coupe of months extra onboarding new hires.
A library with a rich ecosystem of third party vendors instead of the clunky GNU/Linux offerings.
There are a 1000 different ways to implement autocomplete menus and charts; that would be a nightmare to produce or use.
I understand that this is a push for mobile but hopefully a linux support will be considered.
The functional features in C# are not like for like ports of F# features and have very large gaps in the functionality and usage. It's great that C# is looking at F# to try and stay relevant but it's massive dishonesty to claim those features are just the same as those in F#.
The basis and usage of a language are steeped in its construction and usage patterns, F# has a distinct base of applying pragmatic functional programming and simplicity, whereas C# is an object oriented language takings usage patterns from Java and the typical patterns formed from that area. They will never converge due to the huge amassed different historical usage patterns. You could say C# is heading for being the new Scala 2 when Scala 3 has learned the lessons of blindly applying features and has now taken a more reasoned approach.
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.
For who are interested take a look on https://fsprojects.github.io/Fabulous/Fabulous.XamarinForms
- They only work for the newest Windows Build
- There are no compatibility packs to target older Windows Versions (7 or 8) or even older Windows 10 Builds (not even the Windows 10 LTSC)
- They are more proof-of-concepts and feel unfinished. After the release, they only get minor updates
- All the minor updates need the newest Windows Build again
- Your customers ask you if you are crazy, because your software doesn't run on a 5 year old PC, that doesn't auto upgrade to the newest Windows version anymore
Avalonia: https://avaloniaui.net/
Uno Platform: https://platform.uno/
Edit: Nevermind, found one myself:
An internal binary leaked a while ago, someone confirmed the WebView2 aspect: https://twitter.com/teroalhonen/status/1346196838840463360
The other side is Xamarin.Forms and its designated successor MAUI. Here you have the typical Microsoft UI problem. It is quite an unfinished framework. You can build everything with it, but if you do something else than the showcase app, you are going to have a difficult time.
Xamarin is for sure not going to die soon.
Plus you can't share UI code between Android and iOS. You still need to build the UI's natively with no code reuse.
Plus building and cross-compiling between Windows and Mac is hacky and painfully slow.
I wish Microsoft would get rid of Xamarin. Every Visual Studio update has a bugfix for it, usually relating to iOS.
You don't know what you're talking about clearly.
Doing consulting I've done plenty of projects in React Native and played with Flutter a bit but Xamarin really is a great framework.
Utterly false - Xamarin Forms is totally cross-platform UI; you're probably mistaking it for Xamarin Native, which is used as a target renderer for each platform. Look at this sample project: https://github.com/xamarin/xamarin-forms-samples/tree/master...
The .iOS and .Android project folders target each platform respectively, with a single project shared between them that defines UI that is rendered onto each platform. You claim to have experience with using it, but obviously haven't done anything even as simple as a HelloWorld.
Site note: 5 eliminates "framework" and "core"; 5 is technically a descendent of the core family (also skipping 4.x versioning, as it overlaps with framework 4.x), but satisfies all the requirements of apps that use framework 4.x. Ergo, "framework" is available on non-Windows targets and you no longer need to choose.
Xamarin also produced an entire UI framework. WinUI 3 (/w MAUI for non-Windows) is the intended upgrade path of Xamarin Forms, while the rest of Xamarin UI that isn't part of Forms lives on either in WinUI 3 or has designated replacements. In many cases, the upgrade is merely changing your `using` lines.
Side note: Uno has been using non-Forms Xamarin UI like this for years, substituting Xamarin's functionality when you're not on Windows.
The other part isn't getting as much buzz ("Xamarin is now just a 'compiler feature' of .NET 6+"), in part because it does seem somewhat "anti-news", it's not a new brand like MAUI or new buzzwords, it's just feature check boxes in a list. That said, you can tell it was a lot of hard work technically and I know a bunch of developers that are excited that there's just one unified tool stack now (you can use the CLI `dotnet` for everything that Xamarin used to do; Visual Studio has some updates to make everything feel even more seamless than it used to, including a lot more improvements to single project multi-targeting instead of needing to create a project per target OS/hardware). That buzz is out there on social media, at least, if it isn't making huge splashes in news sources.
More churn, more abstraction, much of it feels unfinished. This is starting to make Electron look attractive.
Just keep in mind, this is all custom rendering, it is not a native control wrapper. If you want an app that will look like a normal MacOS app on the Mac, this may not be the best choice, and something that wraps native controls (like Xamarin) would likely work better. If you want a UI that looks the same everywhere, it's great.
One advantage is that it works in a very "sane" way - you're just writing a net core app, that's all there is to it, unlike with Xamarin.
A disadvantage/advantage (based on your perspective) is that this is just a UI framework, so you don't get .NET wrappers for all the other, non-UI platform stuff that Xamarin provides. If you need some platform functionality, you have to access that in some other way.
For UWP they made promises for Maui, but GTK is still community owned.
Of course, then the question(s) are what toolkits will this ride over for the platform. It's hard enough getting tray icons working consistently in Linux apps as it is, for example.
I just want to write VB and it work on a phone or a Linux box.
I hesitate to believe Python would exist in the way it does today if Microsoft hadn't treated VB so badly. It's only now being replaced as the default to teach in schools because of its simplicity and readability.
I spent a long time working in a codebase that was half C# and half VB.NET, and after a couple years I could switch between the two without thinking. VB has slightly more verbose syntax but that's about it, they're pretty interchangeable.
I don't hate `Dim foo As Boolean = True` but I wouldn't say it's more simple and readable than `bool foo = true;`.
The 2007 project was a mess when I inherited it - the contractors who wrote it were based in India, and the code looked like a VB6 project. They had not turned on option explicit or option strict. They did not understand how events or event handlers worked - they added handles clauses to methods then assigned a variable with the current instance to make the events happen. It was bizarre. They also did a lot of horribly hacky things because all the variables were basically being treated as variant. There was even a bit of code where they had a select case statement where a Boolean variable was being used as a case... and I mean it was doing a select case on and integer, and one of the cases was a Boolean variable. So it depended on what that was set to as to what the case did. I turned on option strict and explicit, took a deep breath, and fixed the hundreds of errors. It was BRUTAL! I'm not saying this is something that is an issue with VB, that was down to the programmers not being trained properly and making some very bad decisions. But in C# it would have been very hard to make the same mistakes.
By the time I left the 2013 job in 2018, I had divorced myself from almost all of the VB.Net code and I swore I would never touch VB again. So far, so good.
Honestly, because of how much VisualStudio auto-completes code, the biggest practical difference that cause me grief was semi-colons: spend a day working in one language, and spend the next day constantly getting the other language wrong.
I remember back in maybe C#5 days there were somethings that I thought VB was nicer for (though I can't remember or find what they were now), but spending the last years working with modern versions (C#7.3 or C#8) there's nothing at all I miss from VB.
I'm not saying VB is the best language, just that it's the one I find the fastest and most comfortable for me to work in.
As there was never (as far as I know) an easy way to migrate existing apps from VB6 to VB.NET, the main reason to use VB.NET would have been a preference for the BASIC syntax, which I don't think was ever particularly common, this was always just a loud minority. And a significant part of this minority also didn't like VB.NET because even this was too different from what they were used to.
Keep in mind the only 2 good GUI tools at the time, IIRC, were VB6 and Delphi. VC++ and stuff like MFC was overly complicated, and the Java stuff was garbage. As neither VB6 nor Delphi used a C-family language, you had a lot of people using them just because it was a better tool, not because of a preference for the language.
The only thing I like about VB (.Net) is that it supports XML literal notation... which was crazy useful in the mid-2000's when dealing with Flash (it's own XML literal notation) as a data passing option. I know others that utilized that feature well for Xaml applications.
I'd much rather just use C# at this point. Actually, I'd rather use JS (node/deno) or rust than C#.
That's my point. Colleges have been teaching Visual Basic as a starter programming language for decades. Only in the last handful of years have colleges started switching to teaching Python first... after many years of neglect by Microsoft. My local college still has an entire specialization of their CS degree based on VB.
Python is where it is today because Microsoft has steadily ignored the language that brought new CS students straight into the .NET world.
Where? In the US, university-level intro to programming would have been in Lisp, Forth, C, C++, and/or Java before possibly trying something else in the mid 2000s, but I struggle to imagine an American university strong in CS touching anything in the VB namespace (5, 6, .NET) whatsoever.
1. The r/visualbasic subreddit is constantly fighting people trying to use it for very low-effort homework help (just tell me how to do this problem, rather than asking for specific issues). It's literally every other post to the sub.
2. Almost no Visual Basic books are still published today. The few that are, are college textbooks, which explicitly mention them as being part of a degree: https://www.amazon.com/Microsoft-Visual-Windows-Database-App...
Where does one get a degree in writing C#?
That said, despite what MS has said the writing has been on the wall for VB.net since day one and it was only ever a transitional path for VB classic. The companies that never made the transition are the ones you generally want to avoid, the types of companies still using VB are generally using a lot of other dead end tech like web forms or TFS.
Some design decisions in VB stood the test of time remarkably well, dim/var to declare a variable and type declaration on the right now seem to be features of most new languages.
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 :)
Swift with SwiftUI embraced the data oriented way with structs only
They both target resource constrained devices, wich will perform better?
I can already tell, apps with MAUI will be laggy on most android phones, probably less on iPhones since the hardware/OS is just better, just like with Xamarin today
Also abuse of abstraction layers is what makes your programs slow, most of the time, wich Xamarin and now MAUI does a lot too, that's what you get for abusing OOP
In server they could get away with it thanks to their JIT, since they don't care about cold start
But in AOT scenarios, you depend a lot on the quality of the AOT compiler, how well it does optimizations, and how well your code is written to facilitates good optimizations
Again, MAUI is open source, check their code, you'll understand what i mean by "the code is just slow"
People always forget what they program for, mobile devices are constrained devices with constrained resources
Pumping your desktop PC and claiming your benchmark does well doesn't automatically translate to better perf on mobile
Then people wonder why their app drain the battery so fast, and you get 1 star reviews as a result, people doesn't care, that is why i leave 1 star reviews, most of the time
Apple mentioned in their WWDC how they embraced data oriented code for SwiftUI wich gave them great performance by default
you might not see it on your i9 with 64gb of memory
but your mom's android phone will struggle
And slow data structures have yet again has nothing to do with it at all. I guess you mean datastructure containing pointers to objects, which is not always the case, and an implementation detail.
No, I'm not interested in Electron. Blegh.
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.
For example, the most prominent Tk application I'm aware of looks like this on Windows: https://upload.wikimedia.org/wikipedia/commons/2/2b/Scid_4.6... On Linux (where I use it), it looks even worse.
While Qt doesn't use real native widgets on all platforms (IIRC), it at least seems to effectively mimic them under most conditions.
There was an attempt at a GTK backend for ttk on linux, but apparently there were technical difficulties so it was abandoned.
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.
Desktop support is very new and still in beta: https://flutter.dev/desktop
> battle tested
Desktop support is far from the ideal situation(alpha). As far as I'm aware, the iOS jank is still an issue.
Also, it's Google. You never know if it will be around next year which means using it in production is a huge risk.
"Experimental" feels like an odd word choice, if you're truly trying to offer useful information.
[Disclosure: I work on the Flutter team.]
I've been passively looking at Flutter with interrest.
It really is the project to beat. I am not sure how you are gonna drop a framework over C# and compete with a framework/lang combo long term.
That standard makes sence if you have a rigid hardware-like approach
(Of course, that's not a viable test for most mobile frameworks. I suspect that an iOS Xcode project from 2011 would not run without rework, nor an app written for Android Honeycomb.)
Flutter is open source, which provides some automatic measure of protection against obsolescence. And companies like Toyota who are building it into embedded systems like cars that will still be around in 20+ years.
.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.
Xamarin is from Mono and had its own XAML for Xamarin.Forms that underneath have build in Renderers for platform targets.
Xamarin allows Shared or PCL that can be made for each platform iOS, Android, UWP etc. You can use CustomRenderers for each platform to access the native platforms and write code towards them or use Xamarin.Forms.
Xamarin.Forms is what is being replaced really and the porting to .NET 6 for MAUI, with WinUI for the UWP targets.
Both Xamarin and UWP have differing XAML because they had their own for the platforms they were on, Xamarin from Mono, UWP progression from other Microsoft tech. In a way this version merges that more closely but still can access directly. The default MAUI will use these targets per platform. If you override one you can implement it in direct platform. Xamarin is really just an abstraction around the platforms and some shared controls that have pre-baked renderers that do that for you.
I don't really use XAML much though other than a stub to load Main, everything is done in code usually. Same way I build native apps directly, mostly code except where not possible or the team needs to edit them. For Xamarin I use Shared setup where I can use Xamarin.Forms (and soon MAUI) for ContentPages/Controls but where needed you can still use a CustomRenderer and override a control or access some properties that you want to edit, or create entire controls/sets that aren't shared across all targets as Xamarin creates a baseline between them and renders how each platform does. In those custom scenarios you might use UWP/WinUI if targeting UWP. If targeting iOS/Android it may be UIKit/Foundation or Android the Android libs Views/Graphics/Content etc.
The Shared [1][2] setup and Xamarin.Forms or coming MAUI allow you to quickly get the app running on all platforms and then you can adjust as needed for specifics. Or do the whole thing natively per platform with custom and just manage it from Xamarin. It is flexible and great for prototypes quick and getting those to something that is shippable. The Shared setup this way is similar to the handler approach in MAUI where underneath the shared abstraction controls are converted into platform specific but you can do custom ones to override or combine controls.
[1] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...
[2] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...
I would not be surprised if MAUI also gets abandoned halfway through development.
Xamarin.Forms was great for getting prototypes going to get things running then going in and taking areas you need to customize, or all controls, and making them platform specific to the targets.
You can still have a shared library that does Content/Pages and most of the work shared. I don't know if Xamarin.Forms was ever meant to be a full solution but it is ok for prototypes and enterprise, for actual consumer shipped apps more customization was needed and CustomRenderers.
The Shared [1][2] setup this way is similar to the handler approach in MAUI where underneath the shared abstraction controls are converted into platform specific but you can do custom ones to override or combine controls.
[1] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...
[2] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...
- They're going to support MVVM and MVU (MVU is similar to JSX with React).
- You'll be able to target all these platforms from a single C# project. With .NET 5 and earlier, Xamarin required you to have a separate project for each target. This will result in a simpler codebase.
I think there is potential for redemption here -- although I do worry the native widget binding approach still comes with a lot of friction that adds unavoidable complexity. However, Maui's new "handler" pattern for native widgets seems like it could be adapted to support Skia/manually rendered widgets if someone wanted to invest in that non-trivial effort.
From my experience the native widget binding is both the strength and the weakness of the approach. You get to take advantage of battle tested native controls that are fully featured. But if the platforms don't have enough similarity between them to create a cohesive interface then you're battling multiple platforms trying to take advantage of the native features layered in another opinionated model that sometimes can be detrimental to the native performance you're hoping to leverage.
I'm hopeful though.
If it turns out to be XamarinFroms done well, I can dig it.
> Email me david.ortinau@microsoft.com. Stealing is not ok and has not been intended. Happy to work through conflicts.
And it was never renamed.
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?
> "...deliver updates directly to users over the air and out of band."
Whoa. You have my attention.
First party support for hosting and over the air updates is coming before the end of the year.
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.
PWA. FileSystem API is coming.
> Or if Google wasn't the sole effective standards body for it.
Agreed.
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.
.NET Core 2.x (2019), .NET Core 3.x, .NET 5, .NET 6 (Sept 2021)
Will you consider then?
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.
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.
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.
I guess I should be happy my xaml experience is still relevant...
All they had to do was not make it worse than HTML/CSS...
It's admittedly confusing and not all that well explained.
Can anyone help a brother out with a good repo or two that codesplains MAUI decently?
My understanding (based on talks and blog articles) is that it’s basically Xamarin brought up to speed with .NET 6. So it can use the SDK style projects and other modern .NET+C# features. For UI you’ll be able to use XAML (as before), a new model-view-update paradigm, or Blazor.
What is the 2D renderer being used, skia?
Usually the biggest selling point of non web GUIs is being NOT js. If only Microsoft could integrate graalVM in Edge/electron then we could all use our favorite language in the feature complete APIs of the web.
This cycle they're focused on improving 'inner loop performance'. The inner loop of the dev cycle, that is. https://github.com/dotnet/core/issues/5510