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

11,267 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Developers Win! shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Mike-EEE commented  ·   ·  Flag as inappropriate

    Correct, shimmy. All of the "Big Four" are accounted for, with the exception of the Web.

    I would also like to share my appreciation for your comment along with Lukas and Alberto's comment. And by appreciation I mean 100% agreement and shared vision. :)

    I also have to say I am a bit disappointed in //build and Evolve in that no cross-platform UWP was announced. Xamarin.Forms is a good stab, but has a lot of problems. I guess for the time being the best answer is Perspex, which is very much under development (and does not support web):

  • shimmy commented  ·   ·  Flag as inappropriate

    This is now partially achieved with Microsoft acquisition and open-sourcing of Xamarin. Anyway, Xamarin doesn't provide a solution for web browser yet.

  • Lukas commented  ·   ·  Flag as inappropriate

    UWP needs to be added to Xamarin so we can deploy an UWP app with the exact same UI definition to other platforms. Xamarin.Forms is not suited at all for consumer apps. We need a real UWP XAML runtime on Xamarin. Also a WebAssebly version of the UWP runtime should then be made, so we can deploy UWP apps directly to the web as well! This would be pure awesome.

  • Alberto commented  ·   ·  Flag as inappropriate

    Cross platform for mobile is covered with Xamarin, it just needs to improve and fix bugs and integrate in UWP.

    What is needed is running this UWP/XamarinForms in browser without plugins to create LOB web applications that can run everywhere ( from mobile to browser). The HTML/JS model doesnt work for .NET developers, you need to hire different skills in your development group and it makes grow difficult and unproductive.

    It is like if you need to hire a sysadmin that is an expert in linux and windows, there are some but they are difficult to find and expensive, usually there are windows professional and linux professional and they just want to stay in their comfort zone and grow in windows or linux.

    Same is applied to .NET and HTML/JS, you will find expert in HTML/JS but they will prefer to use NodeJS on backend than learning that MS .NET thing. You will find .NET backend experts but they are not good/productive/passionate about HTML/JS.

    At the end you dont have the flexibility to hire just a full stack .NET developer when you grow that can work full stack and move from UI to backend depending on company needs while growing.

    As now applications need to be written for all mobiles and WEB, I see this unified application model broken until there is a good solution to develop as web applications that run on browser.

    Even if MS just decided to support it for Edge browser it would be great because remember it is mainly for LOB applications, for just a website company content/newspaper/etc HTML/JS is fine. The problem is when you want to create modern apps that run everywhere.

    Microsoft is getting more and more open so why not give the flexibility and embed this on Edge to give the choice. You will be endorsing standars HTML/JS as you are doing now but also being flexible and give a choice for developers to use your flagship NET/UWP modern apps platform that you want everyone to use for building windows/mobile apps.

  • Alan commented  ·   ·  Flag as inappropriate

    How about creating open source project to create solution to run UWP 10 apps on Android and iOS. Right now I don't know how, something like Xamarin Forms but using UWP UI Layer,
    so your UWP app without changes can compile for Android and iOS.
    If somebody is already doing it or want to do it, I like to contribute. If not? May be I do some investigation, what it takes, do it. Any suggestions?

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hope is not so long! silverlight dead 5 years ago, cant wait other 5 years to run "native" applications in the browser again.

    I watched Webassembly demo running a game in browser and looks awesome. Hope MS is working in that direction to run UWP/XamarinForms apps in browser.

  • Anonymous 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 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 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-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. :)

  • Eder 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 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-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:

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

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

Feedback and Knowledge Base