I suggest you ...

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)
4) Droid
5) iOS
6) Macintosh
7) HTML5
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)
2) HTML5-Compliant - For web-hosted scenarios, via .NET-to-JavaScript transpilation
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!

10,704 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Developers Win! shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • disillusioned developer commented  ·   ·  Flag as inappropriate

        'Under review since February 23, 2016' ... *sigh*

        Sadly symptomatic for the new Microsoft that seems determined to abandon all of its 'legacy developers' for some new cool. It's very revealing to regularly visit Microsoft's own .NET Blog. Based on the number of comments there's low to zero excitement about their .NET Core initiative which seems to get 99.9% of all internal development ressources, while everything remotely WPF-related easily draws 100+ comments. Don't get me wrong, I like .NET Core, although I doubt it will have an impact on the thriving node.js-stack, since MS is - as always - late to the game and fails to offer the 'one language on client and server'-approach. But throwing the whole 'classic' developer base under the bus by leaving them with a 12 year old windows-only UI-Framework WPF that never got any substantial updates for years and by ignoring the plea for a cross platform client application framework is massively frustrating (Yes, I'm ignoring UWP, just like everybody else). Are we really supposed to turn to abominations like electron because Microsoft stopped caring? Where are the alternatives? The 'It's purely experimental and will probably get dumped anyway so don't use it'-Blazor project?

        Thanks a bunch for all your efforts, Mike-EEE. But I doubt there will be any positive reaction from Microsoft. Time to move on.

      • Marc Roussel commented  ·   ·  Flag as inappropriate

        If Elon Musk can send a car in space, Microsoft can send a cow to Mars and back I'm pretty sure of that.

      • Anonymous commented  ·   ·  Flag as inappropriate

        That is an extremely unrealistic suggestion. The .NET Run-Time is specifically designed to work with the Windows API... and has been in-development for over 15 years! Expecting Microsoft to be able to make it "ubiquitous" like suggested is like asking a scientist to make a cow fly to Mars and back.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Yeah @Scott it's great to see the experimentation/exploration. I for one am very appreciative to see MSFT take the efforts to try out and see things. You see this with GOOG and AMZN especially. It's good to see MSFT in that fold now and I really hope they continue.

        The two issues with Razor's approach is that it is tied to HTML5 in a way that is not very elegant when composed with .NET IMO. It is basically a hybrid templating system between .NET and HTML5. So you have some symbols (.NET) that are PascalCase and then others (HTML5) that are all lowercase. Aesthetically, this disruptive to read and parse from a human-readable perspective. Or at least the one that is typing the words that you are now reading LOL!

        The other issue is that now you have WebAssembly Blazor which requires a significant download and then there's another for desktop. Will they each be able to use the same codebase and will it work on iOS/Droid?

        For a little bit where my head has been at lately, I encourage everyone to check out Hugo:

        I have been truly blown away by how simple and elegant its approach is to website design. Totally nothing to do (or compatible) with .NET but really worth a look into how they go about building (or rather "compiling") web sites.

      • mgbrown commented  ·   ·  Flag as inappropriate

        My general opinion of Java apps which tried this is that they are all terrible. The more platforms you support the more compromised your app becomes.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        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.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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

      • Marc Roussel commented  ·   ·  Flag as inappropriate

        @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.

      • Anoonee commented  ·   ·  Flag as inappropriate

        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.

      • shimmy commented  ·   ·  Flag as inappropriate

        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.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @birbilis I am not sure if you were asking me specifically, but in my world *any* non-.NET language is the threat here, not just JavaScript. That is the power and elegance of .NET, with its initial vision that of supporting numerous languages and (in theory) being able to add more in the future to continue staying relevant and competitive. In doing so, companies and individuals are able to leverage previous and existing investments and continue forward onto new projects with these same investments to reduce costs incurred otherwise by developing or incorporating in an all new, incompatible language altogether.

        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

      • birbilis commented  ·   ·  Flag as inappropriate

        why do you assume the Javascript path means just Javascript? Unless they use node.js, they have Java or .NET, or PHP, Python etc. on the server. With WebForms you didn't have to mess with the Javascript, you'd see it as blackbox controls that could also do stuff client-side when AJAX enabled.

        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.)

      ← Previous 1 3 4 5 24 25

      Feedback and Knowledge Base