The Broken, Burned Bridge
TL;DR: VOTE! ^
This post exists to build consensus in the Microsoft developer community around the idea of a ubiquitous .NET client application development model. Show your support by voting for this idea here:
The Burned Bridge ^
In July 2015, Microsoft closed and responded to a vote for Silverlight 6 that amassed an impressively astounding 16,000 votes (note that the current value is due to votes being returned to users). Their answer: just use HTML5 instead. To say that this is a shocking directive is an understatement. As we have (hopefully) demonstrated so far, HTML5 (or web client development) offers a completely different client application model than a .NET client application model. What’s more, HTML5 is not a Microsoft property. So, why is Microsoft directing its own developers to use technologies that are outside of its intellectual property portfolio (keep in mind that Microsoft does not offer its own client-hosted client application model solution)? This answer – which we call “The Broken Bridge” – is just as confusing as it is expensive, and in this article we aim to illustrate how it is exactly both.
Conceptual and Architectural Problem ^
First, let’s start with the fundamentals by way of a simple example with a typical .NET solution. In this .NET solution, you will find projects organized by server, client, and finally shared code between the two. In shared code projects, you will usually find components that can be used in both application boundaries. A good example of a shared component is an
ExceptionFormatter, which can be used to format an exception that occurs within an application into a desired format that can then further be sent to a logging provider (which in turn could also be another shared component) for instrumentation or logging purposes.
In the world of .NET application development,
ExceptionFormatter happily lives on both server and client applications, and each application boundary will have the same compiled version upon deployment. The component has its own set of unit tests assigned to it and whenever something unexpected occurs in its behavior in (either on the server-side or the client), the unit tests are adjusted accordingly and the component benefits and improves from usage in both application boundaries.
Now, let’s say we follow the directive provided by Microsoft in the closed Silverlight 6 vote above and move our client application from a .NET client application into a new HTML5 web client application so that it can take advantage of the web’s ubiquity. Keep in mind that Microsoft is not offering a solution here, but instead instructing developers to simply “use HTML5 instead.”
In doing so, we can no longer use our .NET shared code assembly, as our compiled .NET assembly cannot be used in a HTML5 application in any way. In the case of our
ExceptionFormatters in our solution: one in our .NET server application boundary and one in our HTML5 client application boundary. Now, each version must have its own set of code and testing built around it. If an inerrant behavior is now caught in one application boundary, it must be accounted for (if applicable) in the other, and vice versa.
If this sounds to you like it is violating a design principle of some sort, then pat yourself on the back, dear developer. It is known as Don’t Repeat Yourself (DRY) and it is a principle that is used throughout tried-and-true quality software development. It is more appropriately and technically known as encapsulation, and when used properly, it yields one of the highest forms of quality found in any software solution deployed today.
Organizational and Resource Problem ^
Add the cost of maintaining two codebases that violate DRY (along with its redundant, overlapping concerns) with the cost of reducing expert organizational resources to generalists, and it is fair to say that organizations now face an expensive problem. By following Microsoft’s guidance above and putting their feet into both worlds, organizations now incur an expensive cost in overhead and architecture that simply does not exist in solutions where the client application model is compatible and unified with the server application model.
Dangerous Directive ^
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 now: