search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.1k stars 660 forks source link

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

Closed verelpode closed 10 months ago

verelpode commented 4 years ago

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

shaheedmalik commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

zipswich commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@MarkIngramUK Yesssss

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

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:

lukasf commented 4 years ago 
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.

MarkIngramUK commented 4 years ago

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

lukasf commented 4 years ago

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

zipswich commented 4 years ago

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

Pinox commented 4 years ago

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.

blazor

MarkIngramUK commented 4 years ago

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

verelpode commented 4 years ago

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

lukasf commented 4 years ago

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.

kmgallahan commented 4 years ago

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

MarkIngramUK commented 4 years ago

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

verelpode commented 4 years ago

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

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.

stevenbrix commented 4 years ago

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.

mdtauk commented 4 years ago

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

verelpode commented 4 years ago

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

knightmeister commented 4 years ago

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.

mdtauk commented 4 years ago

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.

stevenbrix commented 4 years ago

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.

TonyHenrique commented 4 years ago

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.

Pinox commented 4 years ago

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

stevenbrix commented 4 years ago

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

Pinox commented 4 years ago

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

stevenbrix commented 4 years ago

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

Pinox commented 4 years ago

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

blazor

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