Microsoft-ui-xaml: Discussion: WinUI vs ElectronJS and cross-platform (enhance WinUI to eliminate reasons for using ElectronJS instead of WinUI)

The same goes with the new Xbox Beta app. It uses a 400MB just being open as a glorified Store. The Microsoft Store uses only 117mb while active.

Until Microsoft develops a cross platform UI framework, which allows for a single UI and control design across all platforms, ElectronJS and it's ilk, will go on being used.

Example of the astonishing speed of ElectronJS/Teams:
Firstly, as a comparison, I timed how long it takes to open Microsoft Outlook and view the most recent message in the inbox (an inbox containing a very large number of messages). It took only a couple of seconds -- actually it was so fast that I couldn't stop the stopwatch fast enough to get an accurate measurement.
Next I timed how long it takes to open Microsoft Teams and view the most recent message in the chat with a colleague: 27 seconds! This time can be more or less depending on how many messages and images exist in the chat pane.

( UPDATE 9-NOV-2019: _A new version of Teams has been released and it improves the time taken to view the most recent chat message. The aforementioned example of 27 seconds now describes the previous version of Teams. Thank you to the Microsoft staff members who worked on this improvement._ )

Last week, I clicked the Help icon in Teams, then I clicked "Give feedback" and typed a message. It was astonishingly slow: Each time I pressed a key on the keyboard, it took several seconds for each character to appear! (However, when I tested "Give feedback" again today, it lagged far less than last week, so apparently it's tricky to reproduce this particular problem.)

If Teams was written using WinUI, it wouldn't have these speed problems and various other unusual bugs. For example, WinUI apps use the date/time formatting that is configured in the Windows settings, whereas Teams always uses 12-hour USA date/time formatting when Teams is set to English language, and ignores the Windows settings -- that's not how Windows apps are supposed to operate. Then I tested changing the language of Teams today and it said _"There was a glitch, Teams is recovering"_. And then several images in messages in the chat pane failed to load.

Likewise if Teams was written using WinUI, it wouldn't create 5 Teams processes.

@mdtauk

Until Microsoft develops a cross platform UI framework, which allows for a single UI and control design across all platforms, ElectronJS and it's ilk, will go on being used.

Although I'd generally agree, there must be more to this story than that, because for example Microsoft OneNote is available for Windows, Android, and Mac, but it doesn't use ElectronJS (AFAIK) and doesn't suffer terrible performance like Teams.

@mdtauk

Until Microsoft develops a cross platform UI framework, which allows for a single UI and control design across all platforms, ElectronJS and it's ilk, will go on being used.

Although I'd generally agree, there must be more to this story than that, because for example Microsoft OneNote is available for Windows, Android, and Mac, but it doesn't use ElectronJS (AFAIK) and doesn't suffer terrible performance like Teams.

Microsoft has the resources to build apps for each platform, sharing code as much as possible - but not using a shared UI

I would love to hear any arguments against using Uno Platform that targets multiple platforms (Windows, iOS, Android, Web) producing high-performance app packages using UWP API now, WinUI later. It uses everything Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Is not coming from Microsoft directly the primary reason for some to avoid it?

I would love to hear any arguments against using Uno Platform that targets multiple platforms (Windows, iOS, Android, Web) producing high-performance app packages using UWP API now, WinUI later. It uses everything Microsoft - VS, C#, Xaml, Xamarin, mono, .Net...
Is not coming from Microsoft directly the primary reason for some to avoid it?

This would have been a better argument some years ago, but a lot of companies looking to invest in building an app or system, needs to know the platform they are developing for has the support and longevity of a big company with vast resources like Microsoft.

The problem with that argument is that the past decade has shown Microsoft abandoning platforms, and user bases, and Windows being moved into legacy or diminishing priority within Microsoft.

So you can't blame new devs for moving towards web platforms, if they wish to run connected services - or focusing on platforms which are actively being developed, and appear to have strong support going into the future.

At the same time there are a few large companies like Adobe, with legacy apps - so moving platforms with those will be next to impossible. There are also hobbyists and businesses with custom software.

Microsoft has done well with .NET and Win32 support. And WinUI may be the chance to allow Win32 and .NET - but with a modern UI.

Silverlight, WinRT, UWP - were all abandoned. (I know UWP isn't technically, but WinUI will most likely be seen as a replacement).

Zune, Windows Media Centre, Windows Phone 7, Windows Phone 8, Windows 8 - let down the enthusiasts and those who they tried to evangelise.

How Microsoft positions WinUI and also ensures the future of Windows is secured, will be _absolutely essential_

WinUI for Desktop looks promissing, but I feel that at least a subset of its XAML must be able to run on the Web; WinUI on the Web, like a new Silverlight but running on .NET 5 and WebAssembly.

Silverlight, WinRT, UWP - were all abandoned. (I know UWP isn't technically, but WinUI will most likely be seen as a replacement).

Zune, Windows Media Centre, Windows Phone 7, Windows Phone 8, Windows 8 - let down the enthusiasts and those who they tried to evangelise.

Concur.
Can't believe some of my Silverlight (web0 apps are still used daily by some users.
Following Microsoft has been increasingly difficult. The folks behind Uno Platform develop and maintain it to support their bread-and-butter app business. It is open-source with many contributors. I feel that I am piggybacking a very good bus with top-notch drivers knowing well how to navigate Microsoft maze or mess.

My 2 cents: UWP and WinUI's only hope, is if they quickly make it cross-platform, web-included, before there's nothing left of it.
Uno Platform is a quick, easy, and probably also the safest way this could be achieved.
As @zipswich mentioned, Uno has been Microsoft all the way and all along; in the coding-guidelines, the tooling, the language selection, and the rendering, and is Fluent-design ready.
It's 100x more Microsoft-biased than Xamarin is, for instance. Let alone React or Electron, and all ugly HTML & CSS or JS technologies MS is so obsessed flattering and cheating with.

And lemme be harsh, C# is only a server language with .NET Standard's lack of a UI framework.
The longer it stays this way, Dart or other technologies will become server-languages, and take over completely.
You see that people are willing to use nasty languages (JS), as a sacrifice to be able to use a single-language code base, in both client and server. C# might fade just like XAML did, or it can win along with XAML if emergency rescue is given.

I don't believe that Uno will be the future. It is very similar to Xamarin.Forms, being a stripped down Xaml framework with lots of missing functionality and lots of complicated extra stuff being added to allow it to somehow integrate in all platforms, with some hacks and workarounds. Sure you can use it, but you are very limited in what controls you have and what APIs you can use. The main problem is that it tries to realize the Xaml UI with each platform's native controls. This is always problematic and leaves you with only the small subset of functionality that happens to work on all platforms.

The future would be to use the real WinUI and provide a real renderer for each platform, implemented in the platform's native 3D engine. This would get us the complete featureset, all the goodness of WinUI, running with native performance, cross-platform.

Actually, Microsoft already had something like this running very well: UWP UI was based mostly on the Silverlight code, and Microsoft had Silverlight plugins for all major platforms, which means they already have basic rendering engines for all of these platforms. They are not up-to-date, since by now UWP has lots of additions compared to Silverlight. But it is a base that can be built upon.

Microsoft sure has the resources to pull this off. This is what people want, and this is what they should do.

C# might fade just like XAML >

Definitely don't agree with this statement regarding C#. C# is much bigger than XAML. If you are following Blazor you will know this can't be true. I see Blazor as a game changer for me primarily using UWP / Xamarin and for C# developers in general specifically targeting business users.

It would be nice to have WinUI x-platform but I think the easiest road to the web /x-platform is Blazor especially now that Blazor also support partial classes that means I can take most of my existing code as is and start using it in Blazor. Couple of hiccups could be alternatives to Sqlite , Shared Projects and ReactiveUI. I should be able to use my existing MVVM architecture and port it to Blazor fairly easily.

The most important stumbling block for me is the lack of .net core 3 support in UWP. I think it's critical for MS to align Blazor + UWP in the developer experience. I know the UWP team is working on it.

Also, I would like to see Blazor pages in UWP / WInUI apps. Hybrid UI model would work great for me in UWP apps so that I can use the best UI assets available. (html5 versus XAML) and also not replicate my UI effort between UWP and Blazor where it make sense.

Currently Electron is using Javascript , HTML + CSS. No reason why we can't use Electron with Blazor => C# , HTML + CSS + gRPC

but you are very limited in what controls you have and what APIs you can use.

@lucasf Have you tried Uno? Did you know Uno allows using any native API via Xamarin in case there is no suitable UWP API. I use only a few native APIs in my Uno based apps even for my real-time video streaming app that uses hardware codec and requires low latency.

but you are very limited in what controls you have and what APIs you can use.

@lukasf Have you tried Uno? Did you know Uno allows using any native API via Xamarin in case there is no suitable UWP API. I use only a few native APIs in my Uno based apps even for my real-time video streaming app that uses hardware codec and requires low latency.

@zipswich The set of standard Xaml controls in Uno is pretty small, not anywhere near what full UWP or WinUI3 has to offer. To realize good/complex UIs, you usually have to embed additional platform specific native UI controls and code. So in the end you will find yourself with a mixture of multiple UI platforms (Uno Xaml, native Android, Native iOS, maybe native Windows or WebAssembly). This is not what I call a great developer experience.

If we had native x-platform renderers for WinUI, we only had one single UI with the complete WinUI feature set, without any kind of platform specific stuff in it. And the WinUI would directly render on the GPU with full performance, just like you'd expect it. No need to add extra Android controls or extra iOS controls. This is how x-platform development should look like.

What is WinUI lacking (and how can it be improved) in order to convince the Microsoft program managers for Microsoft Teams to switch from ElectronJS to WinUI/UWP?

Great question. A huge number of users will be very happy if they did this.

A large factor is the lack of performance measures comparing frameworks. A page which compares equivalent apps done in UWP and Electron and compares speed and memory usage would be enough. This could extend to other frameworks. From this costs to users, effects on usage, and benefits of code consolidation can be weighed up against the financial costs.

The current lack of this research is helping inefficient frameworks to become popular.

Speaking honestly: I doubt MS has any plans to make "WinUI" (Windows UI) cross-platform. On top of that, the fact that it is now open source usually means Microsoft no longer considers it a critical/strategic tech. They are trying to tap the community resources instead to lower internal headcount while keeping it alive. Don't get me wrong, I'm happy WinUI is open source now and appreciate all the time the Microsoft devs are putting into the platform taking it to WinUI 3.0 -- it's a great step to consolidate the windows presentation platform for both native and managed apps. I just don't think Microsoft sees Windows as the future and I don't think they are interested in taking it cross-platform (of course that is their mistake if true).

A real cross-platform development framework that doesn't force developers to use sub-par tech is what the world needs. Seems most people here agree. What that largely means is:

• A control library and markup (XAML) that can render just like platform native designs (we would only need control styles for iOS, Android, etc.)
• Needs to be written in managed code like WPF was. Only the base layers in C++, controls should never be anything but C#.
• Rendering needs to be done with Metal/Vulcan/DirectX (not on top of existing controls like Uno)
• Input has to be re-implemented in a X-platform way
• Accessibility is a big issue that is unfortunately much more easily solvable using Uno's approach

If that's what we want, WinUI is not going to do it I think. The fact and way it's implemented natively (some COM/.net layer in-between) alone means is would be very tricky to take this cross platform. Instead, we have UNO and Avalonia. Avalonia is the real light at the end of the tunnel but they don't have any resources. What is more-or-less possible now is to use the Avalonia rendering tech as a backend to WPF (the managed part). That would give us a true cross-platform UI framework in a short amount of time. The problem is WPF is designed for desktop and a lot of work went into UWP to make WPF/Silverlight friendly for phone-sized devices and modern touch/interactive input.

I honestly think at this point we would be better off if all of us just threw money and code contributions at Avalonia. We've been asking Microsoft for a cross-platform UI for too long and they are content to switch to web technologies themselves. Microsoft is even converting UWP apps like XBox into Electron and web technologies now. Apps are also not selling in the Microsoft Store.

The irony is Microsoft was so successful in the past because they gave developers the tools they needed to build great apps. This draws in users and you have a very constructive feedback loop. At some point that was forgotten. Now developers are resorting to sub-par technologies (HTML/CSS was never originally designed for apps... it was for document markup!) But the savings in only having to develop an app 1-once and run it on Electron and the web far outweigh the sacrifices in functionality, system integration, and performance at this day and time.

The irony is Microsoft was so successful in the past because they gave developers the tools they needed to build great apps. This draws in users and you have a very constructive feedback loop. At some point that was forgotten. Now developers are resorting to sub-par technologies (HTML/CSS was never originally designed for apps... it was for document markup!)

Well said. Besides BASIC, I started using Microsoft IDEs from Quick C, then VC++... Microsoft used to evolve, innovate in a steady, consistent, somewhat predictable manner. We tried to follow it, and it seems to follow the trend of those who are supposed to follow us. I used to tell interns from top tier research universities to use Microsoft technologies for enterprise apps on which they were asked to work. There was zero resistance, and they happily picked up Microsoft stuff quickly. I have been wondering if Microsoft has been looking at what kids these days like, then follow them.

Apps are also not selling in the Microsoft Store.

True sadly. However, I blame the worst app store (for users and publishers), not dev technologies. The daily downloads ratio of the UWP vs Android version of an app: 1:20. They cost about the same amount of effort to develop. This is not an exaggeration. I just took a look at yesterday's downloading data. If I worked for a bean counter, I would be fired immediately for spending so much effort on the UWP version that generates so little return.

True sadly. However, I blame the worst app store (for users and publishers), not dev technologies.

@zipswich, yes, you have a good point. I was just assuming that Microsoft internally sees the sales numbers and assumes (correctly) the ecosystem is dying. This then convinces them that the types of underlying development technologies we are talking about are obsolete so they start to invest and go other directions. In actuality, most Microsoft app developers can see the clear need for a cross-platform framework that isn't written forgetting the last 20 years of UI tech advancement (WPF really was a game changer when it appeared).

We not only need cross-platform: we need something that is done with powerful/scale-able languages and markup and has meaningful scope (intended for apps, good control catalog) from the beginning. I don't think we can count on Microsoft anymore for that though. They've made it clear they see higher profits spending their time/resources in other areas.

I would be fired immediately for spending so much effort on the UWP version that generates so little return.

I hear you, I made that statement based on my own app in the Microsoft Store too.

@robloo You have some good points there, but I don't really follow you. Here are some thoughts:

• Microsoft has put lots of effort and resources into other open source frameworks as well, such as .NET Core, ASP.Net Core, EF Core. Obviously they see the future in open source, cross-platform develpment (at least for server applications). They also put resources into AOT compilation, so .NET Core can be compiled to iOS and Android as well (where JIT is not allowed). So I can't follow you saying that WinUI is dead now, just because they make it open source. I mean, it could be true, but if your only argument is "because they make it open source", then this is not very convincing.

• Qt is a cross-platform UI framework, being implemented in native C/C++. It has hardware accelerated OpenGL/Direct3D renderers, so it looks the same and has great performance on all platforms. No platform specific code is needed, all controls run on all platforms, including iOS and Android. So why should it not be technically possible to run WinUI on iOS and Android, if Qt can do just that? WinUI is implemented in WinRT, which is native C++, just like Qt. Internally, it uses only a few COM technologies (IUnknown interface plus the COM factory system). It should not be too hard to abstract that away or re-implement what is needed for other platforms. I don't think that any COM code is directly used in WinUI code.

• Silverlight used the same technology and was available x-platform.

• Windows is still the number 1 desktop OS, heavily used, not only at home but also (especially) by businesses. Combined with Office licenses, it generates a lot of solid revenue for Microsoft. They'd lose this revenue if they let all major UI development platforms die. WinForms and WPF are dead already, so WinUI is the only active UI platform on Windows. I don't believe they want to get rid of the complete Windows/Office/Enterprise system, so I don't believe they want to get rid of WinUI.

• Making WinUI open source is great for devs, not only for Microsoft.

• It might be that UWP is going to die. Many devs keep away from it because of all the stupid limitations. The Windows Store is not remotely successful. Windows Phone is dead, which was the main reason to even start the whole UWP thing.

• Bringing WinUI to desktop apps with WinUI 3.0 and making it open source, might actually be the step to save it, not kill it!

I was just assuming that Microsoft internally sees the sales numbers and assumes (correctly) the ecosystem is dying. This then convinces them that the types of underlying development technologies we are talking about are obsolete so they start to invest and go other directions.

@robloo It does not have to be the case. I have been saying all along that it is the worst app store that killed Windows Phone, the best mobile platform.

They can kill two birds with one stone: outsourcing the store to a competent third party and end the .Net Native nightmare. It will reduce their cost and (I believe) double, quadruple... Windows app downloads quickly. More than 90% of my UWP app problems are solely related to the .Net Native nightmare.

@lukasf I think you misinterpreted a lot of what I was saying.

I can't follow you saying that WinUI is dead now, just because they make it open source.

I would never say WinUI is dead. I did say Microsoft probably no longer sees it as a critical/strategic long-term product. They see higher profits in other areas (services and the cloud) so are making sure to spend their time where there are higher profits for the shareholders. This means I think they won't be significantly growing WinUI to make it cross-platform and just keep it alive which I made sure to say instead of "dead". (I'm not someone on the UWP/WinUI is dead bandwagon). I also very strongly feel Microsoft is doing a great thing with WinUI 3.0 which I stated. It's allowing all of Windows, win32 native and managed, to consolidate with one UI framework.

So why should it not be technically possible to run WinUI on iOS and Android

Anything is technically possible. I was saying it would be extremely difficult though as it was designed and implemented solely for Windows. I also gave the example of how it communicates with managed code as something I think would be very tricky to take cross platform. It would be good for all of us if I was wrong here though.

Silverlight used the same technology and was available x-platform.

And Silverlight is dead not because it wasn't technically possible but because it no longer was a good business case which is really my most critical point. Note that it also died to the same HTML/CSS/JS technologies now taking over desktop and mobile development.

They'd lose this revenue if they let all major UI development platforms die.

This could probably be discussed a number of different ways but probably gets totally out of scope to the topic pretty quickly (which I know I'm already doing). Bottom line, of course Microsoft will not let all Windows UI platforms die. You still have to write apps for Windows... I never said otherwise.

Making WinUI open source is great for devs, not only for Microsoft.

I did say "I'm happy WinUI is open source now and appreciate all the time the Microsoft devs are putting into the platform taking it to WinUI 3.0 " The intention was to convey my sentiment that I also think open source is great for a number of reasons I didn't touch on. As an example, even Uno Platform now having access to the source is great as they stated at UnoConf.

It might be that UWP is going to die.

Wait, which side are you on? haha. But seriously I consider WinUI/UWP essentially the same thing and UWP will just have a minor evolution into WinUI with no major hickups for developers.

Bringing WinUI to desktop apps with WinUI 3.0 and making it open source, might actually be the step to save it, not kill it!

I agree with you and never intended to say otherwise. I was looking at some bigger picture trends though and also talking about taking it cross-platform.

@zipswich

They can kill two birds with one stone: outsourcing the store to a competent third party and end the .Net Native nightmare. It will reduce their cost and (I believe) double, quadruple.

The good news is Microsoft already decided to kill .net native. Technically it had a number of ridiculous restrictions that didn't follow .net specifications which it sounds like you are more than familiar with. I think it was something that was done quick/dirty to fix startup and performance problems on windows phone and they never bothered to go back and fix things since windows phone died.

Now Microsoft is developing full, high-performance, AOT compilation using Mono technologies and LLVM. This should come out by next year I think and is also useful for client-side Blazor with webassembly. Miquel de Icaza gave a good presentation touching on it earlier this year at UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (he is the first presenter).

@robloo Okay maybe I got you wrong in some points.

So why should it not be technically possible to run WinUI on iOS and Android

Anything is technically possible. I was saying it would be extremely difficult though as it was designed and implemented solely for Windows. I also gave the example of how it communicates with managed code as something I think would be very tricky to take cross platform. It would be good for all of us if I was wrong here though.

Silverlight used the same technology and was available x-platform.

And Silverlight is dead not because it wasn't technically possible but because it no longer was a good business case which is really my most critical point. Note that it also died to the same HTML/CSS/JS technologies now taking over desktop and mobile development.

My point here is: Silverlight was already running cross-platform. It could be used with managed code. The UWP Xaml UI layer from Windows 8 was basically Silverlight, just with a new namespace and some added metadata. By now it has evolved, but in the beginning it clearly was just Silverlight Xaml with a new namespace. So if they could run Silverlight cross-platform back then, they can run WinUI cross-platform as well. And I don't believe that this will be "extremely difficult" but I'd rather say it would be rather easy for a huge company as Microsoft. They already had a cross-platform rendering layer for Silverlight Xaml. It shouldn't be too hard to update it so it can run the latest WinUI.

It might be that UWP is going to die.

Wait, which side are you on? haha. But seriously I consider WinUI/UWP essentially the same thing and UWP will just have a minor evolution into WinUI with no major hickups for developers.

WinUI is just a Xaml UI layer, while UWP is a complete app framework and system API layer, being tied to the Windows Store, and with lots of limitations compared to classic desktop apps. So these are two very different things. I really don't know if Microsoft does see a future in UWP and the Windows Store. Not fixing the severe UWP limitations and not really working on the Windows Store problems does not make me very optimistic. But they definitely need some kind of UI framework, and that is going to be WinUI, no matter if used from UWP or from desktop apps. And if they really want it to be successful, they must make it cross-platform. Otherwise people will go away to other frameworks, and then they might at some point leave the Windows platform completely as well. Making WinUI cross-platform would be a means of getting devs to stick to Windows.

My point here is: Silverlight was already running cross-platform. It could be used with managed code. The UWP Xaml UI layer from Windows 8 was basically Silverlight, just with a new namespace and some added metadata. By now it has evolved, but in the beginning it clearly was just Silverlight Xaml with a new namespace. So if they could run Silverlight cross-platform back then, they can run WinUI cross-platform as well. And I don't believe that this will be "extremely difficult" but I'd rather say it would be rather easy for a huge company as Microsoft. They already had a cross-platform rendering layer for Silverlight Xaml. It shouldn't be too hard to update it so it can run the latest WinUI.

I didn't know that history of the Silverlight base being used for UWP/Win8 back then, if that's the case it definable makes me more optimistic about how feasible this is. Thanks for the correction!

WinUI is just a Xaml UI layer, while UWP is a complete app framework and system API layer, being tied to the Windows Store, and with lots of limitations compared to classic desktop apps. So these are two very different things.

Yes, you are right and I should have chosen my wording more carefully. Certainly UWP in app model and packaging will continue to exist for now. However the UI layer will switch to WinUI which is what I was trying to communicate. I think there will be more changes in the coming years with .net native being replaced but the packaging/App model/API's introduced with UWP will still exist in some form. I definitely agree that Microsoft may not see a future here though. Thankfully, as long as XAML and C# is still there migrating to a new application model or packaging/distribution is usually relatively quick. If only Avalonia was finished...

And if they really want it to be successful, they must make it cross-platform. Otherwise people will go away to other frameworks, and then they might at some point leave the Windows platform completely as well. Making WinUI cross-platform would be a means of getting devs to stick to Windows.

I also agree with you 100% and have stated the same several places. I've come to the conclusion that for a number of reasons it isn't going to happen though.

I can't disagree strongly enough with the commenters saying:

WinUI 3.0 must be cross-platform!

1) We need a UI framework now, not in another N years when the theoretical cross-platform project is stable.
2) We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

The solution, in my mind, is to have another framework which builds on top of either WinUI 3.0 (if you want to maintain Fluent, and have little work in rendering, hit-testing, etc), or from the ground up with WinUI Composition if you want max performance, and don't mind doing all the rendering and hit-testing yourself (at the potential cost of not being consistent).

I remember I saw those lines some days ago:
"The operating system is no longer the most important layer for us... What is most important for us is the app model and the experience."
So it is obvious that WinUI should be the best GUI experience, and I think that it will be, like the best of WPF, UWP and Windows 10,

But it is obvious that the Web and its old javaScript+HTML is being used everywhere, and their web frameworks and stacks are being using massively, not because they are better, but because they are readily available on the phone webbrowser, and desktop webbrowser. You can create a HTML file in Notepad, put a Script tag with an alert('Hello World'); and you have an App.

So I see that it is possible and even necessary to replace it with .NET+XAML using WebAssembly. We need .NET to be equally ubiquitous as javaScript is today.

Silverlight was a light of hope... and now with WebAssembly, I see that it is possible to Silverlight to return.

I would be happy with this:
WinUI being the full OS powered GUI and at least a subset of its XAML being able to run on the WebBrowser.

So I see UNO team as very important, and hope that they will join Microsoft in a near future to join forces on this wonderful effort that is the WinUI.

@MarkIngramUK Yesssss

Make WinUI the best UI choice for anyone considering native Windows development. Finish:

• Input validation & a native datagrid control
• The other ~170 feature proposals here
• The other ~300 open tickets
• .NET Native > .NET Core migration (for .NET Core 3+5, .NET Standard 2.1+, and C# 8...)
• New AOT compiler
• Get more coherent fluent design guidelines flushed out and published
• Refine the style/theme system
• De-emphasize distracting composition features (tilt, heavy acrylic usage, reveal) and focus more on the depth+shadow system & animations (which bring clarity and guide users)

These are the things that will make WinUI more appealing to people considering it vs. Electron in the future.

The icing on the cake would then be:

• Tool(s) to help keep your CSS <-> XAML styling in sync
• Guidelines for keeping app logic separate from views for maximum .NET code reuse on other platforms
• Some tool to generate a one-time rough translation of HTML > XAML controls to get devs started with their native WinUI apps (rather than assuming most devs are going to be starting with XAML apps and a desire to head towards HTML)

2. We need a UI framework that is as close to the OS as possible. With cross-platform, there is always a trade off. Either lowest common denominator for functionality, or inconsistent control rendering due to custom rendering.

@MarkIngramUK Silverlight was cross-platform, full featured and rendered exactly the same on all platforms. Qt is cross-platform, full featured and renders exactly the same on all platforms. You only get inconsistent rendering and lowest common denominator controls if you try to realize your controls by internally translating them to native controls of a different platform (which is what Xamarin and Uno try to do). If you do the abstraction not on control level but on the lowest level (the GPU rendering layer), you can get 100% same output on all platforms with the complete control set. The control set is already there, it is WinUI 3.0, and it is a great one even now. The only thing that is missing is rendering layer implementations for the other platforms (and they could be partially taken from old Silverlight sources).

I'd really like to do cross-platform app development. But neither Xamarin nor Uno look appealing to me and I don't really like JS/HTML and everything that is based on it. Unfortunately, developing exclusively for Windows Store is a bad choice if you intend to actually make money with it. At least I had rather bad experiences with that, and then after Microsoft killed Windows Phone ecosystem, I've more or less put an end to it (despite some small "just for fun" projects). I'd instantly start working on new apps again if WinUI was going cross-platform.

All current cross-platform frameworks have more or less severe limitations and/or a poor development experience. If Microsoft could make WinUI cross-platform, it really could be a breakthrough technology. Xamarin is already pretty successful, despite all its edges and corners and limitations. Just imagine how successful WinUI could be if it would run on all platforms with full feature set and the top notch Visual Studio dev experience.

@lukasf , this is my point:

Silverlight was cross-platform, full featured and rendered exactly the same on all platforms.

I don't want the same rendering on all platforms. I want each application to look consistent with other applications on the target platform. That's why the native controls need wrapping - but then that leads to lowest common denominator.

@MarkIngramUK I see it like this: Simple apps stick to the stock UI controls of a platform. Great apps have their own look+feel. They don't need stock platform controls. Look at Spotify, Netflix or other great+successful apps available for multiple platforms. You can't tell the platform they use, just by looking at their controls.

I'd want my cross-platform apps to look and feel exactly the same on all platforms.

@MarkIngramUK Glad that you are touching upon reality beyond theory. Here is the reality for me: I have a bunch of apps that evolved from SL/WP > WinRT > UWP that needed to target multiple platforms yesterday. I looked into Phonegap/Cordova, and spent a lot of time exploring Xamarin very seriously, and gave up eventually. I fell in love with Uno for many reasons as soon as I started using it. At this moment I do not know any other promising practical X-platform technology friendly to C# and Xaml that I can use right now. When WinUI evolves into a X-platform API 1, 2, or 3 years later, the top-notch Uno folks will migrate Uno from UWP to WinUI, and all my Uno based apps will be able to migrate accordingly and quickly. I have nothing to worry about now.
By no means, I am against intriguing theoretical discussions here. Love to hear all kinds of ideas.

Can't WinUI / MS leverage from the Blazor project to render WinUI as a "Blazor Native" App ?

I know Steve Sanderson presented Blutter where Google's Flutter can be rendered using Blazor (and that's a XML based UI). It seems the Blazor team has some nice tech on the UI rendering side to leverage different UI frameworks. If Blazor can handle Flutter it should be able to handle a WinUI / Sillverlight type equivalent.

The potential is a less fragmented MS ecosystem and way more powerful, starting at the web and ending with native apps x-platform using a unified .net 5.

@lukasf :

@MarkIngramUK I see it like this: Simple apps stick to the stock UI controls of a platform. Great apps have their own look+feel. They don't need stock platform controls. Look at Spotify, Netflix or other great+successful apps available for multiple platforms. You can't tell the platform they use, just by looking at their controls.

I'd want my cross-platform apps to look and feel exactly the same on all platforms.

We combine both approaches for our apps (https://affinity.serif.com). Our customers can be quite vocal if we don't adopt common platform standards e.g. ordering of buttons on dialogs (Windows is normally OK then Cancel, whereas macOS is Cancel then OK), buttons with round corners, hover states, checkboxes vs switches, layout of controls etc. So yes, on the surface, our apps look the same on Windows and macOS platforms, but we have subtle differences (rendering and UI interaction). We also take full advantage of our host platform by using their native APIs, and therefore we're never subject to lowest common denominator problems.

I still think the above discussion is misleading, WinUI is the lowest level UI framework that Microsoft provide. If you want a cross-platform library, then build on top of that. It's the equivalent of saying, "Win32 should be cross-platform!". No, Win32 should be the best framework for the Windows platform. It's the same argument here, WinUI should be the best framework for the Windows 10 platform.

@MarkIngramUK wrote:

WinUI is the lowest level UI framework that Microsoft provide. If you want a cross-platform library, then build on top of that.

That strikes me as a practical solution that could really succeed, depending on the details (although not necessarily the only solution). Two layers:

1. Microsoft WinUI: Not cross-platform.
2. Microsoft CrossXYZ-UI: Cross-platform. Its internal implementation for Windows would be written using WinUI.

Such a 2-layer solution would help mitigate the problem I mentioned in my original message:

Potentially new versions of WinUI might be substantially delayed because of the increased amount of work/difficulty of maintaining support for multiple different operating systems. For example, "We could have released this new version of WinUI already, months ago, except for the problem that we've finished debugging it only for Windows and not yet for Android nor MacOS nor Apple iOS."

According to my experience with cross-platform development in the past, I'd note that this 2-layer solution would be more successful if various changes/additions are implemented in WinUI for the purpose of supporting and assisting the separate cross-platform "CrossXYZ-UI" layer. Otherwise, if WinUI does nothing to assist the cross-platform layer, then in my experience, this usually means that the cross-platform layer is often forced to jump through contorted hoops that make the programming and reliability difficult and delayed.

According to layering theory, WinUI doesn't need to know or care about a "CrossXYZ-UI" layer that uses WinUI, but that theory functions poorly in practice in the real world, therefore I say that WinUI would need to take into account and assist the "CrossXYZ-UI" layer, but I don't mean the horrible idea of creating dependencies on "CrossXYZ-UI" inside WinUI, and I don't mean special private hooks inside WinUI that are only used by "CrossXYZ-UI". The 2 layers should still be kept separate in a clean manner. I'm just saying that when API design decisions are made for WinUI, these decisions would need to be performed with consideration for their impact on the separate "CrossXYZ-UI" layer, and with consideration for how WinUI can make life easier for the "CrossXYZ-UI" layer, not only with consideration for apps that directly use WinUI.

I don't know whether Xamarin already attempts to operate in the above-described 2-layer manner, but if it does, then I imagine it currently excludes the part of the idea where WinUI supports/assists the separate cross-platform layer. It's difficult to trust Xamarin when Microsoft didn't trust Xamarin enough to use it for Microsoft Teams and various other Microsoft apps.

In the past, I published cross-platform software that functioned successfully and with good performance, but I ended up cancelling the cross-platform work because of non-technical reasons. For example, the customers using the Linux version of the software insisted that the price of the software should be $0. Thus the cost of producing and maintaining the Linux version far exceeded the $0 of income from the "customers" using Linux, thus it was obviously unsustainable.

As an app developer, just because you _can_ theoretically produce a cross-platform app, it doesn't always mean you _should_. Interestingly, I notice in cross-platform discussions nowadays that people mention Android but not Linux anymore. One of the biggest reasons for this shift is probably the aforementioned $0 problem.

Re Uno Platform:

Even if Uno has good solid reliable technical design and implementation, the risk and worry is that Uno might disappear within a few years because of a similar $0 problem or insufficient income that eventually triggers burn-out and project cancellation or stagnation. Or simply Uno's most important developer one day suddenly obtaining a new hobby/interest/obsession and losing interest in Uno, or a new job/employer and no more time to work on Uno. As @mdtauk said:

a lot of companies looking to invest in building an app or system, needs to know the platform they are developing for has the support and longevity of a big company with vast resources like Microsoft.

I'd also agree with @mdtauk's other comment:

The problem with that argument is that the past decade has shown Microsoft abandoning platforms,

Yes Microsoft has lost some degree of reputation/trustworthiness/dependability via cancellation of platforms. I think Microsoft needs to be careful to avoid any further loss of reputation and trustworthiness via further cancellations. A new version of an existing platform is better than a new platform.

Even if a major new version of an existing platform needs to introduce breaking changes, it's still better (or less bad) than a new platform with accompanying loss of reputation/trustworthiness/dependability. For app developers, the cost of switching to a new platform is very high and sometimes completely unaffordable, therefore anytime Microsoft cancels a platform, it is very bad news and damages the relationship/partnership between the app developer and Microsoft.

If you guys find that two layer approach so appealing, then you can go on right now and use Xamarin or Uno. You don't have to wait for such frameworks, they are already there and they work very well. But you will loose all the benefits and improvements from WinUI as soon as you target Android or iOS. No more NavigationView, no AppBars, no more SemanticZoom, etc etc. Anything that is done in this repo, all the improvements are not available cross-platform, because cross-platform then means lowest common denominator. You could only use them if you specifically target the Windows platform. So you will have to re-implement all the cool WinUI stuff again manually, using Android or iOS native controls.

If that sounds good to you, just use Xamarin or Uno. There is no need for a third framework like this. But to me this does not sound good at all. I want one framework with a great control set, that can be used to target all the platforms directly, with full functionality on every platform. I don't want to re-implement my app's navigation and stuff on each platform separately, having complicated and duplicate UI definitions. To me that sounds like a horrible idea. If WinUI was cross-platform using renderer approach, I could directly use all its feature and every improvement here on every platform. And if I'd want my controls to look more like iOS on that target, I could just apply an iOS ResourceDictionary. Problem solved, without having to mess with native controls and duplicate UI implementations.

The argument that releases would be delayed because a "renderer for other platform was not updated" is an unrealistic argument. A rendering layer works on low level drawing commands like "draw rectangle, draw line, draw text". If you add a new control to WinUI, you write your control logic and you provide a control template, which uses Grid, Borders, TextBoxes and stuff like that. No new control will require updates to the renderers, the renderers will be very low level and with very low rate of changes. There are only rare cases where the renderers would need to be touched, e.g. when adding new brushes or effects. Qt uses the renderer approach and it is one of the most popular cross-platform UI frameworks. The approach seems to work very well for them.

@lukasf

I want one framework with a great control set, that can be used to target all the platforms directly, with full functionality on every platform.

Every engineer and dollar spent making WinUI cross-plat is an engineer and dollar that could have been used to make WinUI on Windows better.

The argument that releases would be delayed because a "renderer for other platform was not updated" is an unrealistic argument.

It is not just a simple task to create a perfect 1:1 rendering engine that works on iOS, Android, MacOS, Linux, and Windows 7/8. There are a tremendous number of Windows 10 APIs that apps & the framework rely on. You'd essentially be creating a completely new app framework.

Also, look at this recent Reddit thread: What should I use for user interface in C#

Literally zero mentions of WinUI, and a single half-recommendation to use UWP. Developers need to be enthusiastic about using WinUI on Windows long before trying to make it cross-plat, considering all the huge investments that would require.

@lukasf,

you can go on right now and use Xamarin or Uno

I alluded to it in my previous post, but we write separate front ends for each platform we target. Windows (WPF), macOS (Cocoa), iOS (UIKit).

if I'd want my controls to look more like iOS on that target, I could just apply an iOS ResourceDictionary. Problem solved

Until the user updates their OS and all of the apps change appearance, except for yours.

A rendering layer works on low level drawing commands like ...

You need more than rendering for cross-platform. Window management, input, text handling, rendering, system integration (e.g. Taskbar / Aero Peek etc). There's no way that attempting to change WinUI's focus from Windows-only to cross-platform wouldn't cause an extreme delay.

In terms of rendering, WinUI is built on Windows.UI.Composition, so you would have to completely replace that lower level library, with something that was cross-platform, and hopefully not incur any performance penalties from your abstraction, and then port it to other platforms. Or, completely re-write WinUI to not depend on Windows.UI.Composition. Again, no small job.

Just to re-iterate - I'm not against cross-platform libraries. They serve a purpose, I just don't think WinUI should become one.

@lukasf

because cross-platform then means lowest common denominator. …... I want one framework with a great control set, that can be used to target all the platforms directly, with full functionality on every platform.

You want it with full functionality on every platform -- me too -- sounds wonderful; a dream -- but just because you and I want it, doesn't mean it must be possible and practical. The wish and the result could be very different. The wish could be full functionality while the result ends up being mostly the same problem as you mentioned -- lowest common denominator. Your idea has merit but it's not immune to falling victim to the lowest common denominator problem that you mentioned.

If WinUI was cross-platform using renderer approach, I could directly use all its feature and every improvement here on every platform.

Really ALL its features and EVERY improvement on EVERY platform? Are you sure that such an impressive goal can be achieved merely by basing WinUI on a cross-platform renderer? So easy is the solution? I think you're making the idea seem far easier than it is in reality, because actually much more than the renderer is required, such as:

• Window management plus flyouts, popups, context menus, modal dialogs.
• Display management and resolutions and responding to changes.
• Input devices (keyboard, mouse, touchscreen with gestures, pen).
• Animation.
• Fonts and styles, getting info and measurements, not only rendering. Also unicode text processing.
• Drag and drop.
• Clipboard cut/copy/paste that works with various formats, not only text.
• Scrolling with good performance, unlike the awful scrolling performance of chat panes in MS Teams.
• Reading/loading resources (of various kinds) stored inside the app package, such as image resources and others.
• Audio and video playback.
• Automation for screen readers etc for accessibility.
• Theme/appearance consistent with whatever is currently configured in the OS.
• Retrieval of various OS settings that affect GUI, such as international formatting, mouse and keyboard settings, etc.
• Issues to support mobile devices plus tablets plus desktops.
• And various other things plus hundreds of details that are easily forgotten when estimating the project size and release date.

I still think your idea has merit but it's much more difficult and much less clear than you made it seem. It could also slow down the development and progress of WinUI very much.

Can't WinUI / MS leverage from the Blazor project to render WinUI as a "Blazor Native" App ?

@pinox, yes we definitely could, but then Blazor Native wouldn't be cross-platform, unless they targeted Uno (which would be my personal preference).

Cross-plat is definitely something we've thought about, and we've done some fairly thorough investigations of different cross-platform framework architectures. We've come to the same conclusions that everyone on this thread has, which is that both solutions have pros-and-cons, and that our customers are fairly split 😃

@lukasf I think the "lowest common denominator" that currently exists in Uno is a resource limitation issue, and not due to layering. I would love to be proven wrong, but I think that issue could be solved, and not be made any worse in the future.

There is having a subset of XAML to offer rendering of native looking UI controls and windows - or you could own the renderer on macOS, iOS, Android, Linux - and render the same "Fluent" controls and templates on all platforms.

Apart from making some kind of variant of the CoreWindow / App Window implementation to work with the native OS - everything inside the window, could be rendered.

On Windows it's DirectX, but Apple has Metal, and Linux has OpenGL. Devs would have to do some kind of IF statements to handle native file IO, Notifications, etc - but Xamarin would help with that

@stevenbrix -- I see you replied to @Pinox's idea _"render WinUI as a Blazor Native App",_ but what do you think about Pinox's _other_ idea? Interestingly, @Pinox also wrote:

Currently Electron is using Javascript , HTML + CSS. No reason why we can't use Electron with Blazor => C# , HTML + CSS + gRPC.

@Pinox -- I'd agree that "Electron C#" would appear to make much more sense than "Electron JS", but if it uses C# and Blazor as you suggested, then I think the MS Teams app probably wouldn't need Electron anymore because Blazor would completely replace Electron? I could be mistaken -- I don't know enough about what features Electron supports. Although, if ElectronJS currently has any useful feature that Blazor lacks, then this missing feature could be supported in the next version of Blazor, potentially.

So I guess you raised an important point by mentioning Blazor. A decent solution for the MS Teams app might be to switch from ElectronJS to Blazor + WebAssembly. That's really interesting.

If the MS Teams app switched from ElectronJS to Blazor, then it might or might not use any part of WinUI. Either a connection or non-connection between Blazor and WinUI could be explored further, as you already started doing. Interesting!

Silverlight, WinRT, UWP - were all abandoned. (I know UWP isn't technically, but WinUI will most likely be seen as a replacement).

My understanding is that UWP is the runtime, whereas WinUI is the GUI / widget layer / etc. I.e. Win UI will run on Win32, or .NET, without the UWP API.

The thing that drives me nuts is that UWP is actually a pretty competent API. It's not as powerful as Win32, but compared to Android (for example) it is so much saner. I think developers have missed the point that there is now a unified runtime API, that has a consistent object model, API, isn't obtuse, etc, etc.... did anyone else here write Win32 apps back in the 90s or early 00s before .NET was on the scene? Using the native platform APIs were terrible.

Back to the issue at hand, I absolutely would love to see WinUI cross platform. There are posts about it being tied to COM etc... Apple's Core Foundation plugin (CFPlugin) framework is, IIRC, based on COM, so maybe a lift and shift would be as simple as writing a renderer for Apple platforms. The more logical thing would be to facade the platform differences and keep the high level WinUI objects.

I would love to see a cohesive, cross platform effort from Microsoft, that targeted Windows primarily, but bought a completely compatible object model and XAML dialect to mobile, Linux and macOS. There is already a fantastic cross platform ecosystem (minus a GUI) in .NET Core. Bolt on a competent XAML framework and it would be a no brainer for all client side development, particularly if the visuals could look native. For example CommandBar -> NSToolbar appearance on Mac, Navigation View -> NSOutlineView on a Mac, etc.

My 2c worth, but I see a big focus on this.

I am also hopeful (though I shan't hold my breath) that Microsoft will re-enter the market with a Windows based phone. Being a cogent cross platform environment would massively help this goal.

I shall watch this discussion with interest.

Silverlight, WinRT, UWP - were all abandoned. (I know UWP isn't technically, but WinUI will most likely be seen as a replacement).

My understanding is that UWP is the runtime, whereas WinUI is the GUI / widget layer / etc. I.e. Win UI will run on Win32, or .NET, without the UWP API.

Technically I think WinRT (Windows RunTime) is the runtime, and the UWP (Universal Windows Platform) is built on top of that runtime. And UWP supports using XAML as one UI framework.

WinUI will be the XAML part of UWP, but expanded to enable it to be used with Win32 code, with interop through XAML Islands with the WPF and WinForms frameworks.

The thing that drives me nuts is that UWP is actually a pretty competent API. It's not as powerful as Win32, but compared to Android (for example) it is so much saner. I think developers have missed the point that there is now a unified runtime API, that has a consistent object model, API, isn't obtuse, etc, etc.... did anyone else here write Win32 apps back in the 90s or early 00s before .NET was on the scene? Using the native platform APIs were terrible.

UWP is built with a modern approach to battery life, security, identity, store validation - all the things developers have come to expect from platforms like macOS, iOS, and Android. It is because of those inherent qualities, that it can work across many form factors and device types.

Back to the issue at hand, I absolutely would love to see WinUI cross platform. There are posts about it being tied to COM etc... Apple's Core Foundation plugin (CFPlugin) framework is, IIRC, based on COM, so maybe a lift and shift would be as simple as writing a renderer for Apple platforms. The more logical thing would be to facade the platform differences and keep the high level WinUI objects.

When you factor in .NET Core support, which is already supported cross-platform, the UI layer is the part that is missing. WinUI initially is entirely focused on Windows, but hopefully in time, Microsoft can refactor it in such a way, that platforms can substitute their own rendering which would allow identical UI to run on multiple platforms.

I would love to see a cohesive, cross platform effort from Microsoft, that targeted Windows primarily, but bought a completely compatible object model and XAML dialect to mobile, Linux and macOS. There is already a fantastic cross platform ecosystem (minus a GUI) in .NET Core. Bolt on a competent XAML framework and it would be a no brainer for all client side development, particularly if the visuals could look native. For example CommandBar -> NSToolbar appearance on Mac, Navigation View -> NSOutlineView on a Mac, etc.

As soon as you start looking at it in this way, where you are translating Windows to Platform Native controls and concepts, you end up with Xamarin Forms. You target a lowest common denominator approach, rather than allowing an Identitcal UI to run everywhere.

My 2c worth, but I see a big focus on this.

I am also hopeful (though I shan't hold my breath) that Microsoft will re-enter the market with a Windows based phone. Being a cogent cross platform environment would massively help this goal.

I shall watch this discussion with interest.

I think one piece of this story, yet to be detailed is enabling UWP apps to compile to, and run on Android - which would solve the issue of apps running on the Surface Duo.

There was the Astoria project... The Android on Windows Bridge, which could come to Windows to allow Android apps to come to the Microsoft Store. Once Microsoft has their own Android codebase, that makes the prospect easier to conceive.

I see you replied to @Pinox's idea "render WinUI as a Blazor Native App", but what do you think about Pinox's other idea? Interestingly, @Pinox also wrote:

Currently Electron is using Javascript , HTML + CSS. No reason why we can't use Electron with Blazor => C# , HTML + CSS + gRPC.

I'd agree that "Electron C#" would appear to make much more sense than "Electron JS", but if it uses C# and Blazor as you suggested, then I think the MS Teams app probably wouldn't need Electron anymore because Blazor would completely replace Electron? I could be mistaken -- I don't know enough about what features Electron supports. Although, if ElectronJS currently has any useful feature that Blazor lacks, then this missing feature could be supported in the next version of Blazor, potentially.

@verelpode as I understand it, Electron will always need to be in the picture. If Teams were to hypothetically move to Blazor, they would still want a standalone client app like they do today, and Electron makes the most sense for them. In theory, and someone can correct me if I'm wrong, but switching to Blazor + WebAssembly would make their app performance much better when running in Electron. Although I would wager their performance issues are due to architectural issues more so than anything else, VS Code is an Electron app and I'm very impressed with the performance there.

Keep in mind that WebAssembly may also run outside the WebBrowser...
I see Blazor as a way from those coming from ASP.Net, an experiment bringing the .NET to the WebBrowser, but the most complete path would be XAML on .NET Core, Xamarin, UWP/WinUI and UNO; The full XAML on WinUI /Windows 10 and a part of its XAML also being able to run on the Web.

@verelpode @stevenbrix My understanding is that Blazor runs on the wire in Electron. So directly from .net core to Electron with the use of gRPC. Therefor the gRPC channel communicates with electron and no longer the JS renderer I assume. Plse correct me if I'm wrong. There is no WASM involved.

It would be really interesting to see the speed improvements using gRPC directly with Electron. In my mind it can be massive if optimized.

In Steve Sanderson youtube clip he mentions the use of no WASM ( 53:13 min into video )
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Can't remember where I read the gRPC part, Anyways, therefor me probing the community if something like a Silverlight equivalent of WinUI using gRPC with Electron is possible ? No WASM , on the wire so to speak.

@verelpode @stevenbrix My understanding is that Blazor runs on the wire in Electron. So directly from .net core to Electron with the use of gRPC. Therefor the gRPC channel communicates with electron and no longer the JS renderer I assume. Plse correct me if I'm wrong. There is no WASM involved.

It would be really interesting to see the speed improvements using gRPC directly with Electron. In my mind it can be massive.

In Steve Sanderson youtube clip he mentions the use of no WASM ( 53:13 min ) into video.
https://www.youtube.com/watch?v=uW-Kk7Qpv5U

Thanks @Pinox! Looks like I have some watching to do! What you're describing sounds like server-side Blazor to me, I was thinking/talking about client-side that runs in the browser and directly manipulates the DOM. I won't say anymore until after I watch that video, because I could be putting my foot in my mouth by saying such things 😄

@stevenbrix you might be right but the electron app runs offline therefor me assuming this is not server side rendering.

My guess would be if the JS renderer used gRPC to speak to Electron then you can use the blazor razor engine todo the same.

gRPC is a new feature in .net core 3.0. Blazor support .net core 3.
Therefor gRPC in .net core 3 opens up the possibility to replace exiting JS technologies with c# by using the "common link" (gRPC) . Clever move MS ;))

but the electron app runs offline therefor me assuming this is not server side rendering.

@Pinox - yeah that has me a bit puzzled. I'm guessing that it's using https://github.com/ElectronNET/Electron.NET, but that's purely speculative

f the MS Teams app switched from ElectronJS to Blazor, then it might or might not use any part of WinUI. Either a connection or non-connection between Blazor and WinUI could be explored further, as you already started doing. Interesting! >

@verelpode what makes this image very exciting is the "reach" of Blazor. As a app guy I can say my limited experience with Blazor so far is => wow this feels extremely performant , almost app like. Looking at the image the roadmap will almost certainly include WinUI as a native platform. (although uncommitted currently)

If they can make flutter work on the Blazor Native side what stops the Blazor team from plugging in the React Native platform to reach all those native platforms. Blazor can very easily become the glue for C# developers into everything.

For me the short term goal is to get on the bus with a HTML UI to compliment my existing WinUI.
Between WinUI / Xamarin and Blazor there is almost nothing I can't do. One code base , 3 UI frameworks. It's going the be extremely exciting to see where this goes because the options seems endless.

To me the ultimate is always super performant .net core (C#) => Blazor ??? => native UI's - it will be the ultimate engineering effort.

I have to say that this is a very inspiring discussion! Lots of different views and arguments, lots of facts I did not even know ("Blazor + Native UI?? Wow").

As @stevenbrix already mentioned, there seems to be a split in the community between those who'd like to run the exact same UI on different frameworks (renderer approach) and those who'd like to render on each platform using the native controls. Both approaches have their benefits and downsides. I agree with @stevenbrix that with enough manpower, the "lowest common denominator" problem could be overcome (e.g. a WinUI control not available natively on platform X could internally be realized in Uno by a bunch of lower level native controls from that platform X, or with partial custom rendering). Then we could have almost the full WinUI control set available, but still get native rendering. Unfortunately, Uno's resources seems to be rather limited right now, given the large number of open issues on their github.

What is obvious here is that there is a high demand in the community for a compelling, high-performance, cross-platform framework. And none of the currently available frameworks really satisfies any of the two sides of the (split) community. It will be very interesting to see if Microsoft has any plans to improve the situation.

I'd say, with Surface Duo and Neo on the horizon, Microsoft must come up with a proper story of how to develop cross-platform apps that run on both the Surface Duo and Surface Neo. Maybe Microsoft should buy Uno and properly fund them, so they can fix all those open issues and add more control support. Or develop an Android rendering layer for WinUI. With devices planned for Holiday 2020, things have to start moving pretty soon.

@lukasf

with enough manpower, the "lowest common denominator" problem could be overcome

Enough manpower... I agree with everything in your message, but I'd also like to emphasize the significant downside that @kmgallahan mentioned:

Every engineer and dollar spent making WinUI cross-plat is an engineer and dollar that could have been used to make WinUI on Windows better.

I'm split because on one hand, cross-platform would be great (if it truly works well), but on the other hand, I wouldn't want cross-platform if it causes big delays in the fixing of various problems in WinUI on Windows, or if it bogs down the progress of WinUI too much and stymies improvements and new features.

What if the cross-platform topic means that we're all forced to choose between one of the following outcomes?

1. An excellent version of WinUI that runs only on Windows; or
2. Medium quality, unreliable, and/or slow WinUI that runs on every platform, and that suffers from an excruciatingly slow pace of development with many outstanding problems remaining unfixed for 5 to 10 years.

That's a big problem that would need to be prevented. In the excitement for cross-platform, it's very easy to accidentally stop paying attention to the prevention of this big problem.

What if the cross-platform topic means that we're all forced to choose between one of the following outcomes?

1. An excellent version of WinUI that runs only on Windows; or

2. Medium quality, unreliable, and/or slow WinUI that runs on every platform, and that suffers from an excruciatingly slow pace of development with many outstanding problems remaining unfixed for 5 to 10 years.

@verelpode First, you are exagerrating a lot here. Second: Microsoft has vast resources at hand. It should not be a problem at all to fund both native WinUI improvements and a cross-platform solution, if Microsoft is really interested in providing a cross-platform framework. Actually they are doing that right now: They develop and improve WinUI, and at the same time they develop and improve Xamarin. They have lots of projects going on at the same time. So if Microsoft is really committed to providing both a great Windows UI framework (which they sure are) and providing a cross-platform framework (which would make lots of sense with Surface Neo and Duo on the horizon), then we don't have to choose. Both can be realized without compromise. (And generally it's not like this is something we can choose. Microsoft will take their decisions and we will get to see what the outcome is.)

So funding a cross-platform framework does not mean at all that WinUI development and stability would have to suffer. If the Uno strategy was chosen, Uno is completely independend of WinUI, because it sits on top. WinUI can be further evolved, and Uno tries to pick up new WinUI controls and concepts (probably at a slower rate). Also if a renderer approach was chosen, it does not mean that it will delay WinUI on Windows. It could be that a new WinUI version is released but there is no Android renderer yet. Then cross-platform development would use the older WinUI release, until Android renderer is updated to WinUI vLatest. Windows developers could use WinUI vLatest right from the start. If the resources are there, both can be developed at same pace.

@lukasf

Microsoft has vast resources at hand.

True, true, but there exists another side of it that is also true: Many project managers have learned the hard way that throwing more money, staff, and resources at a project doesn't necessarily produce success.

Microsoft has vast resources at hand.

True, true, but there exists another side of it that is also true: Many project managers have learned the hard way that throwing more money, staff, and resources at a project doesn't necessarily produce success.

Then the problem may be those project managers and organizational structure ;)

Maybe Microsoft should buy Uno and properly fund them, so they can fix all those open issues and add more control support.

I know nventive has been courting Microsoft for the past several months (a Microsoft acquisition is probably their exit strategy). At Uno Conference there was also a large participation of Microsoft. Even Xamarin is using Uno now to support the web.

I know we can debate the options (1) native renderes or (2) another UI implementation/layer endlessly but looking at what is available now and what we need for surface Duo, Uno is actually the only solution that makes sense. As @lukasf said Microsoft should throw their resources behind it and see how far they can get in a year. If it's successful (feature complete, stable), I don't think developers will really care much about how it's implemented behind the scenes. If it does become apparent that the correct approach is WinUI natively rendered for each platforms that can be a discussion for a few years down the road. Right now it's better to start with a 25% complete Uno platform than nothing at all.

@stevenbrix here:

@lukasf I think the "lowest common denominator" that currently exists in Uno is a resource limitation issue, and not due to layering. I would love to be proven wrong, but I think that issue could be solved, and not be made any worse in the future.

You guys are wrong.
Uno doesn't follow that 'lowest common denominator' mantra of Xamarin, but the opposite, it rather attempts to make sure all XAML controls (and even Windows Community Toolkit!), work on all platforms.

Uno doesn't follow that 'lowest common denominator' mantra of Xamarin, but the opposite, it rather attempts to make sure all XAML controls (and even Windows Community Toolkit!), work on all platforms.

@weitzhandler you are totally right! I believe their architecture will lend themselves to one day have complete parity with the WinUI control set, which may not be possible with Xamarin.Forms. If I understand correctly, that control set just hasn't been built out yet, which is what @lukasf and I were referring to. I could be wrong though, I haven't played around enough to know, I'm just trusting what I've heard from everyone else :)

@weitzhandler Uno's approach of re-implementing the real UWP/WinUI APIs is much better than Xamarin's inventing of a new XAML dialect. But if you run the Uno Xaml Controls Gallery, you will find quite some areas empty. Their control set is sure better than Xamarin.Forms, but it is not nearly a complete UWP/WinUI yet. I think Uno needs more work on the API surface, and also more work on getting the available controls really stable and full featured.

I could see Uno as a vialble option. But it needs some real progress, which is where Microsoft could come into play.

In a different point, I completely agree to what @lukasf said here:

Great apps have their own look+feel. They don't need stock platform controls. Look at Spotify, Netflix

I also think that ideally, the solution is to have WinUI + Fluent design render the same on all platforms, and perhaps provide native-look-and-feel themes for those who need the stock design, to be applied on the specific platforms.
I reckon web should be the same as desktop, so only Droid and iOS are candidates for that anyway.

Cross-platform controls are actually independent of cross-platform frameworks.

Hypothesis: in the future .Net controls will not be restricted to particular platforms.

There are existing .Net UI cross-platform frameworks (Xamarin.Forms, Avalonia). There will also be FutureXplatDotNetUI which everyone is dreaming about and no-one can quite define.

When you create a control you can make it use platform-specific features. E.g. a video player using native players on each platform. Or you could do it in a platform-agnostic way, e.g. using SkiaSharp.

Either way, your control is installable into any .Net UI project.

Corollory: FutureXplatDotNetUI will only need a minimal set of controls

It will need to define a View class and layout infrastrcture, but specific views or groups of views can be added by installing standard .Net UI packages from nuget.

(This post is a comment on cross-platform .Net UI and is therefore unrelated to WinUI.)

I have a feel that the WinUI team's current priority is not for "new native Windows applications". Instead they are focusing more on modernizing existing apps, and making WinUI the underlying support of some higher-level UI framework...

@reli-msft
I have a feel that the WinUI team have already give up expecting people to write new native Windows applications, and WinUI is designed for upgrading existing apps

Coming from a person who works at Microsoft that is kind of weird.

I have a feel that the WinUI team have already give up expecting people to write new native Windows applications, and WinUI is designed for upgrading existing apps

Coming from a person who works at Microsoft that is kind of weird.

@weitzhandler
I should use a more accurate the word I used... It's not "giving up" but "care less about". Anyway that's just a feel from someone outside WinUI team.
But, modernizing existing apps may be more important _for now_, and that may be the reason that WinUI decided to support Win32.

You were talking about what the WinUI team thinks.

As general MS, unfortunately that actually does makes sense.
I wish Microsoft would have given WinUI the love React or Electron or any other HTML CSS and JS tech gets (read my comment above).

@charlesroddie

You always need a framework to develop your controls against. You need base classes to inherit from, interfaces to implement. You need classes to access control trees, templates, etc etc. So you really can't separate controls from frameworks. No control can work in multiple frameworks, unless those frameworks use exactly the same concepts, classes and namespaces.

You could share some code between (C# based) WinUI controls and WPF, but it would still be difficult because of different namespaces and different APIs. But it's plain impossible to share XAML controls with Android or iOS frameworks.

Adding to that, I am really not sure if .NET is the right technology to build a UI stack. Microsoft tried it with WPF and then finally gave up and switched to C++. Having GC breaks during layout and rendering just does not make the best impression to end users, in times where animations get more and more important. Maybe this is not true anymore if a Compositor is available, that takes care of smooth animations completely independend of UI thread. Then the control stack could be C# and only the lowest level rendering and animation part would be native code. But back then, performance was the main reason why C# was completely abandoned in the following XAML UI frameworks (Silverlight and UWP/WinUI).

@lukasf No control can work in multiple frameworks

This is not true. I gave two ways in which controls can work in multiple frameworks. The first approach is writing platform-specific code. Then you need to know the frameworks you support to hook up your platform-specific code to each framework; you can do this right now but the scaffolding can be made easier in future. The second approach (platform-independent rendering) is very easy and is being done right now. E.g. CSharpMath.SkiaSharp can be used across all .Net UI platforms.

@charlesroddie Okay maybe I got your post wrong. But then the control is not really independend of the framework. It can only be installed in those apps whose framework is explicitly supported by the control. And rendering is only a small part of a control. Control logic, data binding and input handling must be implemented for every single supported framework, in every such control, even if you use a platform independend renderer. That does not sound very effective to me, unless the supported frameworks are very similar. As I stated, it is possible to share some code between WPF, Silverlight and UWP. But beyond that it gets really difficult, and I doubt that I will ever see such a control.

A cross-platform framework usually allows you to write all the control logic, data and input handling (and sometimes even the rendering) only once for one API, and then it will automatically map that to each framework. So once the framework is there, control implementation is much more efficient.

It can only be installed in those apps whose framework is explicitly supported by the control.

That's true but supporting more platforms is/can be made easy.

Control logic, data binding and input handling must be implemented for every single supported framework.

Data-binding does not need to be implemented by a UI framework. This is a misconception fostered by prevailing popular but inferior .Net approaches. Controls only need to specify constructors and properties. They do not need to specify any particular way to bind data because once gettable/settable properties are specified consumers can use any approach framework to move data that they want. (And almost any approach/framework is better than WPF/UWP/Xamarin data-binding.)

Control logic is naturally implemented in .Net in a platform-independent way, so that is perfectly catered for in either approach I gave.

Input handling does benefit from a "cross-platform framework", but this can be a very small control framework, which can be referenced in both platform-specific and cross-platform projects, with a very small API that just defines mouse/touch and keyboard input. The SkiaSharp.Extended controls project is moving in this direction.

If you want data binding to work in WPF or WinUI, then you have to declare DependencyProperties. I strongly doubt that anyone would use a XAML control that does not work with data binding. Data binding is at the very hear of these frameworks, and it requires DependencyProperties to work, if you like them or not. If you don't add them, you cannot use your control in any of the current Windows platform frameworks.

With "control logic" I ment more the interaction with other controls, like defining or creating sub-controls for your top-level control, data and status handling between these controls, layout, synchronization with sub-controls. This is all framework specific work. That combined with data binding code (if required by the target framework) and input handling probably makes up >90% of control code. The common part between different framework implementations for one such control is probably so small, it just does not make sense to me to work that way.

I don't say that it cannot be done. But it will be very complicated, since frameworks are so very different. I mean, it is possible to write such a control right now, still I have never seen one. And personally I don't believe that this will become an even slightly popular approach.

you cannot use your control in any of the current Windows platform frameworks

That's not true. A control that does not implement DependencyProperties can be used in WPF/WinUI. This is one of the flaws of traditional .Net data binding: it encourages adding spurious DependencyProperties to controls that already define settable properties. Huge code duplication. (By the way a cross platform control would not be a "XAML control" and you shouldn't be taken in by the misuse of "XAML" in the marketing language of WinUI. Xaml is an optional markup language that can be used with several .Net UI frameworks.)

sub-controls for your top-level control

Yes a control will need to specify sub-controls, so for higher-level controls to be available cross-platform, lower-level ones will be too. If the lower-level controls are available cross-platform then integrating them is easy. You are imagining writing higher level controls before the lower level ones which is not an efficient approach.

The good news is Microsoft already decided to kill .net native.

@robloo I will have a party to celebrate it when this happens.

Even if Uno has good solid reliable technical design and implementation, the risk and worry is that Uno might disappear within a few years because of a similar $0 problem or insufficient income that eventually triggers burn-out and project cancellation or stagnation. Or simply Uno's most important developer one day suddenly obtaining a new hobby/interest/obsession and losing interest in Uno, or a new job/employer and no more time to work on Uno.

@verelpode
I share the same concern probably more than most others. I use much less open-source packages not backed major companies (e.g. Oracle, Google, Microsoft) than average. I believe both of the following conditions have to be met for this to happen:

1. Nventive closes its business. Nventive relies on Uno for its bread-and-butter business.
2. The primary people behind Uno lose their interest in this marvelous project.

As for #1, I have heard Nventive is growing out their current building and moving to a larger facility, so the expanded Uno Conf 2020 (2-day to 3-day) will have a part held in a different building. I am not an economist, so I cannot predict whether there will be a severe recession driving many companies out of business. At least I do not see an economic meltdown in near future right now (the unemployment rate in our area has been below 2% for a while).

As for #2, I rarely see the type of passion that the primary Uno guys have for their project. It is almost like a noble cause, not a mere software product for them. Well, only a fool does not change his mind, so I would not say the probability of their losing interest is zero, but probably not far from zero. To be honest with you, this is the main reason for me to enjoy and stick to Uno right now. Just like any other platform, Uno has many issues (BTW, missing some nice-to-have features is no issue for me.), but they address critical issues rapidly. I think they have half a dozen or more releases every day. One of my apps could not be published due to a known bug of a platform, and it literally took more than half a year for a major company (😉) to fix it (I have archived the ticket).

Based on my extensive experience with Sliverlight, Windows Phone 7/7.1/8/8.1 SDKs, Windows 8/8.1/10 (WinRT, UWP…) (My primary phone was a Windows Phone, the best mobile platform in human history, until the last minute before I had no choice but switching to an Android one this year), I have more confidence on the longevity of Uno Platform than similar things from Microsoft. Yes, Uno is based on all Microsoft technologies, but they take care of migration when Microsoft changes things under the hood.

I have been wondering whether a reason that Miguel endorses Uno and delivered the keynote at Uno Conf is that he sees Uno like his baby Mono in early days, and Nventive like his Ximian.

I do prepare for the worst scenario – decease of Uno. Since all of Uno projects use my two favorite technologies – C# and Xaml, I can migrate them to any emerging platform based on them easily. At least I can say that C# code ages really well. Much of the code in my core utility library shared by all projects is well over a decade old. They still work perfectly, and I suspect they will in the coming decades.

@stevenbrix @weitzhandler @Pinox

An interesting discussion, also noticed Blazor Native being mentioned here as well.

There's been a new NDC conf from Steve with Blazor that might be interesting to consider, the video above using Blazor + Native used Flutter as a renderer. But in a new NDC Conf video Steve now uses Xamarin.Forms to render mobile UI with XAML-like markup. I could see Blazor Native to be the most practical x-platform solution that can work right now with WinUI since it will support React Native in the same vein that I could see it supporting Blazor Native that way. So .Net can now target (Web, Mobile, Win Desktop).

UPDATE:
A new version of MS Teams was released recently, and it improves the time taken to view the most recent chat message. In a previous message, I mentioned that it took approx 27 seconds, but thankfully the new version is faster at showing the most recent chat message.

Thank you to the Microsoft staff members who worked on this improvement. :smile:

My perspective:

Microsoft: Can develop a minimum Webview2 (Similar to Carlo) that can disable almost all feature and reduce to only event binding to HTML UI...possible all others features are developing in C#/native/out of scope from community(As cross platform Native backend library).
I knew how complex the HTML/CSS side but I would love to leverage that UI knowledge and one to one binding on C# code behind etc event code.

Microsoft: Can power off one ram of 8/32gb of those who had 4x 8gb/ 4x 32gb...Saving a lot of energy.

To do this, we get rid dozen of app that develop with Electron...that depend on Microsoft and Bill Gates's goal.

Although best goal is to everyone start develop app and gain traction from some CSS3 standard GUI Framework...possible like QT/GTK... but too bad GTK is not non copyleft, and possible like QML with .net equivalence.

UPDATE:
Cancel what I said in my previous message about the problem being fixed ☹️ It's not fixed. This is bizarre: For a couple of weeks, it seemed like the problem was gone, but then the problem returned recently! MS Teams is again giving me difficulty and delays when simply trying to view the most recent chat message.

The bugginess of MS Teams is unsurprising when you consider that it is written in JavaScript. _Of course_ an app written in JavaScript is buggy -- why would anyone expect otherwise? MS Teams uses ElectronJS which uses JavaScript despite the fact that it's well-known that JavaScript was never intended to be a real programming language, rather it's just a casual scripting add-on for web browsers.

JavaScript doesn't even include compile-time type checking -- that's how bad it is. Hence the need for TypeScript to try to correct this _major_ problem in JavaScript. Actually, it's a very bad problem if you think of JavaScript as a programming language -- JavaScript is terrible as a programming language -- but as I said, it was intended to be a casual scripting language, not a programming language, therefore you can forgive JavaScript for failing to include the essentials of a programming language, because programming apps was not the purpose of JavaScript.

What's not really forgiveable is the incomprehensible decision to use a casual scripting language as if it's a programming language. I was really surprised to see that Microsoft chose a non-professional language for an app as important as Teams. I didn't think it was possible for anyone to say the name "JavaScript" while simultaneously forgetting that "JavaScript" has "Script" in its name because it is indeed a scripting language not a programming language. Somehow the existence of the word "Script" in "JavaScript" has just been completely blended out.

The WinUI team members have been working hard on many improvements to WinUI. Microsoft's decision to use a casual scripting language instead of WinUI makes no sense.

There are a lot of very well written, high performance JavaScript web applications. Sure you could get even better performance with other technologies. But the reason why Teams is slow for you is surely not the fact that it is based on JavaScript. That is caused by some bad implementation on either server side or client side (probably async/threading issues). It would surely be possible to write Teams in JavaScript with a lot better performance.

Don't get me wrong, I am not a JavaScript fan at all. In fact I think it is a horrible language. Just saying that the problems you see are not caused by the fact that Teams uses JavaScript technology. It is even possible to run the Unreal engine in JavaScript with good (not top notch) performance.

WinUI is a Windows desktop framework only. So it was not possible to develop the x-platform Teams application based on it, and even today it is not possible. But maybe the problems with Teams will help Microsoft to consider making WinUI cross-platform. With a true x-platform WinUI and .NET Core it would be a lot easier to develop responsive apps that scale well.

WinUI is a Windows desktop framework only. So it was not possible to develop the x-platform Teams application based on it, and even today it is not possible. But maybe the problems with Teams will help Microsoft to consider making WinUI cross-platform. With a true x-platform WinUI and .NET Core it would be a lot easier to develop responsive apps that scale well.

Using Uno, WinUI is cross platform. Look at the UNO Calculator in the Google Play store. It is a ported version of the Windows 10 calculator.

Someone was asking for UWP vs Electron comparison, here there are a couple:

https://twitter.com/emiliano84/status/1198177284533956608

https://twitter.com/emiliano84/status/1198179206548602881

the new XBOX app it's ridiculous, can take easily 1.5gb of RAM for nothing

would be nice if someone can make a video to show how slower they're compared to UWP

I thought most participants of this discussion regarding WinUI & X-platform have read about this story, but just in case some have missed it, here is WinUI on Windows 7 – Yes, it’s possible with Uno Platform. Once an app is based on Uno, it targets Windows, Web, iOS, and Android.

@lukasf

It would surely be possible to write Teams in JavaScript with a lot better performance.

Yes it is _possible_, and it is also _possible_ to write MS Teams in PowerShell with acceptable performance (I like PowerShell), and it's also _possible_ for SpaceX to relocate to Russia and still manage to launch satellites, but it would still be an incompetent management decision to relocate SpaceX to Russia, or to write the MS Teams app in a scripting language such as PowerShell or JavaScript. If SpaceX moved to Russia, then yes SpaceX could still operate, it's possible, but honestly we would have to say that Elon Musk wouldn't really be an effective manager and wouldn't really know what he was doing.

I am not 100% convinced that Electron is the to blame. Visual Studio Code is said to be based on the Electron, too, but its performance is pretty solid. Electron apps are basically web apps, and there are thousands of reasons behind a badly performed web app.

There isn't much WinUI can do to "win Teams over". It's not the tech, it's the product. Teams is like a startup company that's set itself up on a path of rapid growth. It needs to run on multiple platforms with feature parity, and they need to achieve this as quickly as possible. This is the only reason to choose web-based technology. On mobile they can use React Native because it's the only way to tap into hardware with JavaScript, but on Desktop, they need to maintain feature parity and code maintainability with the web app, the mac, and the Linux version. They have to use a framework that targets win32 because they can't wait around for UWP app model to add features it needs. Being able to do share desktop with the option to choose which desktop or which specific app to share is one of its key features. This is just how startup-like products are developed. Slack used jquery to hack growth when they first started and ended up with really bad code, but once they have had some time to refactor, they quickly rewrote everything with react, and Slack is now much faster than before. WinUI and Electron are not in the same category, and for that reason it will not replace Electron for the apps that really needs it no matter what feature it adds.