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!
Jack Bond commented
Hey Microsoft. It's been three days since your last poll. Quick, do another, maybe this time the top request won't be exactly the same as the last 100 polls.
Whoop Dee Doo. You can now run WPF on top of .netcore, but only on Windows.
The level of incompetence is staggering.
Lots of mention of "ubiquitous" in //build currently, but meaning all the wrong things. ;)
WebAssembly + Xaml is here:
Paul Sinclair commented
A QT like GUI/Form designer for C# please... that can just work on all platforms.
MS used to provide good tooling for windows that all went down hill after windows 8.. time to get back to good tooling no?
With .net core stuff and multi platform support and proper tooling for GUI layouts they could surely do alot better than half dozen JS libraries built on poor foundations.
I agree GUI for rapid development is needed for web (blazor) and mobile (xamarin.forms), it has been asked thousend of times in xamarin.forms forums. A GUI is why visual basic/winforms/etc were so succesful years ago because any one could create UI so easy and fast, if you had to create windows UI using code, MFC, etc it would not have been succesful.
Coding UI is so boring and slow and is not where innovation for business is. MS has always provided great tooling for UI (vb,winforms,wpf, silverlight,etc) not sure why they are not doing nowdays for web and mobile and they want us to go back 20 years ago to code everything.
If they could provide great GUI tooling for web/mobile it would be a big differentiation from other techonologies like angular, react, etc and lot of people would move to use it as learning curve is so much faster.
@Marc 100% agree... there was actually a discussion around this lately on Xamarin's forums. Well it actually started on Twitter and had to do with Xaml Standard, but was never on Xaml Standard's repo... GO FIGURE. Anyways, there is actually a movement to make code more UI-ish, and I'll just skip to the good part where I put in my $.02. ;)
Any GUI to develop ? Because having a button this way is hard to know where it is.
// Create the UI
var button = new Button("Click me!");
This makes me laugh a little. Imagine I have a very complex form to build. I don't think I see myself building a UI that way.
Markus Schaber commented
A good base for this could be Xamarin.Forms, which already supports the mobile platforms, and work is in progress to support the desktop platforms.
For the web, see https://github.com/praeclarum/Ooui for one possible way to implement...
@Anonymous LOL - Microsoft isn't going to bring about some white horse frontend technology that everyone will use
Why not ?
“You cannot escape the responsibility of tomorrow by evading it today.” ~ Abraham Lincoln
LOL @Marc ... negative but funny AF. ;)
Also, @Anonymous 100% agree. Don't forget this issue has been "under review" for over 2 full years now. Without any remark whatsoever from admins. Pretty impressive. I still think someone got drunk one day and accidentally hit the wrong button. Either that or they are no longer working for MSFT. Maybe both. :P
@FilipiVC Welcome to the unubiquitous world of finding the right solution in a time frame for which the technology is changing rapidly. In a nutshell, right now it's called MVC and a ton of frameworks with a not so powerful foundation.
We still have to wait.....Waiting since a long time now....Meanwhile it's a pain in the...Blazor ? Hmmm not so sure. No GUI to develop UI UX We are still again at the age of the Autocad LISP
A negative post sorry...
my biggest question is about web development and how to make client side interaction easy to develop and with a good look and feel like desktop softwares without tons of frameworks and code.
The fact MSFT is setting up poll after poll instead of just tackling the 10 most voted UserVoice items tells a lot: They hate the answers they get. Stupid as we are, we keep refusing the rewrite all our UI in JS/CSS/"JS generator of the day" and keep asking to fix the mess they created with 3 (!) incompatible XAML dialects. Silly-us.
FWIW, this idea has now surpassed 9,000 votes, and is by far the most popular idea here on Visual Studio's feedback forum. FWIWx2: There's a survey going on with the .NET group on what they should do next. Feel free to chime in and give them a pointer back here. ;)
@Антон, the problem with Bridge.net is that it does not support .NET Standard 2.0 or PCLs, so you ultimately end up with 2 separate codebases that results in twice the total cost of ownership to develop and maintain. Right now the only viable choices or approaches for a ubiquitous .NET are Blazor (as you mentioned) and Ooui:
Антон Кононов commented
For HTML5 experience we can use https://bridge.net/
Here Microsoft can add .NET Standard 1.1+ compatibility and provide with better tooling and WPF support (as opposed to Blazor with WASM this thing is really works NOW).
Blazor is shaping up: