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!

7,230 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 →

    324 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...
      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        I think the first step is integrate Xamarin's XamarinForm into .Net Core, make the UWP appliation model really cross-platform ( the so called UAP(universal applicatoin platform)), this may take 1-2 year, then MS need another 2-3 years to make XAML/C# for web (hopefully works on WebAssembly). So, this is a long journey, be patient wating, guys. :-)

      • Anonymous commented  ·   ·  Flag as inappropriate

        .NET developers want to create web applications in .net and design UI using designer drag-and-drop components, dock/stackpanel, grids, click/double-click events like it has being done always for years in visual basic/winforms/wpf/silverlight/blend, etc. Hope one day we get there again for the web with webassembly, wasm, xamarin, xaml, etc

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hope now that MS acquired Xamarin they can apply that techonology for web also, and allow use XAML for web and web deployment.

        Nobody is interested in doing Windows Store applications for LOB applications.

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        A converter from Silverlight to MVC X is necessary! Whatever the cost because otherwise the cost will go to all those corporations which have lots of Silverlight applications currently running and far too HUGE to convert manually.

      • Eric SchneiderEric Schneider commented  ·   ·  Flag as inappropriate

        Well, if we just had a true cross platform drawing api, the community could build much of it. I have a whole user interface controls stack built in .net, but can't port it because I can't draw anything.

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

        Indeed, Eder! Very VERY happy about that -- to say the least! Cannot thank everyone enough, including the Visual Studio team -- assuming someone didn't hit the wrong button over there or something, ha ha!

        FWIW, here is a post I made about this very update here: http://blog.developers.win/2016/02/for-your-review-we-are-under-review/

        Totally more than I ever expected when I started this vote 4 months ago and I am forever humbled and honored by all that has transpired since then. FWIW, at *best* I was expecting to reach 1,000 votes after one year, let alone two months. Getting 2,000+ votes after 4 months has just rocked my world! And of course I was expecting like 4 or 5 *YEARS* to get *any* sort of recognition/acknowledgement from MSFT, so that has been wonderful as well.

        Granted, it's still just a simple update (without any explanation, no less) but to me that's like getting attention from the hottie in the room ha ha. Like I mentioned in other threads, I feel that question marks are starting to turn into exclamation marks and MSFT really is starting to feel like they are starting to move in the right direction again. :)

      • EderEder commented  ·   ·  Flag as inappropriate

        hey, have you noticed your idea is marked as "under review".
        It's very good to know VS Team is looking carefully at this idea.

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        I was wrong about Bridge.NET sorry about that. It's an excellent idea and upon testing it I find it attractive. Should be integrated with MVC

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

        Whoaaaa... thank you @Philippe Monteil for taking the time to elucidate this very new and emerging concept and technology. Outstanding, even! I do indeed think you have identified the preferred pathway here. I have known about WASM for a while now, but now that I have a better understanding of it I will be using it in my messaging going forward.

        Let's call it... WASM.NET! :D

        This pretty much sums me up right about now:
        https://media.giphy.com/media/75ZaxapnyMp2w/giphy.gif

        I would still like to prefer to think that transpilation-to-plain-old-JavaScript is a valid goal, as I (and many others) feel that is what MSFT should have done (or at least started working on) when they "strategy shifted" (or shafted, really) Silverlight back in 2011. I'm bitter and cannot let it go, I know. 5 years is a long time! You at least can run basic applications with modern hardware as JSIL/org has proven, and that is at least a better pathway than to simply tell developers to work instead with a completely incompatible language/model.

        OK I will now take deep breaths and count to 10. :P

      • Philippe MonteilPhilippe Monteil commented  ·   ·  Flag as inappropriate

        @Mike-EEE: as explained here: http://moduscreate.com/webassembly-explained/
        <<
        You will be able to initially compile source code in C/C++ into a binary representation of an AST tree. The binary version is what’s sent to the browser. No translation of source to binary is required on the browser side, saving a lot of start up time. The AST tree can be directly compiled into optimal machine code, be it x86 for computers or ARM for mobile devices. The implementation of this translator is much more straightforward than for an interpreted language like JavaScript and the resulting code will run quite a bit faster in practice.

        While C/C++ is the initial target language for WebAssembly, there is nothing that precludes implementation of virtually any language that compiles into the AST format.

        One of the clever things about WebAssembly is that it allows for the late binding (or linking) of several WebAssembly modules once downloaded into the browser. This means there can (and will) be an ecosystem of modules that you can mash together to create applications. The late binding functionality allows a C++ module to link with and call functions in a different C module. Or a C++ module can provide a function that can be called from a Java module (assuming a Java to AST compiler).

        JavaScript won’t be going away. Initially, shims will compile the AST modules into ASM.JS or plain old JavaScript. Even once WebAssembly is fully implemented in all the modern browsers, JavaScript will be required to support the countless existing websites that are written in, or depend on, JavaScript. The future will still be writing lots of websites in HTML, CSS, and JavaScript.

        From what one might glean from the WebAssembly documentation and my experience writing C++ around V8, the WebAssembly modules may or may not be running within the engine JavaScript context. Initially the only choice will be within the JavaScript environment, but the ultimate goal is to run alongside the JavaScript environment with ABI interfaces to call JavaScript from the WebAssembly context and to expose WebAssembly variables and methods to the JavaScript context.

        In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly. Any module in one of the languages can trivially call a module in a different language.
        >>

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

        Well @Philippe Monteil now you have me confused. :P I thought WASM was interfaced via JavaScript?

        What is adding to my confusion here is that the creator of JSIL (http://jsil.org) is working on the CIL component for that project here:
        https://github.com/WebAssembly/ilwasm

        This is something I have known about for a while now, but my impression was/is that WASM is all JavaScript, and therefore a transpilation strategy would be the best way to interface with it.

        Please educate us, good sir. :)

      • Philippe MonteilPhilippe Monteil commented  ·   ·  Flag as inappropriate

        @Mike-EEE: a brilliant article explaining the potentially huge impact WebAssembly might have on the web, and in our case on the appearance of a 'ubiquitous .Net client application model.
        BTW, with a technology like WASM in development by the major web browser providers, I am not sure that developing C# -> JS transpilers is still worth the effort, all the more since WASM
        will offer functionalities not available to JS, like a low level support for threading: https://github.com/WebAssembly/design/blob/master/PostMVP.md#threads, among others.

      • DaniilDaniil commented  ·   ·  Flag as inappropriate

        Hi Marc Roussel,

        Thank you very much for the feedback on Bridge! Any feedback is important to us.

        > I tried this simple thing and it doesn't even work.

        Is the test case valid? This piece looks wrong and throws a compilation error "Type expected" in a non-Bridge .NET environment:

        Person p = new () { Name = "Joe Blow"};

        If change to

        Person p = new Person() { Name = "Joe Blow"};

        the test case starts compiling and actually working. I added a "Window.Alert()" call for the sake of demonstration and here is a live working test case:
        http://live.bridge.net/#3393f6e0bd0fb2951146

        > I looked at examples and I dislike the syntax not being like C#

        You might mean chaining in the jQuery demo? If so, then it is just the support of the jQuery library. Anyways, we would be happy to hear more detailed feedback what exactly you consider in Bridge demos not being C# syntax. Just to clarify - all the Bridge demos are written in C#.

        > LOL ... When a UserVoice thread becomes a product's tech support. ;)
        Agree. Mark, you are very welcome to the Bridge forums if you'd like to continue the discussion. Then we could just share forum thread links here for anybody who is interested.
        http://forums.bridge.net

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        All we need is ONE language and the real .NET one please and ONE WEB APP running everywhere. This is what Silverlight was doing so well. We also need something else along that line. We dislike writing HTML by hand for UI thus a need for a great Blend tool to design our interface and having this nice double click action to go right in the C# event code and write the code. I think you see what I mean!

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

        LOL @Marc Roussel! When a UserVoice thread becomes a product's tech support. ;) Marc, that looks like C# to me, albeit terribly formatted. Are you concerned about the [Ready] attribute?

        In any case, I am very appreciative of Bridge.NET supporting this cause and for sharing their project here and for the dialogue that has transpired here. @Philippe Monteil, that link is fantastic. Thank you. Easily the best article I have seen on WebAssembly to date.

        In any case, as the Developers Win! link below outlines, the Xamarin deal should take care of everything but the web. There indeed needs to be a solid pathway or, well, Bridge :) to get .NET into HTML5 browser-hosted scenarios via clever transpilation of JavaScript-to-.NET. It's a complex problem. JSIL.org has been at it for about 4 years now. It might involve multiple teams and technologies (like WebAssembly) to do it.

        The important and key part is to nicely integrate it with all the new stuff that MSFT/Xamarin are doing so that we are all one, big, synchronous, happy .NET family again. :) :) :)

        Once we have this solved it is going to be a golden -- nay, DIAMOND! -- era in Microsoft and .NET history, I dare do say!

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        Bridge ? I just tried this and it's not even close to C# at all. I tried this simple thing and it doesn't even work. I looked at examples and I dislike the syntax not being like C#

        public class App
        {
        [Ready]
        public static void Main()
        {
        Person p = new () { Name = "Joe Blow"};
        }
        }

        public class Person
        {
        public string Name {get; set;}
        public List<string> Compagnies {get; set;}
        }

      • DaniilDaniil commented  ·   ·  Flag as inappropriate

        Bridge.NET team is working on the .NET-to-JavaScript transpilation and other parts which is going to help a lot with the ultimate goal. The goal that we absolutely support. Being open source Bridge.NET is initially meant to help the .NET Community in those ways. Your feedback on our project is greatly appreciated.
        http://bridge.net
        https://github.com/bridgedotnet/Bridge

      • Philippe MonteilPhilippe Monteil commented  ·   ·  Flag as inappropriate

        The WebAssembly project:
        https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.xbywm1lpl
        will make possible one day or another to run .Net code in a browser, give it access to the same API as JS, including WebGL.

        The combination of WASM and WebGL will then offer the resources to implement an XAML like vector-based UI engine able to inject UI blocks in a web page...

      Feedback and Knowledge Base