Calling all .NET desktop and mobile developers!
We would love to hear about your experience with building client applications in .NET. Your feedback will greatly help us to improve the .NET tooling and ensure our roadmap focuses on your needs. Participate in shaping the future of the .NET client development by taking this short survey (5 minutes to complete).
We are also searching for developers to discuss new concepts and prototypes, so tell us in the survey if you would like .NET engineering team to reach out to you about upcoming opportunities in .NET UI development.
We really appreciate your input and will build our decision on the feedback we hear from you.
Light
Dark
29 comments
More VB.NET Based support (Everything is C#, its keeping Telerik’s Online Code Converter very busy…), Better Media Controls for WinForms (XAML Islands is a great start), Native Security Interaction Controls (Windows Hello etc…), Better WinForms DPI Calculation for Labels etc, Code obfucastion as a native VS feature, Eaiser Socket communication for client/server based apps, Native REST/WebSocket API Controls + Documentation for WinForms & VB.NET (relying on thirdparty nuget packages and wrapper classes from the community isnt ideal). Thanks!
this:
https://github.com/microsoft/xaml-standard
Cross-platform XAML/WPF makes absolutely no sense – and thus why Microsoft has been avoiding this for years.
Although the first inclination of any developer is always to ‘write once, run everywhere’, this strategy from a practical perspective has never panned out. We live in an age of native everywhere, meaning a native Mac/Windows app, a native web app, native mobile/tablet apps. A write-once, run-everywhere, ‘cross-platform XAML’ would be a lowest common denominator attempt that would produce a poor experience everywhere and against what our users inately demand/expect.
The valuable option without being native already exists with bringing web/HTML to a native desktop app (ie: Electron), which makes sense and carries business value because web apps are most often already designed for the desktop form-factor and often have no OS-specific UI widgets that they usually integrate into – ie: they use their platform-agnostic design language through the use of any number of UI frameworks (Bootstrap, Material etc.). This is not ideal from a user/product perspective, but so many websites already exist that business value-wise it’s an acceptable compromise (see Postman / Slack as examples of great implementations of this approach).
In terms of achieving true NATIVE cross-platform UI framework, the first FEASIBLE attempts at creating such a platform are Flutter and SwiftUI, which are both a paradigm shift away from any other previous framework (ie: WPF (Windows), Cocoa/CocoaTouch (iOS), Android) – and both of them required re-imagining/building from the ground up from language through to framework to enable such possibilities (read here for a glimpse of why this needs ground-up to achieve: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf)
The only VIABLE contribution from Microsoft in this space would be to build native widget/UI-kit implementations for Flutter (right now) and wait on SwiftUI to open-source and do the same for it (hopefully within a year).
These things tend to be very winner-takes-all, and even the battle between Flutter and SwiftUI may eventually end up with a single winning platform. Trying to achieve what the entire Web ecosystem and Apple/Google have in the consumer UI space is completely futile, and Microsoft DNA-wise as a company stands no chance at achieving such a thing (lack both design prowess and consumer adoption).
Plus, XML/C# are both structurally outdated and have no chance competing with either the modernity of Swift (and yet-to-be-seen Dart), or the adoption/scale of Web. Smart folks at Microsoft know better than to attempt this guaranteed failure, and anyone who has been deep enough into the world of UI/consumer platforms undestands this very well.
So hold your horses for another year or so, and then pick between Electron/web, SwiftUI and Flutter (with hopefully SwiftUI as the winner if Apple decides to open-source and third parties can start implementing OS/web implementations such as Flutter has been already doing).
#skatetowherethepuckwillbe
You basically said that “write once run everywhere” is a waste of time and then go into endorsing Flutter which is exactly that.
Also, HTML5/JS is “write once run everywhere” and has panned out pretty well.
Finally, you laughably state that cross-platform XAML makes no sense, when Uno does a good job refuting your drab and uninspiring cantitude.
Are you sure you’re in the right place?
The Xamarin.Forms startup is slow.
If .net core supports desktop programming on other platforms like .net framework on Windows, that will make it the best tool in the world
We need a cross-platform desktop solution with community support and upgrades for a long time. Whether it is wpf or uwp
WPF/Xaml is good enough, stop make new wheel.We need a “Flutter” for DotNet.
“Don’t invent a new wheel but make Flutter.NET which would be a new wheel.” 😉 We’re talking about Flutter here, FWIW: https://developercommunity.visualstudio.com/idea/351412/create-a-ubiquitous-net-client-application-develop.html
Cross-platform!!!
Add your voice and upvote here, if you please: https://developercommunity.visualstudio.com/idea/351412/create-a-ubiquitous-net-client-application-develop.html
Cross-platform winform/wpf to match .NET Core, please! !
I hope that WPF can cross-platform, because we urgently need it, thank you for your contribution, and look forward to seeing the birth of a powerful cross-platform framework.