The Backwards Bridge

by Mike-EEE
This entry is part 5 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:

Crossing Backwards ^

In our last article, we looked at the current guidance that serves as Microsoft’s official answer to a ubiquitous web client application model, and have demonstrated how it is a failed a broken bridge to its destination.  In this article, we move on to another attempted bridge to web technologies, and hope to show it is as broken as it is backwards.  This is especially so when we consider its business model implications.

This bridge was built soon after Silverlight, when Microsoft introduced the “new” .NET that was created as a “complimentary replacement” (to use our own expression) to existing .NET and WPF applications.  Known as Windows Runtime (WinRT), this platform was the predecessor to UWP and introduced support for JavaScript under the API name of WinJS.

One might look at that decision and admire the impressive feat of engineering that enabled a language like JavaScript into the .NET ecosystem.  And, they would be correct in this regard.  Another perspective might ask: why?  Why even do this in the first place?  If a developer has an HTML5 and JavaScript skillset that caters to a ubiquitous audience, what incentive do they have to build an application to host within the non-ubiquitous Windows Store when they can use that same skillset to build a ubiquitously-available web-hosted application?

To be sure: as of July 2015, Windows Store-compatible desktop and devices accounted for only 16% of the desktop market.  So, what incentive does a web developer have to spend even one second towards building a solution that only reaches 16% of the desktop market when that same one second could be better used towards building a ubiquitously available application (which, incidentally, completely dwarfs the WinRT desktop market)?

Thankfully, in this case, logic seems to have won the day, as it seems a lot of web developers have asked this very question.  As a result, WinJS has failed to gain significant adoption.

Backwards Thinking ^

But, this is not the end of it.  We continue to see this backwards-thinking strategy being employed by Microsoft to cater to Universal Windows Platform and to bring web development resources into .NET client development, rather than the other way around.  The latest attempt being a JavaScript browser that runs as a Universal Windows Platform application.  Here again, we see the same theme.  Yes, it is neat to see such a combination and use of technologies, but the business challenge is the same: the opportunity cost in applying a HTML5/JS skillset towards making a WinJS application is significantly greater – by factors – than applying that same skillset to making a ubiquitously-available web-hosted application.

Or again, asked as a question: why would a developer who can already reach ubiquity with their HTML5/JavaScript skillset risk the opportunity cost to regress and cater to a market that reaches a fraction of the ubiquity that they already enjoy?  It simply does not make any business sense.

Backwards Business Strategy ^

When viewed by the perspective of the typical web developer, the above value proposition is a headscratcher.  But when viewed through the lens of Microsoft’s current business model, it makes perfect sense.  Here’s why: in addition to claiming adoption for WinJS, Microsoft can also claim revenues from not only the developer, but also in the application that they create to host in the Windows Store.  In fact, in order to even register into the store, an individual developer must pay $19.00 while a company must pay $99.00.  Additionally, Microsoft also takes a portion (30%) of any revenues generated from within the developer’s submitted application. When accounting for this dynamic, it becomes clear that any attractive feature that the API/platform can provide to pull developers into this ecosystem (and by virtue its model) becomes tantamount, even if that means catering to developers whose skill set is better spent on a ubiquitous audience.

But even in this light, a web developer does not need to pay $19 for a ubiquitous application hosted on the web.  So, the incentive is further marginalized to cross the “backwards” WinJS bridge.

Finally, there’s another curious wrinkle to this strategy: Microsoft’s smart acceptance and promotion of web standards provides value in the form of goodwill to the industry and in mindshare, but it does not provide any direct revenues for the company’s bottom line.  As we have mentioned throughout this article, there is not a web client application model technology that is currently offered by Microsoft.  Instead, Microsoft expects its own client developers to use externally provided application models and solutions, such as leveraging a curious relationship with Google to support Angular for web client development.

Microsoft does not garner any revenues from this, and what’s more, Microsoft does not produce or retain any intellectual property or proffer any assets towards its intellectual property cache.  This leads to another confusing and seemingly self-inflicting question: why is Microsoft encouraging its own developers to use external, non-Microsoft technologies to build web-hosted client applications while simultaneously running a .NET client developer registration program whose purpose is to procure registrations (and revenues) for its Windows Store?  For every Microsoft web developer out there deciding to deploy a ubiquitous web-hosted client application instead of deploying a client application to the Windows Store, Microsoft is losing $19 per developer.

Thinking Forward ^

Hopefully it is clear by now that Microsoft is offering guidance that not only hurts its developers and its brand, but is also offering a solution that simply flies backwards in the face of good business sense.  In our next section, we aim to round out this series by demonstrating how Microsoft can fix these issues and mend their ecosystem by successfully creating and providing a ubiquitous .NET client application model offering.

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 Navigation<< The Broken, Burned BridgeThe Ubiquitous Bridge >>
  • Andrew Bares

    Good points, but there are a few things I disagree with…

    Developer registration cost: A one-time fee of $19 or $99 (for companies) is nothing for companies to pay. That’s barely a drop in the bucket. Registering a domain costs nearly that much (the individual one). And considering that the Store gives you placement where more people can discover your app, it’s a decent deal. For example, a new website that is a TV guide manager would have a super hard time appearing anywhere on Google/Bing search results. But enter yourself in the Windows Store? There aren’t that many apps… people can discover your service.

    30% revenue from purchases: If you don’t like that, use your own payment system (which also cost, though yes, don’t cost as much, but then you need to write and maintain code to integrate with those). For websites, if your core website already has a payment system, then obviously sticking with the external payment system is smartest.

    I agree (and so does Microsoft) that the WinJS of Windows 8 wasn’t the best idea. They admitted that at Build.

    Hosted web apps in Windows 10 are the new thing, and I think those actually make sense. With those, web developers don’t have to “regress and cater to a market that reaches a fraction…”, they simply submit their existing website’s domain as an app, and it appears in the Store. If they want to add some light-up features to their site like ability to pin live tiles, pop toasts, etc, then they can, without having to fork or regress anything else. All of their code lives on their web server. They update the app by simply updating their website.

    Hosted web apps exactly address one of your big points: “For every Microsoft web developer out there deciding to deploy a ubiquitous web-hosted client application instead of deploying a client application to the Windows Store, Microsoft is losing $19 per developer.”

    • Thank you for your input, Andrew. Even if it’s a drop in the bucket (and honestly I think MSFT should be asking for an annual fee not unlike Xamarin’s model — maybe not as much as they do it, however :)) the issue is not only the cost, it’s the principle of it. That is, the value proposition is still reversed. MSFT is still charging for something that provides limited accessibility (1B in a best case scenario — 3 years from now) when opposed to the ubiquity of the web (approximately ~3B right now with all devices considered, no hassle). If access to 1B is worth $19, how much is access to 3B worth? This is the desired direction/mindset here. MSFT can be making much (much!) more with ubiquitous access to different client market spaces.

      As for Windows Store value in the form of exposure… sure, you can possibly see better/targeted exposure for your particular application (due to a less-congested marketplace… which isn’t exactly a selling point), but first you need to build it in a way that the store can interface with it, and that leads to your coveted hosted web-apps. 🙂

      It will be interesting to see how this “bridge” fairs. From the desired model’s point of view, it is still considered a backwards bridge as you are asking a ubiquitously-available technology (HTML5/JS) to integrate with a limited-available one (UWP). Pure web developers who do not have a MSFT background will probably ignore this bridge as they first do not want anything that MSFT is selling (there is stigma that MSFT is always battling with that crowd), but also they already have the exposure/ubiquity/audience that they already enjoy from the web. .NET developers might be interested in the bells and whistles, but if they are truly .NET developers, you end up promoting a development model/paradigm that encourages an HTML5/JS client frontend paired with a .NET/C# backend. As a result, you end up with an expensive (WAYYYY more than $19!), overlapping, and redundant development model/paradigm that is addressed and explained in this article:

      So, instead of thinking “how do we pull in $19 from each web developer that can work with Microsoft technology” (limited market and value) it should be a matter of “how do we pull in $19 for every major market every Microsoft developer wants their application to reach” (MASSIVE market and value). That’s the goal here and something I think will resonate with MSFT developers and I dare say its shareholders as well. 🙂

      • Andrew Bares

        I definitely see how there’s value in that proposition. This area isn’t my specialty nor interest, so I’ll just resign from this conversation 🙂

        • Aw man. Just when it was getting good. 😀 Always looking to learn and grow here, Andrew — as well to make sure all considerations are accounted for and accurate. Thank you for the support and thoughts!

  • Eder

    Hello Mike-EEE
    Totally agree with you and already have created a similar thread on MSFT uservoice

    But your idea and study is even more ambitious, and better.
    Congratulations. I already voted on your idea on uservoice and hope it comes to life.

    • Thank you for your support Eder! It’s great to see so much support around both our votes already. Hopefully we’ll grab some attention from the execs at MSFT and we’ll be able to see another dominant client model offering from them in the future.

    • A quick note here, Eder. I’ve got weekly vote reports to see how your vote is doing, along with others that are asking for a ubiquitous .NET. You can see them here:

      Our two votes are pretty much neck-to-neck with each week, which is more than I could have expected and asked for when I started this blog/idea. Additionally, we are also currently the #1 and #2 Hottest Votes on Visual Studio’s User Voice, which again is mind-boggling and WAY past my personal hopes/expectations from the outset of this endeavor:

      • Eder

        Hope Microsoft could hear us and the other 3000 developers who is spending their time to help .net evolve.