I suggest you ...

Create a Ubiquitous .NET Client Application Development Model

This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/351412/create-a-ubiquitous-net-client-application-develop.html
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:
http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/Vision.png

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:
http://blog.developers.win/series/bridge-to-dotnet-ubiquity/

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!

11,273 votes
Vote
Sign in
Check!
(thinking…)
Reset
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 →

    499 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Marc Roussel commented  ·   ·  Flag as inappropriate

        Please can we remove JavaScript of the equation ? This is the culprit in all this as well as not having a GUI to develop UI as it was before.
        We are .NET developers that just want a solid GUI call it BlazorEditor, Blend or whatever you want and all we do is coding C# OOP full from server to client which will run on the WEB.

      • Collin Sparks commented  ·   ·  Flag as inappropriate

        I think this approach is ignoring a lot of the problems that have come up when people tried to do this in the past. You just don't want or need UI that is portable from mobile to desktop. In order to do that properly the framework needs to make a lot of assumptions about your design that your UX designers are going to be very unhappy about. Or you can just have a desktop design everywhere that's bad on mobile, or a mobile design on desktop that's bad for desktops. Xamarin already has the mobile side of this covered, and it works quite well. With the addition of Blazor we can now create cross-platform desktop apps that utilize HTML5, javascript, and Razor. I would argue that the approach Microsoft has taken is giving us what we really needed to solve these problems, instead of what some people thought they wanted.

      • Olumide commented  ·   ·  Flag as inappropriate

        By the way, the Web Assembly aspect of my previous comments on Xamarin.Forms is possibly not accurate for Microsoft. Specifically, it should rather be about developers not Microsoft implementing Web Assembly support for Xamarin.Forms/UWP, e.g. Ooui (https://github.com/praeclarum/Ooui) and Uno Platform (platform.uno).

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @Oliver I am OK with Blazor. In fact it's really awesome that MSFT is stepping out and trying new things here. At the end of the day however they are WASM-centric and are not really designed for iOS/Droid/Windows. Additionally Razor has its own parser/engine and is not very Xaml-ish as you know.

        My beef with WASM is that there is a huge download associated with it. If there is a way to streamline this there won't be much of a problem but I am pretty sure it's going to be a struggle for the first couple years for sure.

        As such, I am still very much in favor of Ooui's approach and using a simple, lightweight HTML+CSS presentation tier. The trick here, however, is to adapt it so that you can easily Xamlfy it and make it more .NET-ish.

      • Oliver Shaw commented  ·   ·  Flag as inappropriate

        Is there a reason you chaps don't mention Blazor more? It's .NET CLR in WASM. any thoughts?

      • Marc Roussel commented  ·   ·  Flag as inappropriate

        ...Meanwhile we develop in JavaCrap with tons of frameworks and we don't know for how long we will suffer.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        HEY EVERYBODY... GUESS WHAT NOW HAS TWO+ YEARS IN SERVICE AND OVER TEN THOUSAND VOTES TO ITS NAME???

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        > I guess we do care about Microsoft.

        LOL... yeah, I agree. More like I care about my soon-to-be-approaching 20-year investment into their technology. ;)

        I can't find much fault in what you have to say. WebAssembly is certainly a viable route any tech can take so I see what you say there. I am just not impressed with what I have seen out of XF to really jump in. In addition to their bigger fundamental problems, the way they approach problems and write APIs (e.g. ALL THE STATIC METHODS) leaves much to be desired.

        As such, I think the primary concern in XF and UWP is that neither of these technologies *inspire* developers. WPF and especially Silverlight were LOADED with really great, creative approaches that made developers think differently in how they created their solutions. What's more about Silverlight, is that it was 100% fully comprehensive. It wasn't "just" at the UI tier... it had RIA Services and a ton of supporting cast around the entire vision. In addition to vision, it had purpose, and this fed into developers' minds as they were not only implementing core solutions, but extending and making their own.

        None of that exists in UWP or XF IMO. Now, I will say that I am getting that same creative energy from .NET Core's camp. To me, that is where the talent is at these days but NO UI... this is why I say dump UWP and have .NET Core absorb its mission.

        THEN we can have another HOLISTIC shot at creating a UI-oriented solution. Right now, the UI space is so rickety and pieced together. Hodge podge. There simply is no inspiration in that, and the poor adoption reflects this.

      • Olumide commented  ·   ·  Flag as inappropriate

        @Mike-EEE

        I appreciate your efforts, sir. I will also make effort to involve in the other location you pointed to.

        So, in response to your latest feedbacks. I do think Xamarin.Forms supporting WebAssembly is enough. Rendering to the same usual HTML, CSS & JS, the other obvious option, is not actually a plus, cos it forfeits the essence of the native approach in the first place, even though I support that Xamarin.Forms should support the Web. WebAssembly is just enough to make things complete. A perfect cross-platform solution will not be easy to achieve. OK, what if we had more than Android and iOS to deal with? Wouldn't there be more platforms to target? Of course, yes.

        For UWP, I do think that with the current amount of investment that has gone into it, if Microsoft should try to start over again with something else, it might finally make people forget about Windows development for good. It would likely be a disastrous move for Microsoft. I bet Microsoft will not try that but to simply keep enhancing UWP to become better.

        I have used WPF (few years after it was released and got more stable and accepted) and UWP. Being that I do appreciate UX and UI responsive design, the first thing I instantly noticed about WPF is the flexibility of XAML in achieving a great UI design. But then, I noticed the serious absence of responsive design capabilities. Then came UWP eventually to take care of those areas. Business logic didn't change much. UWP XAML, even though differently intentioned, is still better at doing modern UI design than WPF XAML.

        Btw, making WPF to run on mobile devices was going to be harder than UWP. Because if Microsoft hadn't done something about a unified Windows development, people would have complained too.

        What makes the Web better today is with the introduction of true responsive design and adaptive design capabilities. Much of the development in the Web arena have been about the UI in a long time and much less about JS until more recently.

        UWP vs WPF is a tough one. UWP can only become problematic when things get really complex, and if examined carefully, bad application-wide design approach is mostly to be blamed. These days, there are various ways to implement application design in a more modern way and things don't have to be done in old ways.

        One other issue I had with UWP was not being able to easily use SQL Server with it, and that has now been taken care of, even though SQL Server data could be accessed over APIs or over a network. But if examined critically, it wasn't a real problem if one could only think in a more modern way. SQLite was just OK for the client in the more connected world of today, unlike when computers were more independent like in the early days of WPF era. Most times, it's an app design/architecture issue.

        I recommend that we should all help UWP to succeed. And ensure that we contribute towards Xamarin.Forms achieving WebAssembly capabilities.

        I guess we do care about Microsoft.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        BTW @Olumide I super appreciate your line of thinking in providing potential solutions. Please do not think that I do not find them valuable with my line of questioning. If you want to join the discussion there on that Disqus thread it is a better way of posting comments and I can upvote them, too. :)

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @Olumide. Have you tried Xamarin.Forms? It's not very well liked or broadly used, mostly because it's very difficult to use and has fundamental architectural/design issues (not to mention INCREDIBLY buggy -- but this is getting better). For one, if you have a custom renderer for a control, you must make that renderer for each platform you wish to support. So if you also include web as you are suggesting, you could end up creating four custom renderers for each control. Hardly viable.

        When you say XF is closer to the web, we should ensure that you mean that it LOOKS closer to the web. XF has NO plans to become web-based technology, save for WebAssembly when it reaches RTM (but when? this is still a risk).

        Also, have you actually tried to make a UWP application vs. a WPF application? Have you encountered an error in UWP? And then tried to find out more context around that exception on StackOverflow? If you haven't, give that a whirl before suggesting that UWP should be promoted in any capacity. There is also the HUGE issue with the Xaml model which I can't even begin to get into it here.

        At the end of the day, the best thing that could possibly happen is the .NET/Core group to assimilate the UWP group, hopefully gutting all its management in the course of doing so.

        BTW I am wrecking shop on this very topic here, if you are up for some good reading/discussion:
        https://mspoweruser.com/microsoft-fixed-fluent-designs-most-stifling-limitation-at-build/#comment-3897863413

      • Olumide commented  ·   ·  Flag as inappropriate

        @Mike-EEE @Marc Roussel

        Thanks for the feedback.

        I still have the following to say..

        Xamarin.Forms is still the right candidate I suggest for whatever cross-platform endeavour that Microsoft does. Even now that CSS is a part of the tooling for Xamarin.Forms, it's closer to the Web than ever. In the end, it's essentially all about UI and backing business logic.

        UWP must stay unique so that it can evolve even if other platforms happen to not evolve or evolve in different directions.

        Also, the Web should not be helped by any native platform. All that have tried it essentially failed (e.g. Silverlight and Flash). TypeScript is still the wisest of them all because it's very compliant with the present and future plans of web standards. UWP will fail if it tries to satisfy the Web. WPF's XBAP essentially failed. Enough lessons learned there. Even Java failed to reinvent the Web. All of them who didn't abide by web standards failed.

        So, my recommendation is that Xamarin.Forms should be Microsoft's cross-platform effort. It's not uniquely about sacrificing Xamarin.Forms for that course. Xamarin.Forms should simply maintain compliance with the current state of the technologies it's rendering to. It shouldn't move faster than them, especially the Web.

        Also, Microsoft should implement Visual Studio in UWP and forget WPF. They should create new ways for UWP to be as ubiquitous as WPF have been. Now, there's an upcoming feature that will enable multi-instance running of UWP apps on Windows. Things are happening, but until Microsoft implements their own serious apps, especially Visual Studio in UWP, people will find it difficult to take them seriously. It is doable. In the end, it's basically about the UI and the backing business logic.

        So, Xamarin.Forms is the best logical bet if Web development is also to be in Microsoft's unified cross-platform effort. No need for a new drastic change.

        Also, for people who hate to design the UI, i.e. people who honestly but wrongfully think UI designers are irrelevant, Microsoft should make more effort to make the Windows Community Toolkit more featured so that UI designers can have a new place for creating customizable UI controls for people who hate to do UI design, and Xamarin.Forms should have something similar for it too. Google is already doing something similar with the much acclaimed Material platform (which I actually had thought would eventually become more like the CSS Bootstrap that web designers use), because they realized that every app began to look the same.

        This issue is not that complicated.

      • Marc Roussel commented  ·   ·  Flag as inappropriate

        @Olumide If I may add to that, at the beginning we had one code base, VB then VB 6 following by VB.NET and 90% of these coders switched to C# and I don't want to argue here about syntax but let stick with C# as a major player. We were all happy in our happiness but something was missing. The whole Windows development wasn't working on the WEB then came an unpredictable thing we welcomed so well : Silverlight. All developer were in extreme joy. Suddenly we reached a canyon and felt in it (without dying of course) and now we are at the bottom wondering how to go back up. Meanwhile at the bottom, many dyed of starvation and the rest of use that still struggle with many syntax and poor foundation which result in a long development process are waiting for a rope or a ladder to help us regain what we had at the top of a canyon which is getting deeper with time.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        I appreciate that you appreciate, @Olumide. :D Thank you for that.

        Unfortunately, if you are not aware, the Xaml Standard is dead. UWP group simply does not play well with others, or at all for that matter. UWP has hijacked Xaml and for whatever reason someone continues to allow their questionable management maintain power despite the fact that they are the primary reason Windows has lost its relevance during the past 5 years. More "discussion" here: https://github.com/Microsoft/xaml-standard/issues/230

        (I denote "discussion" because all of "management" has abstained from any communication with the members they have been delegated to serve. Perfect example of UWP at "work.")

        I especially like the "new" XamlDirect "feature", which is basically a wrapper around System.Activator... a nifty class that has been around since v1.0.

        Also, I respect and understand what you have to say about the web. It *IS* the common denominator. Taken in the context of a few more years, however, it will be even closer to native technologies than what it is today.

        ALSO consider (in my opinion) that "amazing" applications really do not need that much technology to be amazing. I am more of a minimalist in my style, however. I think less is more. If you are looking for super graphics intensive power and/or a game, you are 100% correct. However, for about 95% of LOB's out there (Windows Forms, even), the web currently has you covered.

        The issue of course is that it is a total pain to work with, especially when .NET is involved, and that is what we are aiming to fix here.

      • Olumide commented  ·   ·  Flag as inappropriate

        @Mike-EEE

        First off, I appreciate your work here and everywhere, sir.

        I checked the link. But no matter how productive and efficient it can be to satisfy the Web by compelling native platforms, a truth is that the front-end Web will keep being the one to slow others down. Against my deepest wishes, I see a future where the front-end Web, albeit advanced enough too, would only keep being a common ground and/or interface between various proprietary and public technologies but where no one will be willing to wait for the front-end Web to match up.

        If we examine things critically, so far, the front-end Web has slowed down innovations. With time, other platforms are going to be evolving really faster than the front-end Web can catch up. There are many features on native platforms now that the browser and Operating Systems (OS) built on the front-end Web will not match in a long time, or that it will struggle to match.

        Web Assembly will do a lot but it will possibly not catch up with native platforms because of the limitations of the browser, even though it can be made to run elsewhere.

        In the end, a way forward I see here is to see the outcome of the XAML standard, and also let Blazor and ASP.NET Core keep doing their thing to satisfy the Web. With Blazor, .NET developers won't need much of all the complicated front-end Web framework fragmentations (i.e. Angular, React, etc.).

        We have to let Xamarin.Forms keep trying its best with being cross-platform. And let the precious UWP keep evolving to great extents, even beyond Xamarin, which brings me to why I sometimes think that the XAML standard is not necessary because it's unlike how HTML emulates XML and its predecessor(s) by simply respecting their syntax and stuff but not like the XAML standard is intended to be a word-for-word unification of XAML for both UWP and Xamarin.Forms, which I think is going to hinder the growth and evolution of UWP.

        I believe that Microsoft cannot afford to comform their native platforms to the limitations of the Web. It's dangerous for innovation. So, we should try to live with having Blazor & ASP.NET Core, Xamarin.Forms and UWP if we want to give room for great innovations to happen.

      • Ed commented  ·   ·  Flag as inappropriate

        @Ken
        Sounds good but its not that simple, all MS controls are inside the OS not in .Net or in Was.

      • Ken commented  ·   ·  Flag as inappropriate

        My favorite solution would be to:
        1. Have .NET Core 3.0 working in WebAssembly, excluding the subsets that need system services like File IO.
        2. Complete open source WPF so that the DirectX layer can be replaced with WebGL or OpenGL equivalents.

      • Olumide commented  ·   ·  Flag as inappropriate

        Xamarin can be and is already being used for this. Microsoft cannot/will not/should not do this using the main proprietary platforms, e.g. Windows UWP, for example, which is bound to evolve in a direction that other non-Microsoft platform may not.

        Xamarin is enough to sacrifice for the cross-platform course.

      Feedback and Knowledge Base