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:

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!

8,531 votes
Sign in
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 →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • birbilis commented  ·   ·  Flag as inappropriate

        ...and if he means for Canvas support (for rendering), there are some fallbacks for it too (using Flash etc.). Not sure if one uses WebGL for rendering if there are any decent fallbacks

      • birbilis commented  ·   ·  Flag as inappropriate

        Not sure why he says "Con: Relies on fancy new support in modern browsers. Fortunately support is ubiquitous today, but this won’t be working on Windows XP." at http://praeclarum.org/ - Isn't there available an (automatic?) asm.js fallback for WebAssembly?

      • cs mr commented  ·   ·  Flag as inappropriate

        The important aspect of native apps for me is efficient compilation to native code. Bytecode is OK, AOT even better. Of course what matters is the end result: memory usage and performance.

        Current examples seem to confirm that serious apps (e.g. 3d games, office applications, adobe cc-type applications, AI) cannot be written using javascript or anything compiling to javascript, without being laggy memory-hogs.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Hah, well "better" is relative, and of course every application is different and tailored towards its intended market. Certainly native hosting environments offer "better" :) integration with device components and hardware accessibility. But also consider that HTML5 is slowly gaining more and more access to these features as well.

        > Webapps are a cross-platform technology, that make it easy to reach many platforms, albeit with a low-quality solution.

        Consider that the only difference between a "webapp" and a "nativeapp" is the hosting environment. That's it. You can technically run an HTML5 "webapp" in a nativeapp via Cordova and a suite of other technologies. A "webapp" is simply an application that is hosted in a web browser host process. It is not a website, although those have historically existed, and are probably contributing to your conflation with the two notions (and that of "low-quality"). If you have not taken a look at WordPress's editor lately, try checking it out and see if you continue to have the same notion of a "webapp" being of low-quality. From what I have seen, it is just about as good as any WPF application I have seen, and then some, especially when you consider it can be rendered on any modern browser (and therefore device).

        > But if we can reach those platforms natively, why would we want a webapp?

        Or conversely, if you have one application that runs within a hosted web browser context (i.e. everywhere), why would you want nativeapps? :)

        Along such lines, consider the sheer amount of resources required to get .NET to run and emulate a Droid/iOS environment. Or even UWP. You will spend a day in Visual Studio installing all the required (100s of GBs!) software to simply launch an emulator (or UWP scene) from your installation, assuming you do not run into obscure platform-based hiccups. Whereas with web, a simple visit to a URL is all it takes, no special installs required, outside of the web browser you run it on (preinstalled on all devices these days) and the web server that serves the content, of course.

        And, of course, this runs through the whole "web" experience. Users don't need to go to a store or perform any installation or permissions checks to run a web application. They simply visit a url/location and it "just works" without having any proprietary magic or store voodoo. In fact, if you have a web application and force the user to further install a "native" app, you risk losing that user altogether as you already have them right there. In your web application. :)

        The web is simply much more lightweight and as it incorporates more and more native-esque features and functionality, it will become the defacto platform to develop and deliver upon as such. That's not to say that it will replace native applications (although it might), but it should certainly be considered as a peer platform to the current 3 platforms that we find ourselves with in the current landscape.

      • cs mr commented  ·   ·  Flag as inappropriate

        From my business's point of view, once we have covered all the platforms, we would not release a webapp because anyone can get a native app, which is better (performance, memory, reliability).

        If we didn't have coverage, then yes a webapp would be worthwhile. Webapps are a cross-platform technology, that make it easy to reach many platforms, albeit with a low-quality solution. But if we can reach those platforms natively, why would we want a webapp?

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Sorry brogrammer... if there is one thing in all of MSFT that is worse than UWP it is IE. You're on your own there, I'm afraid. ;)

      • Aaron commented  ·   ·  Flag as inappropriate

        Mike-EEE, OOui does look very promising. I hope the project continues to grow. Presently, I was only able to view the examples in Edge rather than IE. Perhaps there's some security setting that needs changing?

      • balazs hideghety commented  ·   ·  Flag as inappropriate

        Yes, especially IoT device support could be released separately! Some 3rd parties based on MONO does exist...

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Heh heh Aaron, yeah ... about that UWP. Installing that bloated SDK on your machine via Visual Studio takes about a day. Same for Xamarin's Droid experience. I got mass respect for Xamarin for the magic they have pulled off to get .NET working on Droid, but there's a LOT involved in getting it to work on a developer machine. UWP, OTOH, seems like they have put every second of every "employee" in their organization to destroy the MSFT brand. When they actually get around to doing any work, that is. ;)

        Now, compare this with working in a web page. You don't have to install any grueling SDK packs or muck with any emulators. It "just works" and is incredibly lightweight. This is why I am so sprung around the WebSocket Bridge approach as demonstrated by Ooui that I mentioned earlier. The same lightweight code that is used to work in a webpage can also be used in a native environment. You could do 99% of your development by viewing it in a webpage (no WebAssembly required!) and spend the remaining 1% deploying it to native hosts to make sure it works there. In theory. ;) Very promising stuff.

      • Aaron commented  ·   ·  Flag as inappropriate

        Well for me, it's .xbap (or at least WPF) until the wheels fall off. I work for a large Fortune 200 building internally LOB apps deployed to a Citrix Zenapp farm, so cross-platform be damned. I am one of those unrepentant crazies who appreciates being able to write strongly-typed , object-oriented C# code in WPF without having to learn a half dozen ****** little scripting frameworks every few months. And since my apps run on server that sits physically next to the database server, they happen to be faster for remote users than my counterpart's ASP.NET apps.

        Only downside is I am now am getting one project where they don't want users to have to log into the Citrix portal. So I threw the .xbap up on a SharePoint, which works fine for the next 5 years or so, as long as Internet Explorer continues to exist, then I suppose I'll have to route everyone through the Citrix Portal and hear all the attendant gripes about logging in. Too bad the HTML5-shilling , Google-wannabe idiots over at the Edge development team would much rather have pages load a couple nanoseconds faster than to continue to support a format that is a perfect fit for intranet development in oh, say, about 80% of the largest organizations out there. I guess I know how you Silverlight guys must feel now!

        If Microsoft isn't going to give us Silverlight vNext because they're so worried about cross-browser and cross-platform compatibility, the least they could do is make the latest Windows browser support XAML in a browser in one format or another, for the benefit of the great many of us business developers who don't give two ***** what Apple and Google are up to and just want to deploy to our intranet windows users. UWP through hyperlink ? Yeah that might be an option if the many remaining Win7 user's machines all breaks at once and users get upgraded to Win10 overnight...and if I can somehow work through the built-in security hurdles. I'm curious how many UWP success stories there are from former Silverlight or WPF/xbap developers. So far I haven't even been able to compile a UWP without security hassles....

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Yeah, I gotta say I am very drawn to Ooui's approach over Blazor's ATM:

        As I mention there, it doesn't support data-binding (yet ;)), and other issues, but consider that this works in all four platforms: iOS, Droid, Windows, *and* web. Additionally, with the web scenario, you aren't faced with the prospect of massive downloads (or a proprietary technology that requires codified agreement between Google, MSFT, and Apple, blahhh). The websocket magic sends all the information back and forth between client and server.

        Even better, this allows us to sidestep Xamarin.Forms and UWP altogether. ;) ;) ;)

      • Anonymous commented  ·   ·  Flag as inappropriate

        What about PWA (Progressive web apps) and C#/WASM? looks like a great thing if we could build C#/WASM websites that also run fast and like native on mobile, desktop, etc

      • Henry commented  ·   ·  Flag as inappropriate

        - Does not require store apps for Windows or Mac
        - Object serialized on one platform can be deserialized on any other platform without extra work or loss of floating point number or integer number precision
        - Development tools, libraries, packaging, etc should be runnable and able to build production applications without accesssing a third party store, web service, etc. This is needed for any realistic long term support policy. I should be able to rebuild and redeploy a product 5+ years in the future after its first release.

        Software escrow is an important part of large scale commercial software enterprise solutions.

        Reliance on 25 different third party or second/third tier MS libraries is a failure risk 2+ years after the first production release.

        A $1+ million budgeted project with a lifespan of 7+ years for corporate document retention requirements is unlikely to include any short-lived, 2-3 year, components.

        As said elsewhere, 2 to 3 developers, a github repository, message base and few random blog posts does not make for a reliable and long lived component.

      • Marc Roussel commented  ·   ·  Flag as inappropriate

        I think it's ok. We don't need it anymore ;)

        Did you ever try to do a grid like Telerik Silverlight RadGrid in Javascript ? You better have to work on it fast and for a long time. Despite having a lot of people trying to push some kind of Data Grid out there. I saw all of them and none are 30% of RadGrid and specially all typed with C# on the client side Mhuaaaaaa

        Right now I'm doing a BIG project in JS/Razor/C#/Html/CSS/Jquery/Ajax and everything else and I had to forfeit with their old Telerik RadGridView and go with CARDS instead. No more fency rows with cell colors, filters, aggregates and validation made easy. That time is the past. Now it's CARDS and simple

      ← Previous 1 3 4 5 19 20

      Feedback and Knowledge Base