Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: WinUI vs ElectronJS and cross-platform (enhance WinUI to eliminate reasons for using ElectronJS instead of WinUI) #1461

Closed
verelpode opened this issue Oct 18, 2019 · 83 comments
Labels

Comments

@verelpode
Copy link

Here is an interesting and useful topic for discussion. 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?

I heard from a few people that the explanation for the painfully slow performance and unusual bugs and quirks in Teams is that it uses ElectronJS instead of WinUI/UWP. Apparently this explains why Teams doesn't behave as well as other apps from Microsoft.

We use MS Teams every day for work purposes and we find it excellent for improving our communication and work productivity, but the painfully slow performance and unusual bugs are frustrating, therefore we wish that Teams (or at least Teams for Windows) was implemented using WinUI/UWP instead of ElectronJS.

Is cross-platform compatibility/portability the reason why MS Teams doesn't use WinUI? Any there any other reasons? What is WinUI lacking and how can it be improved in order to make WinUI suitable for MS Teams?

Although cross-platform WinUI is a nice idea, it's also worthwhile considering the ongoing cost or extra work and possible delays. 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."

Achieving reliable cross-platform portability is a large challenge that also produces some disadvantages, therefore an alternative to consider is to make Teams for Windows use WinUI while Teams for Android and Mac continue to use ElectronJS. Obviously the disadvantage of this path is the ongoing maintenance of synchronizing changes in Teams-WinUI with Teams-ElectronJS.

Thus the question would then become: How can WinUI be improved in order to support ongoing synchronization of changes between 2+ implementations of the same app? Can such synchronization be semi-automated by a new tool etc? What if a new tool can read WinUI .xaml files and use them to auto-generate at least some of the stuff needed for the ElectronJS implementation of the same app?

Related Links

@verelpode verelpode added the discussion General discussion label Oct 18, 2019
@shaheedmalik
Copy link

shaheedmalik commented Oct 18, 2019

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.

@mdtauk
Copy link
Contributor

mdtauk commented Oct 18, 2019

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.

@verelpode
Copy link
Author

verelpode commented Oct 18, 2019

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.

image

@verelpode
Copy link
Author

@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
Copy link
Contributor

mdtauk commented Oct 18, 2019

@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

@zipswich
Copy link

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?

@mdtauk
Copy link
Contributor

mdtauk commented Oct 19, 2019

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

@TonyHenrique
Copy link

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.

@zipswich
Copy link

zipswich commented Oct 19, 2019

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.

@weitzhandler
Copy link
Contributor

weitzhandler commented Oct 20, 2019

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.

@lukasf
Copy link

lukasf commented Oct 20, 2019

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.

@Pinox
Copy link

Pinox commented Oct 20, 2019

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

@zipswich
Copy link

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.

@lukasf
Copy link

lukasf commented Oct 21, 2019

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.

@charlesroddie
Copy link

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.

@robloo
Copy link
Contributor

robloo commented Oct 21, 2019

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.

@zipswich
Copy link

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.

@robloo
Copy link
Contributor

robloo commented Oct 21, 2019

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.

@lukasf
Copy link

lukasf commented Oct 21, 2019

@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!

@zipswich
Copy link

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.

@robloo
Copy link
Contributor

robloo commented Oct 21, 2019

@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.

@robloo
Copy link
Contributor

robloo commented Oct 21, 2019

@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).

@lukasf
Copy link

lukasf commented Oct 21, 2019

@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.

@robloo
Copy link
Contributor

robloo commented Oct 21, 2019

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.

@MarkIngramUK
Copy link

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).

@TonyHenrique
Copy link

TonyHenrique commented Oct 21, 2019

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.

@kmgallahan
Copy link
Contributor

kmgallahan commented Oct 21, 2019

@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)

@stevenbrix
Copy link
Contributor

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 :)

@lukasf
Copy link

lukasf commented Oct 24, 2019

@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.

@weitzhandler
Copy link
Contributor

weitzhandler commented Oct 24, 2019

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.

@charlesroddie
Copy link

charlesroddie commented Oct 24, 2019

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.)

@reli-msft
Copy link

reli-msft commented Oct 24, 2019

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...

@weitzhandler
Copy link
Contributor

weitzhandler commented Oct 24, 2019

@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.

@reli-msft
Copy link

reli-msft commented Oct 24, 2019

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.

@weitzhandler
Copy link
Contributor

weitzhandler commented Oct 24, 2019

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).

@lukasf
Copy link

lukasf commented Oct 25, 2019

@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).

@charlesroddie
Copy link

@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.

@lukasf
Copy link

lukasf commented Oct 25, 2019

@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.

@charlesroddie
Copy link

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.

@lukasf
Copy link

lukasf commented Oct 25, 2019

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.

@charlesroddie
Copy link

charlesroddie commented Oct 25, 2019

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.

@zipswich
Copy link

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.

@RyoukoKonpaku
Copy link

RyoukoKonpaku commented Nov 9, 2019

@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).

snip
snip

@verelpode
Copy link
Author

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. 😄

@meteorsnows
Copy link

meteorsnows commented Nov 29, 2019

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.

@verelpode
Copy link
Author

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.

@lukasf
Copy link

lukasf commented Dec 9, 2019

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.

@shaheedmalik
Copy link

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.

@Panda-Sharp
Copy link

Panda-Sharp commented Dec 10, 2019

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

@zipswich
Copy link

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.

@verelpode
Copy link
Author

@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.

@toyssamurai
Copy link

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.

@nerocui
Copy link
Member

nerocui commented Nov 27, 2020

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.

@github-actions
Copy link

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests