Create a Ubiquitous .NET Client Application Development Model
This suggestion is migrated to Developer Community. Please use below link to view the current status.
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!
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:
With this @Microsoft reorganization, with @Azure Cloud First, AI first and Quantum, I think that they will allow XAML to go where previous politics did not alow, ie. the Web. and cross-platform. Silverlight 6, with Universal XAML C# F# support.
For those who have voiced their displeasure with Xamarin Forms, there's a nice thread on their very own repo with developers talking about its shortsighted issues and other well-deserved criticisms. It is also talking about ubiquitous technology in general. Nice read, IMO... that's why I am sharing it! ;)
Got my vote!
For people using Telerik/Kendo can you vote and show interest to see good WASM UI components from them?
@Oliver ... i have had problems before with certain words triggering a block. No warning/indication/nothing. This was on Visual Studio's blog and not .NET's, however. Try doing a simple post and seeing if it works, with a message saying that you are having trouble as described.
Oliver Shaw commented
Keep trying to post a comment on the calling all desktop developers, but nothing appears to show. Any one else had this problem?
Amit Gupta commented
FWIW/FYI nice conversation going on in the comments of this post if you want to contribute/complain somehow. ;)
...and if he means for Canvas support (for rendering), there are some fallbacks for it too (using Flash etc.). Not sure if one uses WebGL for rendering if there are any decent fallbacks
Not sure why he says "Con: Relies on fancy new support in modern browsers. Fortunately support is ubiquitous today, but this won’t be working on Windows XP." at http://praeclarum.org/ - Isn't there available an (automatic?) asm.js fallback for WebAssembly?
Michael DePouw commented
The amazing @praeclarumhas did it again! Xamarin.Forms running on the Web using WebAssembly! Check out this online sample: s3.amazonaws.com/praeclarum.org… Try it yourself here github.com/praeclarum/Oou…
cs mr commented
The important aspect of native apps for me is efficient compilation to native code. Bytecode is OK, AOT even better. Of course what matters is the end result: memory usage and performance.
Hah, well "better" is relative, and of course every application is different and tailored towards its intended market. Certainly native hosting environments offer "better" :) integration with device components and hardware accessibility. But also consider that HTML5 is slowly gaining more and more access to these features as well.
> Webapps are a cross-platform technology, that make it easy to reach many platforms, albeit with a low-quality solution.
Consider that the only difference between a "webapp" and a "nativeapp" is the hosting environment. That's it. You can technically run an HTML5 "webapp" in a nativeapp via Cordova and a suite of other technologies. A "webapp" is simply an application that is hosted in a web browser host process. It is not a website, although those have historically existed, and are probably contributing to your conflation with the two notions (and that of "low-quality"). If you have not taken a look at WordPress's editor lately, try checking it out and see if you continue to have the same notion of a "webapp" being of low-quality. From what I have seen, it is just about as good as any WPF application I have seen, and then some, especially when you consider it can be rendered on any modern browser (and therefore device).
> But if we can reach those platforms natively, why would we want a webapp?
Or conversely, if you have one application that runs within a hosted web browser context (i.e. everywhere), why would you want nativeapps? :)
Along such lines, consider the sheer amount of resources required to get .NET to run and emulate a Droid/iOS environment. Or even UWP. You will spend a day in Visual Studio installing all the required (100s of GBs!) software to simply launch an emulator (or UWP scene) from your installation, assuming you do not run into obscure platform-based hiccups. Whereas with web, a simple visit to a URL is all it takes, no special installs required, outside of the web browser you run it on (preinstalled on all devices these days) and the web server that serves the content, of course.
And, of course, this runs through the whole "web" experience. Users don't need to go to a store or perform any installation or permissions checks to run a web application. They simply visit a url/location and it "just works" without having any proprietary magic or store voodoo. In fact, if you have a web application and force the user to further install a "native" app, you risk losing that user altogether as you already have them right there. In your web application. :)
The web is simply much more lightweight and as it incorporates more and more native-esque features and functionality, it will become the defacto platform to develop and deliver upon as such. That's not to say that it will replace native applications (although it might), but it should certainly be considered as a peer platform to the current 3 platforms that we find ourselves with in the current landscape.