Super.NET Blog, Dawg

Words on the brave path towards a ubiquitous .NET client model.

Developers Win! is now Super.NET. Learn More

Exploring Microsoft’s Xamarin Acquisition with 7 Simple Graphics

TL;DR: Vote!

The purpose of this article is to build consensus around a ubiquitous .NET client application development model.  With Xamarin’s acquisition yesterday, this gets us closer, but not quite there.  Please show your support for a browser-hosted .NET runtime by voting for this issue in Visual Studio’s UserVoice here:

Xamarin is Acquired by Microsoft

Yesterday it was announced that Xamarin had been (finally) purchased by Microsoft.  When I attended Evolve 2014 in Atlanta two Octobers ago, I had an absolute blast, and the running joke then was that Xamarin is the new Microsoft and that Microsoft should be concerned about Xamarin’s acquisition of it.  Well, we know now who is the bigger dog now officially.  It now seems as if everyone is copacetically running in the same pack so that they can turn their eyes on the bigger alpha dog technology at the moment: NodeJS.

Setting the Stage: The Big Four

So why is NodeJS considered the “alpha dog technology”?  Why are .NET developers ditching .NET and moving their code to Node? Additionally, it now seems that we have cross-platform synchronicity with Xamarin and everyone is excited.  So what is the problem?

I will attempt to answer these questions in this article.  For the purposes of this discussion, I am going to approach it as if I am an ISV (independent software vendor — ala someone who has not drank the MSFT Koolaid), and I want to build an application for today’s marketplace that ensures maximum market reach.  To do this, I am going to have to reach “The Big Four” marketplaces: Droid (approximately 1.7 billion devices), iOS (approximately 1 billion devices), Windows Store (approximately .5 billion devices), and the web (approximately 3 billion devices) (note: please see how I got these numbers here).  Or, as presented in a pretty picture (as pretty as I could make it, at least):

The Big Four Platforms: Droid, iOS, Windows, and Web

The Big Four Platforms: Droid, iOS, Windows, and Web

Reaching The Big Four with .NET

With Xamarin’s acquisition, developers are already anticipating a cross-platform Universal Windows Platform — and they should.  In fact, at this point, if something along these lines is not announced at //build or Evolve, it will be a disappointment.  Now, let’s imagine that there is a new UWP platform — let’s call it the Multiversal .NET Platform — that is built with the new Xamarin acquisition, and I as an ISV want to reach The Big Four.  This is what it would look like from a hypothetical Multiversal .NET perspective, now enabled by Xamarin:

Multiversal .NET via Xamarin

Multiversal .NET via Xamarin

Notice something?  All of the Big Four with the exception of the web are accounted for in this new paradigm.  What’s the big deal, you ask?  NodeJS is even endorsed by Microsoft to build web applications.  Let’s explore that further.

Reaching The Big Four with NodeJS

Remember, I am thinking from an ISV perspective.  I want to maximize my market reach, eliminate risks, and lower my total cost of ownership as much as possible.  I will look at Microsoft’s guidance above and say “Hey you know what, Microsoft?  This NodeJS you mention is a good idea.  _Thanks for suggesting it!_  In fact, when I use it with Cordova, I can also reach the other native platforms and save money by only having to use one technology, one language, and therefore one code base to reach all my desired scenarios.”  That is seen here:

Node.js Platform Reach When Paired with Cordova

Node.js Platform Reach When Paired with Cordova

You now might be asking… hey, what happened to .NET?  Where did it go?

.NET Go Bye-Bye

.NET Go Bye-Bye

The Three Major Hosted Scenarios

So far we have been talking client-side hosting scenarios.  What we haven’t been talking about — and is already solved quite convincingly by Microsoft — is the server-side scenario.  Remember, the more code you have within your code base, the higher the TCO, so you want to encapsulate and share code as much as possible whenever you can, reducing the amount of duplicated code — and the amount of code in general.  This was the major benefit of Silverlight back in the day, and as we will see, the major benefit now when using NodeJS.

To start, here are our hosted scenarios, and the code required to run them:

Hosted Scenarios

Hosted Scenarios

Hosted Scenarios with NodeJS

Below you can see what these hosted scenarios look like when using NodeJS.  I have color-coded the areas where you can share code between the scenarios.  The middle is where code reuse is maximized between all hosted scenarios, and therefore enjoys the greatest TCO efficiency and therefore ROI.

Code Reuse Between Hosted Scenarios with NodeJS

Code Reuse Between Hosted Scenarios with NodeJS

Hosted Scenarios with Multiversal .NET using Xamarin

Here we see the same with .NET.  Notice we cannot share code with the browser scenarios because it is written in JavaScript/NodeJS and therefore completely incompatible with any .NET client application model.

Code Reuse Between Hosted Scenarios with Multiversal .NET

Code Reuse Between Hosted Scenarios with Multiversal .NET

Show Your Support

Hopefully this makes a little more sense to the casual observer.  The purpose of this article (and site) is to build consensus around the idea of a ubiquitous .NET client application development model offering.  With Xamarin’s acquisition yesterday, we are much closer to this goal, but not entirely there yet.  Please show your support for this by telling Microsoft you would like to see support for this by voting for this idea here:

Thank you all as always for reading, your feedback, and support!