Closed IrakliLomidze closed 1 year ago
WinUI is not a new UI Framework; it's the evolution of an existing UI framework called UWP XAML. UWP XAML is a high-performance framework used by the Windows 10 OS. The simple fact of being built over a WebAssembly layer will impact on the performance dramatically. Perhaps that meets the requirements of a big set of customers and scenarios, but it won't meet the needs of the most demanding ones such as Windows 10 OS or apps that require a fast render and lower consumption of battery and memory. And this is unique of WinUI versus other frameworks of the same target audience.
If you want to use WebAssembly with WinUI, I recommend to you use UNO. UNO and the WinUI teams have a great relationship, and UNO is implementing the WinUI runtime on the top of WebAssembly. As you see, even with WinUI, you have a lot of options: UWP, Desktop, WebAssembly, etc.
WinUI has a great adoption rate in our previews bits, and the customers' feedback indicates that we are on the right path for delivering a product that will help a lot of customers.
Hope this helps.
Marb2000
Is Microsoft going to use new WinUI 3 in its own desktop products, such Office, Visual Studio? (do no refer calculator or notepad : ) ) In past few years Microsoft advertising FluentUI concept in the desktop app, that expected to came in Office but not happened.
So the question, in general, should it worth investing in desktop development at all. I understand that native code will be always faster, but in modern application development, you may always think web-based. And good example is a web assembly based Autocad.
I would take a native app over a web-based one any day, so I hope MS is going to widely adopt WinUI3 for lots of apps, this will also promote the framework among developers and send a good message, that MS is committed to this framework
WinUI 3 is a customer focus product. It means that we add capabilities to the platform based on customer feedback and requirements. WinUI 3 is being developed with a set of internal and external customers that drive our initial set of requirements. We are fortunate to have the support and sponsor of all these customers. 😊
As you understand, we can't share customers' names (even internal names) without permission, and product owners are very reluctant to share that information until they launch the product. Furthermore, customers do not want to share what technology they use because the important thing is the product, not the technology used. Also, WinUI 3 is still in development, so there won't be products that advertise that they use our technology until we have a release version with technical support or similar.
About your perception of "in modern application development, you may always think web-based," I disagree. IMO it would help if you put on the table the business goals of your product, why and what do you want to build it, and then think in how. If you are biased to go always with web-based first, I bet you will always find justification to use web technologies, although it wouldn't be the best solution. Although I love this topic, I don't think this is the right forum to discuss it.
Going back to your point of how WinUI 3 fits in a web-based approach, we are working with the "React Native for Windows" team for being adopted instead of WinUI 2. SO you will be able to use your web skills to create cross-platform apps.
I think frameworks like React Native will eventually make use of the WinUI/Xaml framework for handling the UI.
@IrakliLomidze as the owner of a company that (so far) only develops desktop applications for enterprise customers, I can attest to the fact that the demand for non-web native applications is definitely there. Unfortunately, I would debate that entirely too much emphasis has been placed on Web technologies and or other sandboxed frameworks such as UWP, over the last 8 years.
As @marb2000 pointed out, part of the demand is due to the performance requirements that cannot be achieved through any of the popular SPA frameworks let alone Microsoft's very own Blazor. I mean not to take away from the greatness that all of these options offer, but rather point out that desktop applications should be thought of as a tool where the need is ever present and the demand just as high. In addition to performance requirements, desktop applications typically need the freedom to perform a lot of operations that are difficult or impossible in a browser based environment. Operations that would be risky to allow in a browser.
Also consider the amount of existing Windows based applications that have a high customer demand that would be rather expensive to re-write using a SPA framework. I am going to name one example, however I want to make it perfectly clear that I have no specific knowledge of, nor do I personally represent anything owned by the company Intuit. The application that comes to mind is QuickBooks. This accounting program has been in use since the late 1990's which means that they probably use MFC since the .Net Framework did not exist until 2002. I use this application at least once a month and you can easily detect the presence of older Windows technologies like MDI. The codebase of this financial application must be huge; in fact a quick internet query suggests that it is over 10 million lines of code and I definitely believe it. Trying to move that much code into an internet application is probably cost prohibitive.
Also worthy of consideration are government based applications that due to network security restrictions cannot run in a browser.
I would also debate that it is much easier to write a deterministic desktop application than it is to do the same through a most browser based applications because unlike the CLR, the behavior of a browser varies greatly.
I chose to comment on this topic because my company's primary product has been in limbo from 2012 when Microsoft announced UWP. They wanted developers to move over to UWP and I was excited to jump aboard. However, it took about a day to realize that it was too restrictive to port to, not to mention it was missing basic capabilities such as allowing for more than one Window. From that year forward, as each year passed, I hoped and prayed that Microsoft would awaken and give us Desktop developers the capabilities we needed, so we could move over to the faster rendering UWP (compared to WPF and WinForms). To say that I was disappointed through 2019 is an understatement.
I believe it was 2018 when I realized that it was time to consider moving away from Microsoft and finding a UI technology that offered what I needed. Over a 6 month period I evaluated several SPA frameworks including React, Durandal/Aurelia, Vue and Angular. Ultimately I decided that Angular might be the best option to evaluate, though I would have preferred Aurelia had it been more mature at the time. (Today I would definitely pick Blazor!) As much fun as I had learning a new framework, and as much as I wanted it to work, I just couldn't force Angular (or any other web technology) to fit the requirements of my application. I could have made it work for a reporting backend, but that's about it.
Aside from the performance concerns, package management was a real showstopper because it was impossible to determine the licensing requirements for each and every package I used indirectly. Every time I attempted to run that app, it seemed that I was greeted with a lot of security warnings that asked me to upgrade a transitive package, that I could not upgrade due to other packages.
I have not used Blazor yet, but I do have high hopes for it as a "tool in my toolbox". However, they will need to achieve web assembly performance on-par with a native desktop application before I could consider re-designing to overcome some of the other issues such as browser related restrictions that seem to be more restrictive as time passes. (I have a PowerShell script that searches for results in my local github repos. I build an HTML list of the results such that clicking on a link to the file in Chrome, will open the file in VSCode. Starting this year I now have to answer yes to two dialog boxes just to allow the file to open. It was bad enough that I had to answer one, but now two. Sudden security additions like these could cripple a business application.)
I mean only to point out how happy I am that Microsoft is finally focusing some long-overdue attention on Desktop applications. I am trying really hard to make WinUI work as my WPF replacement. I am finding it very difficult in the state it is in today, but happy that I can finally build an app that runs outside the jail-cell that UWP and Web based apps require. I mean none of my rant towards you personally, think of it as pinned up frustration I have had from the lack of Desktop UI options. I hope Microsoft continues to focus attention on Desktop development because the demand will be there for a long time to come.
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.
Do you think that it is too late to introduce a new UI Framework?
In middle therm, Desktop application should go away. Every app in the future will be more or less web-based. As I see the future, mostly desktop app will be converted to the web assembly.
Could you explain why to build another desktop framework for that short of time?
In my case, I have my legacy WinForm/WPF apps, and they need to be upgraded. I need to invest in upgrades.
I like the Windows 10 Moder app UI that, regardless of promises, never come to Microsoft Office.
But the real business point of view is why we need to invest in some intermediate solution that in 2-3 years any way needs to be updated to the Web technology.
Do you think it is better to invest something like the election like Blazor that could be used in a Web app too?
In terms of GUI, WinUI Graphics looks and feels could be rendered in WebAssembly as well.
P.S. Dear WinUI team, Please do not get me wrong; I like jobs you have done and going to do, that is a conceptual discussion.