by Mike-EEE
This entry is part 1 of 6 in the series The Bridge to .NET Ubiquity


This series exists to build support around the idea of a ubiquitous .NET client application development model.  This is not intended to be a final solution, but a starting point for discussion, awareness, and a sign of demand. Show your support by voting for this idea here:

Welcome ^

Welcome to the series: The Bridge to .NET Ubiquity.  In this series, we aim to tackle what we believe to be the biggest problem and challenge facing Microsoft and its .NET developers today: the lack of a ubiquitous .NET client application development model offering.

We hope to demonstrate this problem in full by describing both its technical and business challenges, as well as its failed strategies.  To start this discussion, we will first look into the requirements that entail a ubiquitous .NET client application model.  From there, we will tour the different known .NET client application models available today and demonstrate how not a single one fulfill all the desired requirements for this goal.  We will then explore the different “bridges” that have been formed towards ubiquity and see how they have failed or are currently failing or painfully lacking.  We then end with a possible desired solution for a ubiquitous .NET client application model, and demonstrate how this can be built by Microsoft to solve the business and technical challenges it currently faces.  This proposed solution is not a final vision, but is meant to provide a starting point for awareness, direction, and dialogue for this most important (and overdue) goal of establishing a ubiquitous .NET application model.

The Vision of a Ubiquitous .NET Client Application Development Model

The Vision of a Ubiquitous .NET Client Application Development Model

Who Are You?  Who is the “We?” ^

But first, who is the “we” when we speak of “we?”  Or more like “who are you?”  This blog is (currently) written by a single individual, Michael DeMond.  I go by the nickname of Mike-EEE and have been a .NET developer since 2001.  There is nothing special about me, other than to say that I have chosen to spend my years coding rather than wasting it on words blogging or trying to bring attention to myself. Until now, that is. I am simply an opinionated developer who has finally felt the need to put these opinions in a more organized, central medium than random arguments and discussions by way of internet posts and forums.

When I began to write these posts, I did in fact write them from a singular first-person perspective. But, as I wrote, it didn’t feel right for some reason and I ended up switching to using plural pronouns and “we.” It felt more natural to use the plural pronoun “we,” and when I thought of this, a couple reasons came to mind. First, this blog’s roots are found in a failed (and poorly-marketed) petition from back in 2011.  In much the same vein, this series (and its host blog/site) has the same goal as that petition but in a new (and hopefully better-marketed) form: to secure votes around an idea.  So, I feel when I speak, I speak for the people I represent on a particular subject or vote topic.  Based on some votes that I have already posted, I know that I not only speak solely for myself, so that also factors in my mindset here.

Additionally, I have also found that I lean towards using “we” as a “you and me, dear reader” throughout these posts. So, the feeling of “we” feels more natural within the context and spirit that this site and blog was created. To mitigate any sense or risk of misrepresentation, I have explained its use here and will link to this explanation accordingly when the word “we” first appears within a post.

Defining Ubiquitous ^

With that out of the way, “we” get back to our series here.  This series is intended to explore (and suggest) the notion of a ubiquitous .NET client application model. In our next post, we will begin our exploration by listing the desired qualities that make up such a model.  Please subscribe to our RSS (or Facebook / Twitter) to get notified when this and other future posts are available. See you there!

Show Your Support ^

If you like the idea of a ubiquitous .NET client application development model, please take the time and let Microsoft know by voting for this idea on UserVoice:

Series NavigationUbiquitous Qualities >>
  • Steve Shaw

    I am THRILLED to see this blog post. You say it so much better than I could. .Net (C# plus some platform library, whether BCL or otherwise) as source, as the platform in which we develop, HTML5 as target – its a no brainer. I had not grasped until reading your post that XAML was the other piece. There is one aspect which you have backwards: I was stunned when you dinged Xamarin.Forms for adapting to each target platform. No, it is HTML5 which is limited, by forcing every platform to act the same. Better “consistency” goal is to accurately support the UI MODEL everywhere, but adapt to platform conventions. Human equivalent is to go to a country with one’s business goals in mind, but adapt to the local culture. Just like we adapt to: human language, currency, screen size, reader capabilities and accessibility requirements, as well as user preferences. Xamarin.Forms gets +1 for doing what is really wanted. How awesome would it be if one’s iPhone kept behaving like an iPhone, even INSIDE the browser window?

    • Thank you so for your feedback and compliment, Steve. It is very much appreciated. Admittedly, I would have to rank consistent user experience as the least important quality if this project was actually implemented. That is, if it was a matter of having a ubiquitous client application model, and only 6 of the 7 could be fulfilled, the consistent user experience would be my choice to go.

      However, having said that, there are a couple additional considerations on why this quality is important and must be considered:
      1) Long-term design approach. Consistent user interface has been experienced with web sites and web browsers since the beginning of the web. In fact, the only time really where users have been passionate about “platform-specific” application user experiences has been with the mobile revolution. That is, with both Droid and Apple, each started with their own ideas of user experience and this conditioning (training) has been part of this expectation and a source of “platform pride” (for lack of a better term). In 10 or 15 years, do you think these paradigms will even matter? It’s also curious that these same passionate users will visit a web page on each of these platforms, and this condition/training/expectation does not apply. A web page can act totally unlike a native application and no one complains about it. Yet ultimately, what the user is interacting with is a client application, just hosted in a different process (web/browser). Don’t you find this dynamic curious? Again, I am in the camp that feels that native/platform-specific user experience is a fad that eventually will get replaced by a (web-like/platform-agnostic) ubiquitous user experience. I say this also because of the next point…
      2) Cordova. You can see with the Cordova SDK/API that this is starting to shift the conditioning. Cordova is essentially an HTML5 application hosted within a Droid/Apple/Windows WebView control within a native host. The result is a consistent user interface and experience, just a web page.
      3) Themes/styles. Even with all of this said, designers/developers will be able to create their own themes and styles that either mimic host user experiences and/or improve upon them (to evolve them even further). So, in the end everyone will win as user experiences will continue to evolve and improve. Hopefully. 🙂

    • Looks like you edited your initial post after the first post, and I am just seeing it now. Really good ideas here, Steve. 🙂 First, I would say that your idea for Xamarin for HTML5 would indeed be a good strategy. However, I have had conversations on their forums and that seems to go against the grain of their community, and something they do not wish to explore. Check this thread out for more:

      Also, not to mention that Xamarin.Forms is (ironically) not open source. Additionally, their Xaml system is also closed source and is an internal (non-public) API, not to mention it is tightly-coupled to BindableObject ( ). So, there are some challenges there. However, they do have Evolve 2016 coming up and I would be shocked if some of these are not addressed there (at the very least I am expecting open source XF).

      I would agree with your take on CSHTML5, as they are very much a small vendor with large ambitions at the moment. Even as such I am a big fan and supporter of their efforts.

      Any way you slice it, this this is a massive undertaking that can really only be designed and executed by Microsoft when all is said and done. Hence the vote. I would also like to reiterate that all the content here is just a starting point, and it is up to great feedback, discussions, and ideas like the ones you are presenting that will make this work. I definitely appreciate any support and votes you can help send this way!

      • Steve Shaw

        BTW, given iOS 9.1 and Android 6.0, I feel that the mobile standards have solidified enough that it may no longer be vital for native apps to use true native widgets – skinning may be sufficient; it is now worth the effort to develop skins that behave exactly like their native hosts, where desired.

        Specifically, NoesisEngine rendering in OpenGL in Unity 3D is a very powerful Xaml + C# UI solution. Sometime in 2016, Unity should complete the transition to native performance, by AOT compilation using IL2CPP. Unity has a browser plug-in for desktops. All combined, I am hoping this results in a great short-term solution for C#+XAML apps: app stores for mobile plus browser for desktop.

        In contrast, further research and thinking has led me to conclude that transpiling C#+XAML to JS+HTML will be unsatisfactory. Fundamentally, it is problematic to map one object model, CLR/IL, to another, JavaScript. Will be serious problems with performance, memory usage, download size, and subtle incompatibilities and bugs.

        A web-based ADAPTATION of C#+XAML, into something a bit different, would be more practical. Instead of attempting to preserve full semantics of C/X, start from JS/H/CSS, and work up towards C/X. Get as close as practical, but stick to semantics of the target. Perhaps target AngularJS as base library/app framework.

        And then pray that the gap between the apps made via Noesis/Unity, and the apps made by all JS-based solutions, leads to dramatic improvements in web standards in a few years!

        Meanwhile, I’ll stick to Xamarin and Unity. I’m not going to waste my brain cells on lesser compromises.

        • Really awesome discussion, Steve. I appreciate all of your thoughts here. I’m glad to hear your thoughts on “native” UX. The way I look at it is, superior UX is superior UX and is not platform-specific. Perhaps it was at the beginning of the device revolution, but as time goes on, it all will (and is currently) coalescing to share the best of all paradigms. Such is the web, as well.

          As for transpilation, it is indeed problematic but not impossible. In fact, there is the WebAssembly movement going on right now that I am just beginning to wrap my mind around, and you might want to check it out. The creator of is currently working with Google/Mozilla to get CIL integrated in this new framework:

          For your other thoughts, indeed there are a lot of moving parts and pieces out there. Again the best we can hope for is a crack expert team @ MSFT to pull them all together and execute on them like they did with WPF (I believe that’s the best comprehensive tech to ever emerge from MSFT).

          Of course, this team will not ever form if they do not think to do it. They will not think to do it unless we as a developer community tell them to do so. 🙂 I appreciate your support (and for your posts in the Xamarin forum!) and for your votes. Please tell as many developers as you can and please get them to vote. Thanks again for your thoughts and efforts.

          • Steve Shaw

            Amazingly, Unity seems to have already accomplished this (C#+XAML => JS+HTML+CSS)!

            (I don’t know how I missed this before)

            Unity WebGL:

            Granted, its status is “Preview”. But they seem to be very far along. Certainly much farther than anyone else!

            P.S. your view that “superior UX is superior UX” is like an American going to Paris, and getting into an argument over who’s culture is superior. You fundamentally are missing the point, IMHO. I pray that there will always be cultural variation, both in real world and virtual world. Yes, different cultures will pick up good advances from each other – that’s progress. But if all platforms end up IDENTICAL, then what happens to personal taste and preferences?

          • Haha… they won’t become identical, as they will always be taking the greatest of the greatest and improving on them! Right now we are all silo’d in Droid/iOS/Phone which is actually harming innovation and progress in this regard. Once these walls are removed and we are free to compete and innovate free from the bondage/cult of platform, we will be in a fantastic era for application design. Again, this has been happening for decades with the web, and nobody has been complaining about it. In fact, it is safe to say that the web and native UX models have been feeding off each other for the past decade, no?

            I did look into Unity and was not impressed at all with their .NET idioms. The way they design their applications might make sense in other paradigms, but for .NET it seems very ugly and inferior. Maybe in a few more versions after some serious integration work they might be viable. I do know that they have been working towards WebGL, which is one of the factors that made JSIL a legitimate project to me, personally (I found out about JSIL when WebGL wasn’t really a “standard”). 🙂

            Additionally, I do not believe Unity supports Xaml, and their .NET framework support is 3.5? Simply not a viable framework version.

          • Steve Shaw

            That was my view (Unity not having the right stuff re framework) until very recently. (1) Once they are on their IL2CPP for all target platforms, they can finally leave behind their ancient framework version – it will be straightforward for them to keep up with latest versions via the open sourced .Net code and Rosalyn (2) I mentioned: “NoesisEngine rendering in OpenGL in Unity 3D is a very powerful Xaml + C# UI solution”. So no longer just dependent on Unity’s built-in functionality. (I have not investigated the details yet.) It is this 1-2 combination that will make Unity worth reconsidering, at some time in 2016 when they upgrade to a newer framework.

          • Great. Yeah, it will be interesting to see what they come up with. In the meantime, Xamarin also announced Urho3D, and that looks like it has all the pieces needed as well, just missing a Xaml engine. 🙂 I will be looking into this for my upcoming project.

          • Steve Shaw

            Ah, I saw a brief mention of Urho3D, but am too busy finishing our main app to investigate. Thanks for the reminder that that exists. I will be interested to hear how that works out for your project.

          • Thank you. You can follow along with my check-ins here:

            (I also just realized that I need to update that readme haha)

            Happy Holidays, Steve. 🙂

          • Hi Steve, I couldn’t help myself… and made a post expanding my thoughts on Xamarin above. Mostly due to random comments like this where I had to keep explaining myself over and over. 😛 You can find them here:

          • Steve Shaw

            Ah, I saw a brief mention of Urho3D, but am too busy finishing our main app to investigate. Thanks for the reminder that that exists. I will be interested to hear how that works out for your project.

        • Some other thoughts around this Steve. First, I do not want to make it seem I am slamming Xamarin. I have a lot of respect for them in that I consider them the catalyst in getting the open source revolution started in MSFT. However, they do have a few shortcomings as I have already provided, along with this one that I wanted to mention: Control vendor design friction.

          Due to the design of their rendering API (which is in itself closed/internal and not for extension — another issue I hope to see addressed in Evolve 2016), there is a strategical flaw in how they allow controls to be designed for their platforms. If you are a control designer, you have to create a renderer for each and every platform that Xamarin supports. This is cumbersome. If Xamarin adds support for a new platform, the onus is on control designers to retroactively build a renderer for each and every one of their controls to support that new platform.

          It is my opinion that the onus for such design should rest within the platform itself. That is, adding a control from a control vendor’s point of view should be seamless, and much like building an application around the platform, the focus/thought/effort should be on the problem area/concern that the control solves, not lower-level concerns such as drawing/rendering.

          Additionally, (and again I do not want to seem like I am slamming Xamarin as what they have accomplished thus far is pretty impressive), the renderer API is sort of flimsy now, as all of the renderers and functionality are built around the Xamarin.Forms.TargetPlatform enumeration, when it really should be based on a robust profiling mechanism that allows for better description of the host environment and its capabilities. IMO, of course. 🙂

          Anyways, I wanted to get that out there so I can reference it in the future, and also to get your thoughts around it, especially if you have designed custom controls and have had to create renderers for each of the supported platforms.

          • Steve Shaw

            Thanks for that info Mike – I have not made custom controls with Xamarin, and was not aware of the issues with that. In fact, for our current apps, we gave up on Xamarin.Forms due to other limitations (that probably could have been surmounted, or easily fixed by Xamarin if we worked with them, but we could not risk the delay) – so went back to the safer but redundant approach of separate UI coding per platform. These apps we only care about iOS and Android, so that was not onerous for us. Will revisit in six to twelve months, when we have time to work through any issues.

          • Please keep in touch and let me know how it goes! It’s always great to see the chatter out there.

          • Steve Shaw

            BTW, official response from Xamarin that they are ignoring web at this time: Miguel de Icaza- “We do not have plans to target the web space at this point.”

            I suspect this means we won’t see any dramatic improvement in HOW they approach these fundamental technical issues. With only 3 platforms that matter in the app space (Apple, Google, Microsoft), it doesn’t weigh as heavily for them.

          • Yeah that is disappointing. I have added to that thread. 😛 Thanks for the heads up!

          • Yeah that is disappointing. I have added to that thread. 😛 Thanks for the heads up!

    • Here you go, Steve. This is a solution I just found out about from the Azure group. This allows for Windows applications to be piped in through iOS/Droid devices, and as such provides the consistent user experience we have talked about. Since it is based on Remote Desktop it is not a viable solution for consumer-space, but it worth knowing and thinking about:

  • georgebirbilis

    the “Advancing a ubiquitous .NET client application development model and other improvements.” header is a bit cut-off in Firefox. That is the bottom part of g, q etc. Probably those two lines have small fixed height or something

    • Hi George thanks for letting me know. I do see what you are talking about… Looks like the 2nd line’s text does hang down a smidge. I did try playing around with the line-height in FireFox and it didn’t seem to fix it. If you have any suggestions on which CSS property that is causing it I will check it out. Otherwise, well,.. you (hopefully) know the story when it comes to CSS. 😛