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:
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!

10,169 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 →

    469 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • 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.)

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Wow @Marc... that IS a good video. All until the end when it talks about async, though. What a stain on our language:
        https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/9126493-improve-asynchronous-programming-model

        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!!!

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        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:
        https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3556619-silverlight-6

        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.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        +1 to Marc's sentiment, but do I have to actually state that at this point? LOL... @Marc I think it's better to state that this as a business problem rather than comparing technologies. When you introduce JavaScript (or ANY language that isn't .NET/IL-compatible), then you have simply doubled the amount of code required to build your solution. Smart businesses will realize (and already have) that they can dump .NET altogether and simply use JavaScript as it can be used everywhere while also enjoying the ability to share code between all known boundaries (as you suggest with .NET). This is an INCREDIBLE amount of cost savings as not only you can easily leverage existing development but bugs fixed in one area are automatically fixed in another and vice versa. With JavaScript paired with .NET you are constantly chasing bugs in both frameworks -- not to mention constantly learning quirks in both frameworks -- leading to a lot of time and money lost due to such endeavors.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @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:
        https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-frameworks-libraries-and-tools

        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.

        Additionally you seem to be missing the point about JavaScript, as Blazor is meant to replace all the expensive, friction-prone script that you use in a typical web-hosted application and use .NET instead, thereby reducing the total cost of development for a .NET solution.

        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.

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

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

      ← Previous 1 3 4 5 23 24

      Feedback and Knowledge Base