Discussion: WinUI vs ElectronJS and cross-platform (enhance WinUI to eliminate reasons for using ElectronJS instead of WinUI) #1461
Comments
|
The same goes with the new Xbox Beta app. It uses a 400MB just being open as a glorified Store. The Microsoft Store uses only 117mb while active. |
|
Until Microsoft develops a cross platform UI framework, which allows for a single UI and control design across all platforms, ElectronJS and it's ilk, will go on being used. |
|
Example of the astonishing speed of ElectronJS/Teams: ( 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.
|
Although I'd generally agree, there must be more to this story than that, because for example Microsoft OneNote is available for Windows, Android, and Mac, but it doesn't use ElectronJS (AFAIK) and doesn't suffer terrible performance like Teams. |
Microsoft has the resources to build apps for each platform, sharing code as much as possible - but not using a shared UI |
|
I would love to hear any arguments against using Uno Platform that targets multiple platforms (Windows, iOS, Android, Web) producing high-performance app packages using UWP API now, WinUI later. It uses everything Microsoft - VS, C#, Xaml, Xamarin, mono, .Net... |
This would have been a better argument some years ago, but a lot of companies looking to invest in building an app or system, needs to know the platform they are developing for has the support and longevity of a big company with vast resources like Microsoft. The problem with that argument is that the past decade has shown Microsoft abandoning platforms, and user bases, and Windows being moved into legacy or diminishing priority within Microsoft. So you can't blame new devs for moving towards web platforms, if they wish to run connected services - or focusing on platforms which are actively being developed, and appear to have strong support going into the future. At the same time there are a few large companies like Adobe, with legacy apps - so moving platforms with those will be next to impossible. There are also hobbyists and businesses with custom software. Microsoft has done well with .NET and Win32 support. And WinUI may be the chance to allow Win32 and .NET - but with a modern UI. Silverlight, WinRT, UWP - were all abandoned. (I know UWP isn't technically, but WinUI will most likely be seen as a replacement). Zune, Windows Media Centre, Windows Phone 7, Windows Phone 8, Windows 8 - let down the enthusiasts and those who they tried to evangelise. How Microsoft positions WinUI and also ensures the future of Windows is secured, will be absolutely essential |
|
WinUI for Desktop looks promissing, but I feel that at least a subset of its XAML must be able to run on the Web; WinUI on the Web, like a new Silverlight but running on .NET 5 and WebAssembly. |
Concur. |
|
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. And lemme be harsh, C# is only a server language with .NET Standard's lack of a UI framework. |
|
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. |
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 |
@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. |
@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. |
Great question. A huge number of users will be very happy if they did this. A large factor is the lack of performance measures comparing frameworks. A page which compares equivalent apps done in UWP and Electron and compares speed and memory usage would be enough. This could extend to other frameworks. From this costs to users, effects on usage, and benefits of code consolidation can be weighed up against the financial costs. The current lack of this research is helping inefficient frameworks to become popular. |
|
Speaking honestly: I doubt MS has any plans to make "WinUI" (Windows UI) cross-platform. On top of that, the fact that it is now open source usually means Microsoft no longer considers it a critical/strategic tech. They are trying to tap the community resources instead to lower internal headcount while keeping it alive. Don't get me wrong, I'm happy WinUI is open source now and appreciate all the time the Microsoft devs are putting into the platform taking it to WinUI 3.0 -- it's a great step to consolidate the windows presentation platform for both native and managed apps. I just don't think Microsoft sees Windows as the future and I don't think they are interested in taking it cross-platform (of course that is their mistake if true). A real cross-platform development framework that doesn't force developers to use sub-par tech is what the world needs. Seems most people here agree. What that largely means is:
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. |
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.
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. |
@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 hear you, I made that statement based on my own app in the Microsoft Store too. |
|
@robloo You have some good points there, but I don't really follow you. Here are some thoughts:
|
@robloo It does not have to be the case. I have been saying all along that it is the worst app store that killed Windows Phone, the best mobile platform. They can kill two birds with one stone: outsourcing the store to a competent third party and end the .Net Native nightmare. It will reduce their cost and (I believe) double, quadruple... Windows app downloads quickly. More than 90% of my UWP app problems are solely related to the .Net Native nightmare. |
|
@lukasf I think you misinterpreted a lot of what I was saying.
I 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.
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.
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.
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.
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.
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.
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. |
The good news is Microsoft already decided to kill .net native. Technically it had a number of ridiculous restrictions that didn't follow .net specifications which it sounds like you are more than familiar with. I think it was something that was done quick/dirty to fix startup and performance problems on windows phone and they never bothered to go back and fix things since windows phone died. Now Microsoft is developing full, high-performance, AOT compilation using Mono technologies and LLVM. This should come out by next year I think and is also useful for client-side Blazor with webassembly. Miquel de Icaza gave a good presentation touching on it earlier this year at UnoConf: https://www.youtube.com/watch?v=tYk2us6W6Gg (he is the first presenter). |
|
@robloo Okay maybe I got you wrong in some points.
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.
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. |
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!
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...
I also agree with you 100% and have stated the same several places. I've come to the conclusion that for a number of reasons it isn't going to happen though. |
|
I can't disagree strongly enough with the commenters saying:
The solution, in my mind, is to have another framework which builds on top of either WinUI 3.0 (if you want to maintain Fluent, and have little work in rendering, hit-testing, etc), or from the ground up with WinUI Composition if you want max performance, and don't mind doing all the rendering and hit-testing yourself (at the potential cost of not being consistent). |
|
I remember I saw those lines some days ago: 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: So I see UNO team as very important, and hope that they will join Microsoft in a near future to join forces on this wonderful effort that is the WinUI. |
|
@MarkIngramUK Yesssss Make WinUI the best UI choice for anyone considering native Windows development. Finish:
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:
|
@weitzhandler you are totally right! I believe their architecture will lend themselves to one day have complete parity with the WinUI control set, which may not be possible with Xamarin.Forms. If I understand correctly, that control set just hasn't been built out yet, which is what @lukasf and I were referring to. I could be wrong though, I haven't played around enough to know, I'm just trusting what I've heard from everyone else :) |
|
@weitzhandler Uno's approach of re-implementing the real UWP/WinUI APIs is much better than Xamarin's inventing of a new XAML dialect. But if you run the Uno Xaml Controls Gallery, you will find quite some areas empty. Their control set is sure better than Xamarin.Forms, but it is not nearly a complete UWP/WinUI yet. I think Uno needs more work on the API surface, and also more work on getting the available controls really stable and full featured. I could see Uno as a vialble option. But it needs some real progress, which is where Microsoft could come into play. |
|
In a different point, I completely agree to what @lukasf said here:
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. |
|
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 controlsIt will need to define a View class and layout infrastrcture, but specific views or groups of views can be added by installing standard .Net UI packages from nuget. (This post is a comment on cross-platform .Net UI and is therefore unrelated to WinUI.) |
|
I have a feel that the WinUI team's current priority is not for "new native Windows applications". Instead they are focusing more on modernizing existing apps, and making WinUI the underlying support of some higher-level UI framework... |
Coming from a person who works at Microsoft that is kind of weird. |
@weitzhandler |
|
You were talking about what the WinUI team thinks. As general MS, unfortunately that actually does makes sense. |
|
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). |
This is not true. I gave two ways in which controls can work in multiple frameworks. The first approach is writing platform-specific code. Then you need to know the frameworks you support to hook up your platform-specific code to each framework; you can do this right now but the scaffolding can be made easier in future. The second approach (platform-independent rendering) is very easy and is being done right now. E.g. CSharpMath.SkiaSharp can be used across all .Net UI platforms. |
|
@charlesroddie Okay maybe I got your post wrong. But then the control is not really independend of the framework. It can only be installed in those apps whose framework is explicitly supported by the control. And rendering is only a small part of a control. Control logic, data binding and input handling must be implemented for every single supported framework, in every such control, even if you use a platform independend renderer. That does not sound very effective to me, unless the supported frameworks are very similar. As I stated, it is possible to share some code between WPF, Silverlight and UWP. But beyond that it gets really difficult, and I doubt that I will ever see such a control. A cross-platform framework usually allows you to write all the control logic, data and input handling (and sometimes even the rendering) only once for one API, and then it will automatically map that to each framework. So once the framework is there, control implementation is much more efficient. |
That's true but supporting more platforms is/can be made easy.
Data-binding does not need to be implemented by a UI framework. This is a misconception fostered by prevailing popular but inferior .Net approaches. Controls only need to specify constructors and properties. They do not need to specify any particular way to bind data because once gettable/settable properties are specified consumers can use any approach framework to move data that they want. (And almost any approach/framework is better than WPF/UWP/Xamarin data-binding.) Control logic is naturally implemented in .Net in a platform-independent way, so that is perfectly catered for in either approach I gave. Input handling does benefit from a "cross-platform framework", but this can be a very small control framework, which can be referenced in both platform-specific and cross-platform projects, with a very small API that just defines mouse/touch and keyboard input. The SkiaSharp.Extended controls project is moving in this direction. |
|
If you want data binding to work in WPF or WinUI, then you have to declare DependencyProperties. I strongly doubt that anyone would use a XAML control that does not work with data binding. Data binding is at the very hear of these frameworks, and it requires DependencyProperties to work, if you like them or not. If you don't add them, you cannot use your control in any of the current Windows platform frameworks. With "control logic" I ment more the interaction with other controls, like defining or creating sub-controls for your top-level control, data and status handling between these controls, layout, synchronization with sub-controls. This is all framework specific work. That combined with data binding code (if required by the target framework) and input handling probably makes up >90% of control code. The common part between different framework implementations for one such control is probably so small, it just does not make sense to me to work that way. I don't say that it cannot be done. But it will be very complicated, since frameworks are so very different. I mean, it is possible to write such a control right now, still I have never seen one. And personally I don't believe that this will become an even slightly popular approach. |
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.)
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. |
@robloo I will have a party to celebrate it when this happens.
@verelpode
As for #1, I have heard Nventive is growing out their current building and moving to a larger facility, so the expanded Uno Conf 2020 (2-day to 3-day) will have a part held in a different building. I am not an economist, so I cannot predict whether there will be a severe recession driving many companies out of business. At least I do not see an economic meltdown in near future right now (the unemployment rate in our area has been below 2% for a while). As for #2, I rarely see the type of passion that the primary Uno guys have for their project. It is almost like a noble cause, not a mere software product for them. Well, only a fool does not change his mind, so I would not say the probability of their losing interest is zero, but probably not far from zero. To be honest with you, this is the main reason for me to enjoy and stick to Uno right now. Just like any other platform, Uno has many issues (BTW, missing some nice-to-have features is no issue for me.), but they address critical issues rapidly. I think they have half a dozen or more releases every day. One of my apps could not be published due to a known bug of a platform, and it literally took more than half a year for a major company (😉) to fix it (I have archived the ticket). Based on my extensive experience with Sliverlight, Windows Phone 7/7.1/8/8.1 SDKs, Windows 8/8.1/10 (WinRT, UWP…) (My primary phone was a Windows Phone, the best mobile platform in human history, until the last minute before I had no choice but switching to an Android one this year), I have more confidence on the longevity of Uno Platform than similar things from Microsoft. Yes, Uno is based on all Microsoft technologies, but they take care of migration when Microsoft changes things under the hood. I have been wondering whether a reason that Miguel endorses Uno and delivered the keynote at Uno Conf is that he sees Uno like his baby Mono in early days, and Nventive like his Ximian. I do prepare for the worst scenario – decease of Uno. Since all of Uno projects use my two favorite technologies – C# and Xaml, I can migrate them to any emerging platform based on them easily. At least I can say that C# code ages really well. Much of the code in my core utility library shared by all projects is well over a decade old. They still work perfectly, and I suspect they will in the coming decades. |
|
@stevenbrix @weitzhandler @Pinox An interesting discussion, also noticed Blazor Native being mentioned here as well. There's been a new NDC conf from Steve with Blazor that might be interesting to consider, the video above using Blazor + Native used Flutter as a renderer. But in a new NDC Conf video Steve now uses
|
|
UPDATE: Thank you to the Microsoft staff members who worked on this improvement. 😄 |
|
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). Microsoft: Can power off one ram of 8/32gb of those who had 4x 8gb/ 4x 32gb...Saving a lot of energy. To do this, we get rid dozen of app that develop with Electron...that depend on Microsoft and Bill Gates's goal. Although best goal is to everyone start develop app and gain traction from some CSS3 standard GUI Framework...possible like QT/GTK... but too bad GTK is not non copyleft, and possible like QML with .net equivalence. |
|
UPDATE: The bugginess of MS Teams is unsurprising when you consider that it is written in JavaScript. Of course an app written in JavaScript is buggy -- why would anyone expect otherwise? MS Teams uses ElectronJS which uses JavaScript despite the fact that it's well-known that JavaScript was never intended to be a real programming language, rather it's just a casual scripting add-on for web browsers. JavaScript doesn't even include compile-time type checking -- that's how bad it is. Hence the need for TypeScript to try to correct this major problem in JavaScript. Actually, it's a very bad problem if you think of JavaScript as a programming language -- JavaScript is terrible as a programming language -- but as I said, it was intended to be a casual scripting language, not a programming language, therefore you can forgive JavaScript for failing to include the essentials of a programming language, because programming apps was not the purpose of JavaScript. What's not really forgiveable is the incomprehensible decision to use a casual scripting language as if it's a programming language. I was really surprised to see that Microsoft chose a non-professional language for an app as important as Teams. I didn't think it was possible for anyone to say the name "JavaScript" while simultaneously forgetting that "JavaScript" has "Script" in its name because it is indeed a scripting language not a programming language. Somehow the existence of the word "Script" in "JavaScript" has just been completely blended out. The WinUI team members have been working hard on many improvements to WinUI. Microsoft's decision to use a casual scripting language instead of WinUI makes no sense. |
|
There are a lot of very well written, high performance JavaScript web applications. Sure you could get even better performance with other technologies. But the reason why Teams is slow for you is surely not the fact that it is based on JavaScript. That is caused by some bad implementation on either server side or client side (probably async/threading issues). It would surely be possible to write Teams in JavaScript with a lot better performance. Don't get me wrong, I am not a JavaScript fan at all. In fact I think it is a horrible language. Just saying that the problems you see are not caused by the fact that Teams uses JavaScript technology. It is even possible to run the Unreal engine in JavaScript with good (not top notch) performance. WinUI is a Windows desktop framework only. So it was not possible to develop the x-platform Teams application based on it, and even today it is not possible. But maybe the problems with Teams will help Microsoft to consider making WinUI cross-platform. With a true x-platform WinUI and .NET Core it would be a lot easier to develop responsive apps that scale well. |
Using Uno, WinUI is cross platform. Look at the UNO Calculator in the Google Play store. It is a ported version of the Windows 10 calculator. |
|
Someone was asking for UWP vs Electron comparison, here there are a couple: https://twitter.com/emiliano84/status/1198177284533956608 https://twitter.com/emiliano84/status/1198179206548602881 the new XBOX app it's ridiculous, can take easily 1.5gb of RAM for nothing would be nice if someone can make a video to show how slower they're compared to UWP |
|
I thought most participants of this discussion regarding WinUI & X-platform have read about this story, but just in case some have missed it, here is WinUI on Windows 7 – Yes, it’s possible with Uno Platform. Once an app is based on Uno, it targets Windows, Web, iOS, and Android. |
Yes it is possible, and it is also possible to write MS Teams in PowerShell with acceptable performance (I like PowerShell), and it's also possible for SpaceX to relocate to Russia and still manage to launch satellites, but it would still be an incompetent management decision to relocate SpaceX to Russia, or to write the MS Teams app in a scripting language such as PowerShell or JavaScript. If SpaceX moved to Russia, then yes SpaceX could still operate, it's possible, but honestly we would have to say that Elon Musk wouldn't really be an effective manager and wouldn't really know what he was doing. |
|
I am not 100% convinced that Electron is the to blame. Visual Studio Code is said to be based on the Electron, too, but its performance is pretty solid. Electron apps are basically web apps, and there are thousands of reasons behind a badly performed web app. |
|
There isn't much WinUI can do to "win Teams over". It's not the tech, it's the product. Teams is like a startup company that's set itself up on a path of rapid growth. It needs to run on multiple platforms with feature parity, and they need to achieve this as quickly as possible. This is the only reason to choose web-based technology. On mobile they can use React Native because it's the only way to tap into hardware with JavaScript, but on Desktop, they need to maintain feature parity and code maintainability with the web app, the mac, and the Linux version. They have to use a framework that targets win32 because they can't wait around for UWP app model to add features it needs. Being able to do share desktop with the option to choose which desktop or which specific app to share is one of its key features. This is just how startup-like products are developed. Slack used jquery to hack growth when they first started and ended up with really bad code, but once they have had some time to refactor, they quickly rewrote everything with react, and Slack is now much faster than before. WinUI and Electron are not in the same category, and for that reason it will not replace Electron for the apps that really needs it no matter what feature it adds. |
|
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. |
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
The text was updated successfully, but these errors were encountered: