Exploring Microsoft’s Xamarin Acquisition with 7 Simple Graphics

by Mike-EEE

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!

 

  • vdxsoft

    Microsoft and Google are currently collaborating to get AngularJS 2.0 (https://angular.io/) to work with Microsoft’s Typescript. I believe that the strong-typed Typescript is the first step in moving toward the NodeJS support of Typescript and eventually being interpreted / converted into .NET syntax.

    • TypeScript is unfortunately 100% incompatible with .NET. TypeScript is a “superscript” of JavaScript. It is used to do exactly what .NET *should* do with JavaScript: transpile into JavaScript-compliant executable commands. It is any wonder why MSFT spent the valuable time of Anders Hejlsberg to create a whole new language that is completely incompatible w/ .NET and C#, rather than creating a way to preserve the investments made in the language that he helped invent and architect. It is also any FURTHER wonder why Anders went along with this preposterous idea as well to further damage the brand that he worked so hard to establish. More around this can be found here: http://blog.developers.win/2015/12/is-net-in-trouble-belated-thoughts-from-connect-2015/