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!

6,706 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Developers Win!Developers Win! shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    292 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • yuliya alasheevayuliya alasheeva commented  ·   ·  Flag as inappropriate

        Украли мою разработку, я на Facebook отправляла ссылку, потом удалила.

      • readerreader commented  ·   ·  Flag as inappropriate

        Man, MS reached to a point that even it's own old OS's are left behind, the new .Net 4.6 system requirements:
        https://msdn.microsoft.com/en-us/library/8z6watww(v=vs.110).aspx
        , does not support windows XP, and all Windows Server from 2012 and bellow.

        continuing like this, the new versions of .Net will even exclude more of MS own OS's, and these operating systems are still used by the majority.

        and I did not start talking about other OS's from other vendors, and as some of us recall, when MS talked about creation of .Net
        , it was to fight java moto:

        "Write once, run anywhere" (WORA): https://en.wikipedia.org/wiki/Write_once,_run_anywhere

        , while this succeeded in java to a certain point, it was forgotten by MS. Totally!!

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Thanks for the dialogue, developers... this is awesome. :)

        @Louis, that migration path is unfortunately one of a broken, incompatible system as highlighted by the series. It is transitioning into a sub-optimal and inferior design from a .NET perspective. Again this works great for JS-only solutions, but not so for .NET-backed ones. :(

        @stimpy77: this goes beyond Windows 10 and is for .NET client application developers. The bridges you speak of are going into Windows, not out of, which is backwards and what the series and this vision seeks to address. Even at 1B Windows 10 installs, there will still be ~1.5B installs of Droid/iOS that outweigh Windows 10, and even much more ubiquity found in the web:
        http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/20150923021143.png

        @Marc: To be sure, the transpilers/compilers only come into play when you are ready to deploy to a target environment/platform. Until then you should be able to develop as you suggest: freely and quickly with instant feedback. And yes, I am dreaming out loud right with you, LOL!

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        Here's my little story.

        I did a lot of SL app for many business and I'm actually the only one capable of converting these apps for them. I'm forced to use HTML 5 and JQuery and a bit of TypeScript and let me tell you that it's not the future I wanted. So sad to see both sides so disconnected. Server side very nice OOP c# code with lamda, linq etc and all the glory that goes with it and then you transfer your object s to the client side to find out that you're playing with strings and some kind of freaky OOP that doesn't have real intellisense at all and I don't want to talk about the UI design in HTML which is totally absent of this world which xaml and Blend was offering so easily.

        So yes we need .NET world of development that targets the web of today. We don't have time to incorporate tons of nuget frameworks to develop a web app. The ideal world for .NET developers are like Silverlight. Nothing less seriously !!!

        You can't imagine the effort I'm putting in converting these apps to HTML 5, CSS, JQuery, Razor, Bootstrap, and more where all I had before was C# + XAML that's all and a very great tool to design UI. All this is lost !!

        From my point of view we don't need to see compilers, transpilers, etc these aren't necessary when developing we just need to see one language, one tool, call it ONEDEV if you whish but yeah that's all we need.

        Well 2 language in fact, HTML 5 and C#. Yes it's ok to loose XAML but at least all the business logic SERVER and CLIENT side should be for instance C# and a GREAT tool to design UI with HTML 5 the way we do with Blend not having to write HTML to see what we want on the UI. That's crazy developing UI with HTML 5 text and run the app so often to see what it looks.

        All this is a huge time consuming thing. What as been said here is what I think so don't take it for granted. I'm just dreaming out loud and expressing what I think about all this.

      • LouisLouis commented  ·   ·  Flag as inappropriate

        @Mike-EEE. I have always interpreted the development of TypeScript as a migration-tool for .Net investments towards these new standards. The W3C standardization of the web assembly specification will also ease this transition.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Louis These are all good points, and truly showcase the need, desire, and most importantly the value of creating an innovative solution to revolutionize and cooperate with these standards -- to work in harmony with existing technologies, rather than remain incompatible, expensive and risky (of flight from use). You have only put two years into TS/JS. Think of those who have over 15 years of .NET experience. If .NET was truly compatible with all these new standards you speak of, then we wouldn't even be having this conversation. Unfortunately that is not the case, and we are speaking to that now. To be sure: .NET is currently incompatible with these exciting standards, but they do not have to be. New opportunities (and innovations) do lead to new business indeed!

      • LouisLouis commented  ·   ·  Flag as inappropriate

        @Mike-EEE, Nearly 2 years ago I started to learn TypeScript/JavaScript and I am impressed with the enormous power of the language. I was able to implement a lot of the APL vector-functions in it in a short time in TypeScript, functions that were very difficult to implement in VB.Net or C#. But the main thing I have learned is that there is an enormous software-world outside MSFT, that is working with this technology. I am also looking at Google Polymer and webcomponents as a replacement for XAML. A vibrant dynamic world of tools and components opened my eyes after 30 years running MSFT software only. And what strikes me now is the enthusiasm of the MSFT TypeScript and Edge teams etc. in developing their products. And they fit into this new standard. Well as they say: you are never too old to learn. That certainly affects this pensionado.
        Innovation will always disturb and disrupt an organization, but new opportunities will lead to new business.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Louis that is some pretty fantastic insight, thank you for sharing. It's good to see that you are validating a huge concern here with possibly jumping to NodeJS/JS for your backend, and why there is so much value in this vote. TypeScript might seem like a small step, but you are not just reusing existing knowledge, you are duplicating efforts/concerns between client/server code-reuse and breaking DRY/encapsulation, which ends up being very expensive, as I'm sure you know with your decades of rather significant experience. :) Some organizations might be OK with that, but they will not be as efficient/effective/dominant as those who aren't.

        It will be interesting to see if you end up going all-JS and dumping .NET altogether as other organizations/developers are edging/considering to do.

      • LouisLouis commented  ·   ·  Flag as inappropriate

        @Mike-EEE, I am from the old skool (I am over 68 years ). @ A year ago I became a pensionado, 20 years after starting and running my own software company with 15 people working for me. The software is still mainly .Net based, but I have lost my confidence in MSFT after changing from WinForms to WPF to Silverlight and UWP/XAML or what's next. We went through expensive conversions especially for our Digital Signage software package. We have added in a very short term a HTML5-based player able to play at any Web-browser including smart-tv's. We have found that productivity in HTML5/TypeScript is substantially higher than in XAM/VB.Net. And there is also more continuity in the HTML5/JavaScript direction. The server-side is still in .Net. But Nodejs has a strong potential in order to use one language for client and server-side programming.
        Luckily: from C# to TypeScript is a small step in reusing existing knowledge.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Louis I had to look up APL. Old skool huh. :) To be sure, technologies do come and go, but .NET is not exactly a one-hit-wonder technology. What will the next language be? This vote maintains that it should be the same as it has been: .NET (C#/VB.NET/F#) innovated for the web (and any platform). Well, that SHOULD happen, and that is the point of this vote. It's the only thing we can do and hope for the best, right?

        Otherwise, we will be going down the road as outlined in the referenced article. You either need a JavaScript backend to work nicely with your JavaScript frontend or you end up breaking DRY/encapsulation. This is an expensive approach and organizations that recognize this (and they are already starting to) will ditch .NET altogether. I am sure you can agree that this is hardly ideal, especially with developers/organizations with over a decade of investment/knowledge in MSFT/.NET.

      • LouisLouis commented  ·   ·  Flag as inappropriate

        @Mike-EEE, thanks for your enthusiastic and friendly push-back to .Net. But unfortunately technologies come and go, we are all "asked" to convert. That's the dynamic of the IT-world. From VB6 to VB.Net to TypeScript etc. What will the next language be?
        BTW I started programming in the most powerful and dynamic programming language APL. And it still exists :-)

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Well, if you are so convinced who am I to change your mind, Louis?. ;) ECMAScript/HTML5 is indeed a standard, but that doesn't mean it has to be incompatible with .NET. Mind you, the strategy that you are endorsing is incompatible with .NET, and therein lies the problem that we are attempting to solve here. Rather than following standards, the vision is to innovate with them while still preserving (and yes, strengthening) existing technologies.

        Have you read the rest of that series? You will see CSHTML5/JSIL/Duoco.de transpile .NET artifacts into 100% ECMAScript/HTML5-compliant code. That is the innovative approach that vision this is after.

        It can be done, Louis. Embrace your inner .NET addict and believe again. :)

      • LouisLouis commented  ·   ·  Flag as inappropriate

        I have read http://blog.developers.win/2015/10/the-broken-burned-bridge/ and I am convinced that MSFT alone is unable to set a programming standard as .Net anymore. The billions of future devices will only work based on standards and .Net is not a part of that standard. At the moment Javascript/ECMAScript2015 is such a standard, whether you like it or not. HTML5 is such a standard, and with Web Components comparable with XAML. I was a VB and .Net addict and I tell you that Javascript/Typescript is a strong alternative.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Louis, using TypeScript (or traditional JavaScript) within a .NET solution introduces the problem discussed at length here:

        http://blog.developers.win/2015/10/the-broken-burned-bridge/

        Conversely, what this solution aims for is a .NET (C#/VB.NET/F#/etc) transpiler to JavaScript artifacts.

        However, we're all about and open to the idea and prospect of XAML-to-HTML5 transpilation as well. :)

      • Terry MurrayTerry Murray commented  ·   ·  Flag as inappropriate

        This is quite obviously the largest obstacle to .net adoption. C# is beautiful, and can quite easily be the most popular language in the world. If Microsoft wants usage growth, we need CLR ubiquity. Start picking platforms and making it happen. At the very least shell out the process and let the community do the work.

      • Developers Win!Developers Win! commented  ·   ·  Flag as inappropriate

        Good questions/points, David. There is no doubt progress being made (especially when compared to 5 years ago), but it is not as focused/clear as it could be. That is part of the vision/ask of this vote: to make a clear, innovative push that truly creates a powerful, authoritative .NET client application model for its developers.

        Roslyn is being used by Duoco.de for their transpiled solution. However, it doesn't account for PCLs (Portable Class Library) and other technical challenges. Mono does indeed support the platforms you mention, but not the web. For an idea of how this is important/significant, please see the following chart that demonstrates HTML5's ubiquity when compared against platforms (all figures guesstimated based on current Net Market Share data and MSFT's target goal of 1B Windows 10 installs by 2018):
        http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/20150923021143.png

        Additionally (and more importantly from a business-perspective), MSFT is losing revenues to web developers as they are charging developers to access the Windows Store. Every web developer is another $19/$99 (developer/company) lost from a Windows Store perspective (not to mention fragmenting the .NET ecosystem even more between incompatible HTML5 and .NET client models).

        All the pieces are there for an innovative, powerful solution that preserves/strengthens .NET/MSFT brand and IP, all the while featuring a legitimate business to drive revenue for shareholders. It's just a matter of tying up all the pieces and making it work, while also generating some bucks for MSFT (as opposed to bleeding it via web developer attrition, as is the case now).

      • David TholeDavid Thole commented  ·   ·  Flag as inappropriate

        I'm a little unsure on this. When you look at the new .net rosyln project, doesn't that solve this issue, at least from a desktop standpoint? Also, mono has the ability to push code to android/ios. It's not perfectly seamless, but I think MS is going in the right direction on this.

      • Developers Win!Developers Win! commented  ·   ·  Flag as inappropriate

        Funny you should mention that, Koen. The original version of this vision/idea from over four years ago did account for BlackBerry: http://dotnetfuture.wufoo.com/forms/m1azjhyi1ozawho/

        In the current version/vision, that is denoted with the 8th and final item listing of "different, future platforms." Additionally, transpiled HTML5 client artifacts and packaging would satisfy this requirement as well.

      Feedback and Knowledge Base