Create a Ubiquitous .NET Client Application Development Model
This vote is for developers who wish to see the idea of a ubiquitous .NET client application development model created by Microsoft and the Visual Studio team.
A ubiquitous .NET client application development model is a model that is defined in .NET-based technologies and is able to run in a multitude of runtime environments -- both native-compiled (store-hosted) and web-hosted.
A *very* rough image of the vision can be found here:
The goal is to enable *one* .NET Client Application Project to build deliverables for the following platforms:
1) Windows 10
2) Legacy Windows
3) *nix (Unix/Linux)
8) ??? (Extendible to different, future platforms)
In order to achieve the above, a ubiquitous .NET client application development model should strive to possess the following qualities:
1) Native Cross-Platform Capable - For native-compiled/store-hosted scenarios (iOS/Droid/Windows Store)
3) Consistent User Experience - For brand recognition, reinforcement, and optimal usability across all known scenarios
4) Cross-Boundary Accessibility - For shared code/assemblies between server and client boundaries
5) Xaml-Powered - Harnessing one of the greatest inventions in Microsoft's great history
6) Object Serialization Congruence - Markup used to describe serialized objects is what is created in memory
7) Holistic Development Consistency - The same guidelines and conventions are used in both client and server scenarios
For more information around this idea and the qualities above, a series of articles has been created to discuss the notion of a ubiquitous .NET client application development model at length. You can view that series here:
Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!
OK I did a little digging and I think the Xamarin is a misstatement there. It's a React Native application that still uses UWP APIs via the dreaded WinJS API covariant. What's been ditched is the XAML API which is what a great majority of UWP resources (and brand) has been dedicated to since Silverlight was sunset in 2011. Do recall that XAML is the format that allows efficient tooling to streamline workflow processes, particularly between designer and developer. There have been countless hours, developers, and additional resources around this UWP Xaml and it has now been resoundly given a vote of no confidence by another group within MSFT. Other groups will surely follow.
Indeed Michael (hey, nice name!), it still uses "UWP" for application hosting on the Windows Store, but the "guts" of the application is no longer the traditional Xaml/APIs of the UWP offering.
The same happens when you use Avalonia (as an example) for your Windows Store deployment. Technically, it's still "UWP" as UWP is the only compatible API that can technically deploy to the Windows Store.
Michael DePouw commented
Interesting comments on that article...
"This article is misleading. This is more about the abandonment of XAML (and Xamarin), not UWP.
The Skype version using react-native has been in development for quite some time and it is a UWP app. " Joe Wood
UWP? More like RIP. OH I SLAY ME!
Interesting project that made a mention recently:
Seems very old skool, though. I am not a big fan of the magic handlers and such, but I understand why someone would be.
Hahaha... with all the GDPRmageddon, I got a nice reminder of the first draft of this ****** back in 2011:
Ohhhh memories. <3
Looks like we can add 35 more votes to this issue. ;)
@Anoonee I think some people working at Microsoft are anonymously writing here. Maybe there's nothing they can do. It's about hierarchy
Some people are taking decisions which affect the future of the developers as we know it.
Wood head Microsoft, a big chance to change the world, but wasted (till now).
Single code base with cross platform application development can overthrow the whole software development world, MS has the power and resource to do this, but they don't.
I was told that people in Microsoft are very smart guys, but their performance shames me.
And, Delphi for WebAssembly:
QT for webassembly:
Why cant we have Winforms and WPF for webassembly? )
Ah but it does @shimmy ... read #3 above, which is further explained here:
The problem with the idea is that it doesn't say that it should render everywhere the same. Xamarin.Forms does this, but you need to touch up each platform separately. Additionally, you would need a custom render for each platform for every control you'd want to create, and there are some essential ones missing, for example RadioButton and CheckBox.
That's how it is supposed to work, at least. And, actually, does work exactly as envisioned everywhere except for this little problem of the UI tier. :P
So could have say WebForms (personally like it better than MVC for focusing on your business logic) + Blazor for example and allow one to build webcomponents (which is trending in recent years) in C# or choose to use readymade customizable componens from MS and third-parties. And I'd really like to see PME (Property-Method-Event) for customization, apart from CSS styling
in fact Blazor could be a renderer for some higher XAML layer that could also have other renderers for targets where you don't have html engine or don't want to carry the HTML baggage (e.g. could be embedded stuff, games, TV stuff, high-perf desktop apps, holographic stuff etc.)
Wow @Marc... that IS a good video. All until the end when it talks about async, though. What a stain on our language:
Adding a System.IAsyncDisposable -- not to be confused with IDisposableAsync ;) -- is a perfect example. It is basically creating two different sets of APIs throughout our entire framework. The async zombie virus spreads! DON'T FORGET TO DOUBLE TAP!!!
Hehe... @Marc thanks Brogrammer... I appreciate that! You got me as I was fixing a major edit/flaw in the previous post, DOH. Do know that I have been pawing at this problem for many years now, and I have not been able to articulate it as well until very recently, I would say in the past year or so. IMO the Silverlight 6 vote didn't survive because it wasn't a very business-oriented case, IMO:
This vote is that EXACT same vote but with a more business-oriented objective and angle. In the end, MSFT is a business (I always use its stock ticker in place of its name for this very reason), and so it is most effective to frame complaints and issues is as a BUSINESS problem and highlight where VALUE is taken and where it can be restored.
I laugh all the time...
@Mike-EEE You have the words to express exactly the need. Thank you and happy 10,032
@Collin, what do you base the statement that Xamarin has this covered and works quite well? It is the second most dreaded framework in stackoverflow's most recent poll:
I also pair this with the comments of this thread, over 450 of them to date, LOL. Xamarin.Forms is not very praised that I have seen.
Also, in regards to desktop/mobile designs. The vision/ask/idea here is to provide a more WPF-esque model where you can easily apply a theme and it would match up with the platform that is serving as the host. Given such a paradigm, you could imagine using it to apply a theme to run on an iOS host that provides the Droid UX and vice versa. The point being that great UX is great UX and is not meant to be bound by, well, boundaries. :) Also consider that what you consider as an "iOS" experience and a "Droid" experience is approaching a decade in age and could use a refresh. Also ALSO consider that no one really complains about how web UX operates and it is growing more sophisticated (native-like) by the year.