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.
> 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.
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.
The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim.
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.
> The notion of "front-end" and "back-end" is completely meaningless here.
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 has two modes: Blazor client-side is C# code running on a WASM dotnet runtime. It does have the frontend/backend split. Data still has to be serialized (as HTTP calls since that's all a browser can do) but it's done using the same classes & libraries as on the backend.
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.
Ditto, I've no desire at all for web applications--or heaven forbid clients--to poke directly at a database or cache, or otherwise obviate the need for APIs. One will need to deploy, scale, monitor, and secure those things very differently from one another.
When you have a stack like this, Blazor goes into additional dimensions of productive. Every F5 of the app is a complete stack running without any frustration in setting up databases, containers, message buses, etc. None of the concerns regarding scalability apply when you plan to go vertical.
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.
Not familiar with .NET, but am intrigued by the Sqlite all-the-things bit -- can you run your LINQ queries client-side? (e.g. for offline capable apps)
We use the Blazor Server hosting model, which is inherently incapable of running offline. For our specific use case, this is actually more ideal than any notion of offline capability. In this model, any LINQ would be running on the server.
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.
LINQ is built into the core .NET runtime (and the syntax into C#) and available everywhere (I think LINQ was introduced with .NET 4 and C# 3.0 some >10 years ago). So doesn't matter if client/server or blazor. But you need some kind of LINQ-to-your-datasource adapter (i.e. to Sqlite, MongoDB etc.) which might have different availability depending on your environment (i.e. a Sqlite adapter would clearly somehow depend on a native sqlite client - but AFAIK is available in Blazor through WebAssembly).
> I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.
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 fact that you have to interface between different teams/languages is often a big part of the slowdown.
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
> The fact that you have to interface between different teams/languages is often a big part of the slowdown
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.
Meteor's problems were around performance and features (or the lack of them) IMO, which are not in principle ones that will crop up if you try to unite a stack around a single language.
Yes. A single-server can scale to thousands of concurrent users however it's not recommend for massive public sites. Works great for admin backends though where the usage is known.
I haven't use Blazor but they mentioning about avoiding the json API with all the encoding/deconding that entails sounds nice, plus only doing routing in the backend. These frameworks (liveview, blazor, hotwire, etc...) seem like a nice compromise that can serve well most webapps out there.
Agreed, I really think Blazor is the way forward for .NET UI. It's bittersweet, but: the Windows and .NET teams have failed to deliver a compelling alternative to web UI, and I'm impressed with how well Blazor integrates web UI with .NET.
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.
Xaml hot reload only works on about half of our views at work, and even then it tends to break itself. I've tried net framework, net core, and net 5. The newer targets break less often but we still can't ship net 5 thanks to Windows 7 extended support contracts from Microsoft. It doesn't even compare to blazors implementation. And c# hot reload breaks frequently around asyncs and lambdas.
He has a point, for example now they've finally stopped supporting IE11 you can legitimately say to customers that supporting IE11 is no longer possible because it's a security hole.
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.
> The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible.
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.
Other than Silverlight, the rest are still available today. Microsoft is unmatched in backwards compatibility. How are you being forced to rewrite your software?
.net core broke compatibility with many more, c#/.net is now decoupled from MS legendary backwards compatibility.
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.
Again, you do not need to rewrite anything if you don't want to upgrade to .netcore/5.0 because .NET Framework is still supported and has a long lifecycle tied to Windows itself. You can even write C# 1.0 code and it will still compile and run today without any issue.
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.
What is a good way to learn the .NET framework or a guided path to understand the development hierarchy in .NET.
It seems expansive with tools for everything from web, app and desktop development. Microsoft provides tutorials but it feels like they are all over the place and not really directed.
I'd consider going straight into Dapper. It's where you'll end up anyways if you start worrying about performance. Direct SQL queries and matching projection models allow for much more flexibility in all areas. If you are bad at SQL, EF Core won't save you for very long. Might as well learn it the hard way.
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
SPA = single page application. You can make one entirely in Blazor and can host it on any static file host. Are you talking about Javascript specifically?
Last year I created a Blazor WASM app[1] to get familiar with the tech. It was a game based on the board-game from the 60's called "Acquire". Although it's using the WASM hosting model, I did use SignalR to facilitate the real-time game play between players. The "practice" mode against the crude AI is entirely WASM and can be "played" as a PWA completely offline.
I had intentions of finishing this out, but I got far enough that I learned what I needed to for now. I felt like it was pretty good considering it's probably less than 40 hours of work and I'm a mobile/desktop dev not a Web dev.
While I agree Blazor is great, everytime I use it it feels unfinished.
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.
That's what I always think about MS GUI frameworks.
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.
> fuck around with JSON APIs alone is worth the price of admission
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.
Maui is targeting React Native and Flutter. Same for Blazer with Electron. They make this attempts to bring C# everywhere. Using Flutter, Angular or setting else is the context switch they try to avoid.
For me, as a .NET fanboy, they are a year or two late.
As a developer who is also a Xamarin Forms user I can say - I get really nice performance out of Xamarin Forms these days. I'm not interested in React Native because it doesn't give me anything I can't do pretty quickly. This is also why I'm not interested in Kotlin and the Android SDK. I've been more or less exclusively developing Android Apps using Xamarin Forms for the last 18 months and Maui is way more exciting than anything else I see from other frameworks.
Haha ... no. Sorry for writing the sentence like that. My fault. It is not a compiler target but from a business perspective the target audience they address.
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 ;)).
ASP.NET is the name for a wide variety of technologies Microsoft has developed over the years. If we’re talking the current/modern version, the answer’s no.
.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.
The WPF grids are fine and autocompletion is trivial. Which is the proper way to write frameworks: make it easy to make the bits you don't have.
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.
So when purchasing Visual Studio subscription in order to write software for windows, you expect nothing to work out of the box? I'd love to see you tackle a WPF monolith within a regulated environment where no 3rd party libs are allowed.
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.
> stuff like Xamarin Forms and abandoning it half-way through
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).
"I've worked on projects using Xamarin Forms, and they turned out just fine."
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.
> at the end of the day you're coercing C# to do something it was not designed to do
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.
> So when purchasing Visual Studio subscription in order to write software for windows, you expect nothing to work out of the box?
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.
I think that it was intentional. Microsoft often comes under pressure for competing with their suppliers and this was the one example where they didn't even try.
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.
It's much better to have the foundations and build the rest yourself (or purchase what you need) instead of having the lowest-common-denominator come from MS.
There are a 1000 different ways to implement autocomplete menus and charts; that would be a nightmare to produce or use.
All the 3rd party library hanger-ons is a real putoff. Asp.Net docs linking(with broken links) to a 3rd party, paid identity framework to make auth work for Blazor/Spa? Gross. It's 2021 and this stuff is table stakes for OSS web framework ecosystems.
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# has the advantage that the features are very well considered and come from a functional programming heritage. The fact it's a functional-first language rather than a bolt-on like C# is a massive advantage.
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.
F# seems to get love and recognition through C# slowly evolving and absorbing features that have been the F# advantage for a long time (fingers crossed for C# discriminated unions...)
I think they have been removed from C#10 now, I saw this on the language discussion:
>While we wanted to look at discriminated unions for C# 10, we don't think we're going to be able to
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.
I stopped counting how many generations of UI Frameworks (Modern UI, UWP, WinUI, ...) they released since Windows 7. All of them ware practically unusable. Some reasons:
- 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
There are some great alternatives to check out, which even provide cross platform support:
New Outlook is being written with a web UI, using WebView2 on Windows. MAUI lets you do something similar (embed a web view, do your UI in that with Blazor or any other web tech).
There are two sides of Xamarin. It builds native apps and you can use their native UI systems. So you can build a native Android UI and a native iOS UI next to each other. This will give you perfectly native apps with the ability to share as much code as possible.
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.
It's 100% UI code reuse between both platforms and MAUI takes it up to Mac and Windows. I've delivered several apps with more then hundred thousand users and the turnaround time for XF apps is generally 3-4x faster than native.
Same. OP says "going to die soon" of a framework that's been around for 9 years and is being invested in heavily. I've been working on Xamarin projects for years and have done very well with it.
Doing consulting I've done plenty of projects in React Native and played with Flutter a bit but Xamarin really is a great framework.
> Plus you can't share UI code between Android and iOS. You still need to build the UI's natively with no code reuse.
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.
Xamarin was a company that produced several things. The AOT toolchain was fully integrated as a first party part of .NET 5.0.
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.
Xamarin is merging into .NET with .NET 6. MAUI is the new name/brand of what used to be Xamarin.Forms the cross-platform UI toolkit. The rest of Xamarin, the "binding glue" to build .NET applications for Android and iOS is now just "profiles"/"targets" of .NET 6 itself: net6.0-android and net6.0-ios.
Obviously I don't know what you are reading, but I've seen a lot of buzz about MAUI (including this article we are commenting on) since last BUILD when it was announced. Some of my "enterprise" dark matter feeds have been extremely excited at the idea that Xamarin.Forms is moving into System.* namespaces in .NET and what that means for certain types of very conservative enterprise adoption (it no longer looks like a 3rd party option with a weird brand; it's "real" .NET top to bottom).
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.
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).
Been using this in production for years now (although we target just Windows and MacOS so I don't have experience with it on Linux). It is buggier than WPF and has occasional annoying issues when you update to a newer version, but it's still too good for us not to use compared to .NET-based alternatives. We've been using it more and more over time.
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.
Not sure on that one... It will depend a lot on community support, getting over the first speedbump is the hardest part... if it gets built, I think it may become well (enough) maintained.
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.
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.
Is it realistic to expect MS to support a language they purposely built a replacement for 18 years ago? What's stopped you "upgrading" to C# in 18 years?
I prefer VB. I have a degree in writing C#, I just find VB vastly preferable to work in.
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.
This is very foreign to me, and I'm not a VB hater.
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;`.
I did this a number of times. I started working on a VB.Net source base around 2007 and started to introduce C# as soon as I could, then next job in 2013 was also a WinForms app that embedded some WPF and used mainly VB.Net and some C#. I have to say, C# feels a lot more productive for me. I can switch between C# and VB.Net easily, but some of the stuff VB.Net does makes no sense.
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.
I did the same, but based on the code style we used, more like `Dim foo = True` vs `var foo = true;`
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.
It's possible it has a "native language" effect to me. Like how if I want to speak another language, say French, I think what I am trying to say in English and then translate. VB syntax is well solidified in my head as what I am trying to do... and in most cases when working with any other language, I end up going "okay, so how is Select Case formatted in this language?"
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.
Python and VB target very different audiences, is there something I'm missing here? Python is an interpreted dynamic language that turns into an unwieldy monster at scale, I believe VB was mostly fighting for Fortran and web devs.
It was, but never really became relevant because most people switched to C# + WinForms and never looked back.
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.
Python was built as an education/learning language first. It's popular because it's often a first language learned, and necessity in education/research space caused a lot of innovation over the years.
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#.
> Python was built as an education/learning language first. It's popular because it's often a first language learned
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.
> Colleges have been teaching Visual Basic as a starter programming language for decades.
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.
You struggle to imagine because you went elitist. "University level strong in CS", I said college. A lot of colleges teach Visual Basic. No, Ivy League schools might not, but a lot of colleges do. Heck, my community college taught a class for kids on it in the late 90s (my intro to programming) and still teaches college students a VB track today.
Well hey, I personally took a C programming course at the local community college, way back when, and have never met someone who learned VB outside of business/industry. Same way that Excel+VBScript are very useful but not taught as CS, but perhaps are covered in business classes. It occurred to me that your use of "college" might be the non-US meaning.
I have never heard anyone from any school in any country mention they used VB in school. Everyone I know who used VB, including me, learned it outside of school (either as a hobby or at work). I don't think VB in colleges was ever as widespread as you claim.
The two pieces of evidence I'd give you as proof of widespread use:
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.
It is a thing for Excel courses. My sister was an accountant a few years ago and had to learn VB to write macros (because businesses are still stuck in the 80s)
Got my 2 year in 2010 at a local CC... they taught VB.Net and DB2 SQL on mainframes. I THINK they are moving towards more JavaScripty stuff but I'd not be surprised if the CC still teaches VB and DB2 Sql because local corporations still have the need.
That's kinda a nitpick. I have a game programming degree, where the majority of programming was C#. But local computer science programs also tend to have language-specific tracks available, like C# as well.
When they go out of their way to say VB is a first class component and repeatadly say over many years that c# is not a replacement for VB then yes, I do think it's realistic to expect them to support it.
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 know someone I used to work with who was a VB .Net MVP for a number of years, and even a decade ago, his biggest complaint was lack of support/examples inside and from MS.
> 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 :)
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
It doesn't matter, native code doesn't make your program automatically faster, C# code is hard to aot compile, lot of things happen at runtime and Xamarin uses a lot of that
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
There is nothing on this list inherent to OOP. I’m fairly sure C++ is an OOP language (okay, multi paradigm), and their use is “zero-cost” abstraction. Vtables are only necessary for virtual functions, and you similarly have to decide another function implementation if the business logic requires that. Indirection, cache misses do happen with some managed OOP language, but that is due to objects being pointers to heaps instead of stack-allocated.
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.
Objective C’s whole thing is based on calls to objc_msgSend instead of directly to the intended function. And yet, the first iPhone (running at 400 MHz) handled it fine.
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
To put the question a bit more nicely than my sibling, don't Tk apps all look... really bad? I don't know if I've ever seen a Tk app that tried to mimic native widgets at all.
Last time I checked (years ago), apps using ttk widgets (rather than old tk widgets) look nearly native on Windows, but still ugly on Linux (matching neither GTK nor Qt themes).
ttk (which was introduced in tcl 8.4, circa 2002) uses native widgets on Windows and Mac. The default theme on linux is ugly, but there are reasonable themes available.
There was an attempt at a GTK backend for ttk on linux, but apparently there were technical difficulties so it was abandoned.
Tk also looks like ass in today's environment of ｍｏｄｅｒｎ apps with their abundance of white space and dearth of affordance. Your Windows 9x-like Tk app will stick out like a sore thumb.
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.
I prefer C#/F# over Dart, but Flutter is promising, and I continue to check in once and a while. I usually overcome PL preferences when the platform or toolkit is compelling. I remember Notch (of Minecraft fame) adopted Dart very early on, and I actually tried it out back then. Somebody had written a Lisp in Dart. I really like F#, and it seems to be sidelined all the time with .NET. There are more and more ways to write C# in a functional way, and it has become the lingua franca of many game engine/3D media creation tools like Unity, Wave Engine, Flax, and Stride to name a few.
I'm not sure what your bar is for "experimental", but Flutter is one of the most popular UI toolkits out there, with many 100m+ MAU apps using it, including tens from Google itself. It's already shipped a 2.0 release, has 15,000+ packages on the pub.dev package server, is the framework Ubuntu has settled on for new desktop apps, has hundreds of active contributors, and is one of the top ten OSS projects on GitHub.
"Experimental" feels like an odd word choice, if you're truly trying to offer useful information.
A lot of devs are risk adverse when choosing platforms for projects. There's still risk as in, will this still be supported in 3-5 years and is the API going to change so much in 1-2 years I'll be rewriting significant portions of my application.
I've been passively looking at Flutter with interrest.
Also, the Dart lang team seems to consider Flutter a first class citizen and has been modifing the language for it specifically. From syntactical sugar for Flutter's constructors to carefully selecting language features considering muilti-target platform performance.
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.
Some people think like this: if i write an app and come back in 10 years, is it still going to work, compile, and be possible to update? By that benchmark very few platforms are acceptable, and they are mostly first party.
That standard makes sence if you have a rigid hardware-like approach
Yeah, that makes a lot of sense for certain platforms. I've spent a lot of my career working with enterprise customers, some of whom are comfortably running 20 year old software written with something like WPF. And in general, that would be true of Flutter too -- on a platform like Windows, it will work at least as long as the underlying Win32 APIs are available.
(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.
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 think there’s some possibility of slight confusion by mixing Xamarin and UWP together. Xamarin (and thus .NET MAUI, which is cross platform) does not use the same flavor of XAMl as UWP (and thus WinUI, which is Windows only but shares the same XAML as Uno).
Yeah, UWP is a progression on WPF/Silverlight that had its own XAML as part of the platform code/declarative.
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.
Xamarin.Forms was like an abstraction helper though, underneath all Renderers. You can/could make CustomRenderers for any custom controls or to access any native needs on iOS, Android and UWP directly. That is how most apps ended up.
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.
Xamarin.Forms also had desktop targets, including WPF and UWP, although I think only UWP was officially supported. Support is perhaps too strong a word...
- 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.
That's why it exploded in popularity then? Literally exploded and was releasing on a rapid cadence to a fervorous developer base. The current non-MAUI Xamarin is very refined and complete from a performance and feature perspective. It is literally the only viable serious cross-platform and mobile development platform.
Its important to distinguish between Xamarin.Forms and Xamarin.Native (which Forms is built on top of). Xamarin.Native is quite nice and is the best abstraction available today (in my opinion). Xamarin.Forms is indeed not great. It is an OK solution for a subset of problems, but even for those I'm left wondering if the pain is worth it rather than rolling my own native frontends in Xamarin.Native.
Xamarin.Forms might not be great if you want to create a beautiful app that performs very smoothly, but it’s pretty sweet for making multiplatform business apps for use in-house (as in: not sold on app stores) imo.
Right, internal apps are the sort of thing I think fall in the 'subset of problems' its good for, but as soon as you have a design guide to adhere to (i.e. you aren't just shipping the out-of-the-box configurations) its buggy and painful.
Hopefully a chance for them to take what they learned through years of experience and cut away from the cruft/technical debt that built up with Xamarin.Forms.
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'd love if this could be a step forward but from my fly-on-the-wall perspective following the github, I'm not optimistic that the team has internalized what exactly this new thing should be, and how it should differ from Xamarin.
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.
I'm not well versed with PWA topics but as long as Apple doesn't curve around this, we can't expect a wide adaptation of it. Don't get me wrong, PWA can be the future but not without the whole Apple ecosystem missing.
Learn to ignore garbage companies like Apple if you don't want to be treated like garbage by them. They don't matter. If Safari does not support the latest and greatest, Safari is garbage and show this message on your website with big bold letters.
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 already consider .Net itself suitable for cross platform use. MAUI had no supported Linux target and no indication that it will be community adopted/done.
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.
Yes, the tooling was the problem. The basic concept of XAML is great in my view. If they only had improved the tooling somewhat and reworked the syntax this would have been a winner.
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.
I think you might need to wait for that, MAUI’s still being worked on for the upcoming .NET 6 release.
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.
How does it compare to jetpack compose and the web? (ergonomics, capabilities, performance)
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.
Has anyone done much with this? I wouldn't mind moving on from Windows Forms but the stuff that's come after seems like evolutionary dead ends that weren't really worth my time, so far...
Oddly enough, if you don't care about cross platform and pixel perfect placement, Winforms are probably the sanest choice. It's been ported to .NET 5 and they fixed some of the high DPI issues of the past (more coming in .NET 6).
No idea who's downvoting you. A lot of .NET effort is put into performance: value structs, value tasks, Span; generally, optimising code against various benchmarks.
I think the Blazor server version is okay for Internet insofar as initial dl is concerned, but the problem with Blazor server is scaling it since the signalr connection requires client affinity with the server. Or I believe that's still the case. I'm not expert, but I think there are some issues with horizontal scaling with server-side blazor. Maybe that's been fixed or there are good solutions for it.
Client affinity with server is due to Signalr. Since server-side blazor uses signalr to pass the changes between client & server. Might be a easy fix with sticky sessions. But haven't come across anyone that has tried it.
Yeah, I always assumed that you could put a load balancer in between to enforce the affinity across a farm, but I think the point is that dollar-for-dollar, the need to do that means it won’t scale well for a massively public app as well as other technologies (i.e. it will be more expensive to host).
But at least you have a 64-bit version of Visual Studio on the MAC. Something devs using windows have been wishing for long time. Supposedly VS 2022 is going to be the first 64-bit VS on windows.
Not even Linux UI libs have "full" Linux support, ui wise. There is GTK, Qt, Tk, Xlib, wxWidgets etc. A single GTK/Gnome App does not look "native" on KDE and vice versa. It is totally unclear if MAUI would support linux, what UI lib it should adopt and it would still not look native for lots of users.
What the fuck is wrong with Microsoft these days? Why can’t they stick to a single UI library for more than a year? We don’t want n+1 incompatible UI frameworks. We want a single UI toolkit that you stay committed to, with rich controls and long-term support. I can’t believe that in 2021 WinForms is still the only sorta decent option to write Windows applications.
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.