Existing .NET Client Application Models

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

TL;DR: VOTE! ^

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:

.NET Client Application Models ^

In this post, we outline all the known .NET client application models and compare them with the list of qualities we feel are necessary for a truly ubiquitous .NET client application model. As we will demonstrate on a case-by-case basis, each model below possesses one or more qualities, but no one single model possesses them all. It is through this exercise of compare-and-contrast that we hope to accurately outline what a ubiquitous .NET client application looks like, as well as provide a window into the frustrating search of successfully finding a ubiquitous .NET client application model in today’s market. We have broken the different models into two different types: compiled (native platform) client application models and web-based client application models, and start with the compiled models first.

(With each client application model below, we have denoted matched ubiquitous qualities in green icons and unmatched ubiquitous qualities in red icons.)

Compiled (Native or Store-Hosted) Client Application Models ^

Windows Forms ^

We start with Windows Forms. Windows Forms can be considered the first .NET client application model and (surprisingly) still pulls weight today in the world of line of business applications. There is even an outstanding vote with considerable backing to make it open source. As this was the first .NET client application model, it did lead the way with the concept of a designer-friendly tooling paradigm. However, the designer was not based on a serialization mechanism and this led to a lot of code being generated instead, leading developers to mark this as a negative aspect of Windows Forms development. In fact, it is safe to say that this aspect is what led to a more robust, readable, and manageable solution found within its successor and the next model we will visit. As Windows Forms was built with the first version of .NET, it was inherently Windows-only, with no chance of cross-platform capability. However, as a native .NET client application model, it does benefit from the holistic development consistency that occurs when being a part of a .NET solution, as well as shared components and assemblies between application boundaries.

Windows Presentation Foundation ^

The big daddy of .NET application client models. Windows Presentation Foundation (WPF) was simply an outstanding innovation in Microsoft client application technology, and can be considered the de facto standard for any .NET client application model. WPF was innovative in many areas, but primarily in how it enabled serialization and design through the use of a new technology known as Xaml. Xaml is an object description technology that is based off of XML. When WPF was first introduced, Xaml was strictly for defining and describing user interface elements. In later versions, this power got abstracted into its own assembly with System.Xaml, where it lives today and other frameworks such as Windows Workflow utilize it. WPF has it all except for cross-platform and web compatibility. In fact, this very shortcoming is what led Microsoft on another endeavor to bring the power of WPF to the web, known as Silverlight.

Silverlight ^

Silverlight is probably the most controversial, misrepresented, mis-marketed, and misunderstood product in Microsoft’s history. To date, Silverlight is the closest match to a ubiquitous .NET client application model that Microsoft has ever created. To the developers who loved it, it was a ported subset of WPF, a .NET client application model, enabled to live in a browser in a cross-platform way. To everyone else, it was a disruptive plugin that required installation on the users machine to operate correctly. Silverlight was a very polarizing force and you either hated it as pure web developers did or loved it as pure Microsoft .NET developers did. At the time it was created, Silverlight was a (very) unique Microsoft property in that enabled .NET applications to run on a Macintosh. However, when the device revolution occurred, Apple disallowed plugins to run on their iOS devices (and browsers running on them), and Silverlight met a most confusing and mismanaged death. Technically, it is still supported today until 2021, but most Silverlight developers have moved on to other client models, while commonly regaling its power and elegance in various (and random) forum and blog posts.

Universal Windows Platform ^

The Universal Windows Platform (UWP) is the latest .NET client application model offering from Microsoft, and it can be considered a “complimentary replacement” to WPF. If you find that term confusing, then it has done its job. UWP (formerly known as Windows Runtime, or WinRT) was designed alongside WPF in a completely different runtime, and was intended to mimic (read: catch up to) Apple and Google by introducing a central application store, where UWP applications can be deployed to and installed by consumers.

Although technically .NET, UWP is designed around an exhaustive set of interfaces that ultimately lead to implementations developed in C++ and COM code. This has been called the “Curtain of COM” and has led to a very different development experience for .NET developers in the UWP environment. The Curtain of COM can be considered an application boundary in its own right. Errors thrown from the there are usually obscure at best, and when an event does arise from it, very little information can be derived from the call stack or other (usually helpful) debugging contexts, which in comparison to WPF and traditional .NET development are usually loaded with rich debugging information.

UWP has been out for several years now, but it still suffers from some serious drawbacks. In addition to the opaque Curtain of COM described above, UWP has a very limited Xaml system that hardly reflects the power of Xaml as seen in WPF or even Silverlight 5. Additionally, whereas much effort was made to make Xaml generalized and abstract in WPF and Silverlight 5, UWP reversed all efforts there by making Xaml a concern of the user interface again. The power of Xaml is in its serialization capability, and also in its markup extensions, both of which are absent in UWP Xaml. Because of this, we do not consider UWP to meet our requirements for a Xaml-powered client application model.

In addition to the dreaded Curtain of COM and a weak Xaml model, UWP does not enable the most fundamental .NET principles and design by way of language support. .NET was designed and intended to allow developers to design their applications in their most preferred language. UWP still does not support F#, which is really a tremendous and embarrassing failing for this group.

Despite these shortcomings, UWP does introduce the concept of a packaged application that is deployed to the Windows Store. This is a very powerful (and well-executed) concept in its ecosystem, as commerce can easily occur not only in sale of applications, but also within the applications it hosts as well. UWP provides the APIs to enable this new form of monetary exchange that was not and is not in WPF. However, even given this highlight, the choice was made to make UWP a Windows-only endeavor, foregoing the cross-platform capability and promise that Silverlight attempted to deliver. In summary, UWP has many challenges to overcome before being considered a candidate for a ubiquitous .NET client application model.

Xamarin.Forms ^

Xamarin.Forms is considered the new .NET client application on the block, and offers good promise to be a ubiquitous .NET client application model in the future. Created by Xamarin, an external company and now strategic partner of Microsoft, Xamarin.Forms offers a Xaml model that is (ironically) better designed and more powerful than UWP’s. Xamarin.Forms works on iOS, Droid, and Windows, fully possessing the quality for cross-platform compatibility.

However, even though Xamarin.Forms’ client application model is fully cross-platform, its client application model is an adaptive one. An adaptive client application model adapts to the hosting environment it executes on, and renders the user interface elements and subsequent user experience that is native to that host. Because of this, Xamarin.Forms does not have a consistent user experience across different devices on different platforms, and failing to meet our ubiquitous .NET client application model requirement for consistent user experience.

Additionally — and more unfortunate — Xamarin.Forms does not provide a HTML5-compliant offering, failing another important requirement in our list of desired qualites. Even so, Xamarin.Forms is still an impressive technology and Xamarin is even more so an impressive company and strategic partner to Microsoft. It says something when an external partner understands a technology (Xaml) better than the company that made it, as seen when comparing Xamarin’s Xaml model to the one found in UWP. There is definitely a feeling that this partnership could and should be leveraged in any endeavor to create a ubiquitous .NET client application model.

Avalonia ^

Avalonia is a new-comer to the game and is currently lighting up the field in spectacular fashion. It is just getting off the ground and is showing a lot of promise. Avalonia is currently running in alpha, and allows Xaml-based designer support and an inspector for your processed/loaded Xaml. It is also powered by a much needed cross-platform Xaml parser known as OmniXaml. Avalonia currently runs in *nix and Macintosh, but not in Droid or iOS (yet). However, they are currently exploring MonoGame support which would enable these scenarios. Avalonia does not currently offer a transpiled offering into JavaScript artifacts, so these scenarios are currently prohibitive and does not meet our requirement for HTML5-compliance. However, the group around this project seem very in-tune and capable, and we expect this project to go places.

Urho3D ^

Urho3D is a 3D gaming engine that has its own user interface subsystem, and was recently made available to .NET from the good folks at Xamarin. Like Xamarin.Forms, Urho3D enables .NET application development for iOS, Android, and Mac. Urho3D could be seen as a viable, recommended replacement for Monogame, or at least the official cross-platform 3D .NET application recommendation from Xamarin. We list Urho3D here rather than Monogame as it does have its own user interface subsystem, which makes it possible to define a client application model as such.

Unfortunately, Urho3D does not support Xaml (at the moment) and while it does have support for creating transpiled HTML5 output via its C++ offering, this is not possible via the .NET offering from Xamarin as it is based on the same technology toolchain as Xamarin.Forms. However, since it does have its own user interface subsystem, Urho3D does meet the consistent user interface and experience requirement that Xamarin.Forms does not.

x2h: Xaml-to-Html Translator ^

Have you ever seen the request on a forum post or blog comment that “someone should build a converter for Xaml to HTML output?” If you visit any of the MSDN forums, blogs or UserVoice boards, you have probably seen it a lot. Well, someone has done exactly that in xaml2html. It has just been released as a beta for developers to try out. As it is new it is very raw, but the working concept shows that it is possible to take a WPF project and output its contents and “translate” them into another form — HTML5-compliant artifacts, to be exact. Do note that this is more of a technology/project than an client application development model, but it is worth knowing about and to follow along with its progress to see how it evolves.

Azure PowerApps ^

Azure PowerApps is a product that is in preview, and holds some promise in the search of a ubiquitous client application model. It has cross platform capabilities, working on iOS, Droid, Windows Store, and the web. As promising as this sounds, its intended audience at moment is the non-professional developer, working on internal corporate line-of-business applications (think: next generation Excel macro-maker). This obviously prohibits professional .NET developers (at present) from developing consumer applications with this model, but it will be interesting to watch going forward if this does move towards this space. Considering that this is coming out of the Azure group, this product has every reason in the world to succeed and become a viable force in the marketplace. For more information on this exciting, emerging technology, check out Mike-EEE’s guest article on the MSDN Azure Development Blog.

Azure RemoteApp ^

Finally, we end our tour through native-hosted client application models with a technology from Azure, known as RemoteApp. To be sure, RemoteApp is more of a technology than a client application model — you can think of it as a client application model host. Using Remote Desktop technology, RemoteApp will take a Windows application installed on Azure and feed its rendering to a user’s remote device. That device can be a iOS, Droid, and of course a Windows device. Since it can be any Windows application, a developer could use WPF and have full access to its power and Xaml engine.

Currently, RemoteApp is meant for enterprise scenarios, and it would be interesting to see if there are plans to make it more for consumer-based scenarios. Additionally, while it only currently supports native-hosted applications, it would be interesting to see if RemoteApp could be used to pipe its renderings through a WebGL canvas on an HTML5 web page to fulfill our HTML5-Compliant Requirement.

While RemoteApp offers a lot of promise, there are some considerations. First, if this technology branched out to the consumer space, there is no telling how feasibly scalable it would be. RemoteApp is a remoting technology, so for each client application that is running, the instance that is running will actually be running on the server. At first glance, this does not seem like a feasible design that can scale well — or at the very least, cost effectively. Additionally, since this technology is dependent on Remote Desktop, that does imply that a live internet connection is required to use it, which means that if a user doesn’t have an internet connection, they can’t use an application used with this. Finally, because of the always-on connectivity requirement, there may be some intensive bandwidth considerations while a user is active with the application.

There are a lot of unknowns with this technology in regards to a ubiquitous .NET client application model, but there are enough intriguing elements here that we thought it merit listing here from an awareness perspective. There are definitely unique — and innovative — qualities to appreciate about this clever new offering from the Azure group, and they are worth learning and exploring.

Web-Hosted Client Application Models ^

All of the listed .NET client application models described so far have been “native” or “compiled” or “store-hosted” in nature. Now we start to move into client application models that run primarily in the context of a HTML5 runtime instance, or browser.

ASP.NET-Hosted (HTML5) Client Application ^

Our first model is actually a hybrid of these two contexts, and it is the model found in ASP.NET applications. This model is hosted and executed on the server in its own boundary, and can live in the same tier or different tier than the primary application services in which it communicates. When a page is requested and processed from the server, it is created by ASP.NET and ultimately emits HTML5 and JavaScript, and sends the results to the requesting client.

Here, we start to encounter and understand the challenges associated with web application client models. The emitted HTML5 and JavaScript in no way is connected with the .NET artifacts that execute on the server. Therefore, state that does not require server interaction must be maintained on the client through means of HTML5 element interaction and JavaScript. The use of this state (and application) management in JavaScript on the client, along with .NET on the server violates the requirement of cross-boundary capable artifacts. Additionally, the requirement for consistent development guidelines to define these objects is also violated as prescribed JavaScript naming conventions and guidelines are completely different from .NET’s. Finally, ASP.NET primarily describes its objects through a syntax known as Razor, and does not satisfy our requirement for a Xaml-driven description model.

Nonetheless, it is conceivably possible to think of ASP.NET in the near future as a possible cross-platform (albeit not ubiquitous) .NET client application model. That is, by hosting a ASP.NET server process in a Droid and/or iOS application process, ASP.NET could satisfy the cross-platform capability requirement by essentially running a server in a cross-platform context and serve up pages through a web-view control on the native device. More thoughts around this intriguing possibility can be found here.

HTML5 ^

The HTML5 client application model can currently be viewed as the oil to .NET’s water. In seemingly every aspect, from markup language to interpreted language, the HTML5 client application development experience is unlike any counterpart found in a .NET client application model. However, the HTML5 standard is an established, embraced, and popular standard since October 2014. By abiding and following this standard, it has accomplished a goal that .NET has failed to do to this day: ubiquity. Every HTML5 application written to its standard has a very high probability (minor differences do exist) that it will run and operate exactly the same no matter the browser or OS used to view the application. This not only satisfies our requirement for a consistent user experience, but makes HTML5 a truly ubiquitous client application model, and one in which we are basing our goal here for a ubiquitous .NET client application model.

An HTML5 application is written in HTML5-compliant HTML, and JavaScript as the interpreted language of choice. Both of these offerings are incompatible with .NET models and architecture. Because of this, there is no Xaml, or .NET, .NET Development Guidelines, or shared code between application boundaries. In fact, if you have a component written in .NET on the server, you must write its equivalent in JavaScript (or TypeScript) for the client.

Oil and water, indeed.

This is a very expensive and complicated problem, and it is any wonder why the Visual Studio team has inexplicably guided 16,000 voting users of Silverlight to build their applications using HTML5 instead, when doing so will incur twice the code since sharing code between client and server is no longer possible in an HTML5 client application model as it was in Silverlight. In a future post of this series, we will discuss this problem more at length.

CSHTML5 ^

From oil, back to life-giving water again. CSHTML5 is an amazing project that does not get enough consideration, exposure, or press it seems. It is based off a an even more amazing project known as JSIL.org. JSIL.org is a project that takes .NET code and transpiles it into HTML5 and web-standards artifacts. If this sounds like something an entire division at Microsoft should be dedicated to, rather than some wiz-kid out of California, then you are not alone. Here we have a project that accomplishes the seemingly impossible: reconciling the differences between a .NET client application model and an HTML5 client application model. CSHTML5 is based on JSIL.org and enables Xaml-defined and described applications to run in any HTML5-compliant browser. With this, you get .NET assemblies, guidelines, and consistency between client and server development.

Perfection, right?

Well, almost. As great as CSHTML5 is, it does currently suffer from some challenges that we have outlined here:

  • CSHTML5 is currently run by a smaller company and lacks the proper development resources for a truly revolutionary change. Again, we feel this is a problem space that an entire group within Microsoft should be dedicated to solving.
  • While it is possible to “share” code between client and server projects (through the use of linked files) in a CSHTML5 solution, you cannot share them in the way as you can in a traditional .NET solution, which is what is expected in our Cross-Boundary Accessibility requirement. Additionally, CSHTML5 does not support Portable Class Libraries at the moment, so that also does not satisfy this requirement.
  • Finally, with CSHTML5 it is possible (or will be possible), to host an application in a cross-platform native web control and gain cross-platform native capability, much like the same way that Cordova operates. This appears to meet our requirement for cross-platform native support. However, when we think of cross-platform capability, we mean to see our ubiquitous .NET client application model compile to the target platform’s native byte-code.
  • Performance is also a present consideration, as you would expect from a beta product.

With all of this said, in our view, CSHTML5 is at present the closest thing to a ubiquitous .NET client application model in the current marketplace. However, it does suffer from lack of momentum and resources, as well as key features to make it the perfect and recommended model. It is our wish to see Microsoft partner with CSHTML5/JSIL.org and incorporate this as an official technology in the Microsoft landscape, and leverage it towards building a ubiquitous .NET client application model.

WebSharper ^

WebSharper is a promising web-hosted client application model that features F#-to-JavaScript transpilation. IntelliFactory, the company behind this model, is hard at work making additional features that will be available soon in alpha releases, the most notable of these being C# support. WebSharper works by creating a model around the HTML5 DOM. It uses a templating system around HTML5 files, so Xaml is not utilized in any way. Code is written in F# (.NET) and which is ultimately injected into the HTML5 DOM where traditional JavaScript APIs such as Bootstrap and jQuery can take over and work with those elements. Additionally, you can use code between client and server, so that does appear to satisfy cross-boundary accessibility, at least for F#. We will have to wait for C# support to know for certain if it fully satisfies all use cases. For instance, Portable Class Library-support is not available yet but that is slated as a future feature.
As WebSharper doesn’t offer native-compiled support, or Xaml support, and works with the HTML5 DOM as its client model, it lacks all the requirements for what we are looking for in a ubiquitous .NET client application development model offering. Nonetheless, with all of its interesting current and planned features, it is one to keep an eye on as new versions are released.

DuoCo.de ^

Another JavaScript transpiler technology, DuoCo.de enables you to transpile your C#/VB.NET projects into HTML5-compliant artifacts. Duoco.de takes a more efficient transpilation route than JSIL in that it uses Roslyn to generate the JavaScript. However, the client model philosophy of DuoCo.de is different than CSHTML5. While it does provide the ability to transpile C#/VB.NET artifacts into JavaScript, DuoCo.de is designed to operate in the context of an HTML5 client application model. This means using HTML5 elements and markup to describe your application, rather than a Xaml-driven approach. This is an incongruous approach and one that does not align with our requirements or vision of a ubiquitous .NET client application model. Additionally, since Duoco.de transpiles via Roslyn, it only (currently) supports the languages that Roslyn supports, which at present is C# and VB.NET. This leaves other important languages like F# (even though every .NET language is important!) out of the realm of possibility to use with Duoco.de.

Bridge.NET ^

Like Duoco.de, Bridge.NET is another C#-to-JavaScript compiler that allows you to work in the HTML5 client application model paradigm.  They have built C# APIs around the major JavaScript-based equivalents and the expectation is to operate within the context of an HTML5 page, complete with DOM and related elements.  So Xaml is not a supported mechanism in this model as of today.  Bridge.NET is also similar to Duoco.de in that it is tied into Roslyn for all of its magic.  However, unlike Duoco.de, Bridge.NET is open-source and appears to have a healthy community around it.  Like all the other .NET-to-JavaScript transpilers in the present market, Bridge.NET does not enable portable class library support at the moment, so the holy grail of Cross-Boundary Accessibility remains illusive.   All said, I will say that of all the products in this area that I have seen to date, Bridge.NET looks the most professional and promising.  It will be interesting to watch their progress (closely!) to see if they manage to get PCL support, and maybe leverage their great professional look to even partnership with Microsoft to help enable integration with its new cross-platform initiatives.

 Fayde ^

Finally, we wanted to mention Fayde, another creative client application model that has gotten some acclaim. Fayde does have some strong Silverlight-based roots, is Xaml-driven, and bases its outputs in performant web-based artifacts. While Fayde is Xaml-driven, its code is expected to be developed in TypeScript/JavaScript. This breaks our requirement for a cross-boundary accessibility.

Summary Matrix ^

To summarize all models with the desired qualities, we have created the following grid to cross-reference all known client application models with our desired qualities for a ubiquitous .NET client application development model.

Capability Matrix for .NET Client Application Models

 
Native Cross-Platform Capable
HTML5-Compliant
Consistent UX
Cross-Boundary Accessibility
XAML-Powered
Object Serialization Congruence
Holistic Development Consistency
Windows Forms
Windows Presentation Foundation
Silverlight
Universal Windows Platform
Xamarin.Forms
Perspex
Urho3D
xaml2html
Azure PowerApps
Azure RemoteApp
ASP.NET-Hosted (HTML5) Client Application
HTML5
CSHTML5
WebSharper
Duoco.de
Bridge.NET
Fayde

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<< Ubiquitous QualitiesThe Broken, Burned Bridge >>
  • John Tasler

    Technically, UWP does support XAML, albeit an immature feature set.

    • Thank you for your comment, John. It is the first one for this blog. 🙂 And yes, UWP does have a Xaml system, but it is much inferior to the minimal/desired Xaml system of WPF and Silverlight 5. Even Silverlight 4 would be insufficient. The requirements and this post as been updated to reflect this.

  • georgebirbilis

    Mobilize.net that made the WindowsPhone8 Silverlight to UWP Bridge that Microsoft promotes has some more technology for porting XAML-based apps to HTML5 etc. from what I remember

  • Scott W

    Thanks for summaries on these technologies and overall a very good series of posts. You might want to add WASM and Unity. Also there could be a place in here (the series, not necessarily this post) somewhere to talk about deployment. Specifically the immediate nature of web (HTML or Silverlight) versus UWP+Store approach.

    • Appreciate the feedback, Scott! Deployment is indeed important. There is still the big task of caching data/assemblies/artifacts from WebAssembly so that clients should only download something once. This of course was handled in Silverlight but I digress. 😀 Unity is definitely a viable model, especially since it is a ubiquitous model. My problem with it is that its approach is unlike anything in .NET and in fact violates a few design principles in its implementation. It is very “un-.NET” and from the last I checked it only supported .NET 3.5. WebAssembly is very key now. I should definitely add an entry here as it is basically what everyone is talking about to bring .NET back into the browser. Miguel de Icaza actually spoke about it recently here: https://www.reddit.com/r/programmerchat/comments/4dxpcp/i_am_miguel_de_icaza_i_started_xamarin_mono_gnome/d1v9xyd And there are some good links in the comments of the vote this site was built to promote here: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

      Admittedly, since that vote has been marked as “Under Review” my focus on this site has waned a bit. The hardest part of getting MSFT’s attention around this important issue is done, now it’s a matter of getting them to build it. 🙂 Anyways, I will keep this in mind in case I do find myself adding more content here — which BTW has turned into WAYYYYYY more than I anticipated! LOL! Thanks again for your feedback and for visiting!

      • Scott W

        Yes, agree WebAssembly looks promising at least as far as writing c# and having it run in the browser is concerned. There’s still the XAML piece, so I wonder how something like Fayde would integrate if it all. Also whatever XAML->HTML process is used, the third party vendors like Telerik etc,need to get on board to get decent LOB controls. Although once C#/XAML -> WebAssembly/HTML is running, maybe a port of their existing SIlverlight controls is on the cards.

        • Oh, yeah… lots of questions like these. 🙂 Xaml should still be a compiled resource, so ultimately it will be a serialized object that gets emitted as instructions and stored somewhere. w/ WASM it will be like its own runtime/VM that can house any sort of code. I am not sure of all the particulars just yet, as the important part to me is that MSFT (and now Xamarin from the sounds of it) have their eyes and minds on this and it ist just a matter of time before a solution is made. I’m giving it another 2 years? That sounds/feels about right to me. That means we will have .NET on iOS/Droid/Windows (as we do right now via Xamarin) AND web. Life will be pretty sweet — unless another disruptive tech emerges to displace it all again, that is. Haha… wouldn’t THAT suck. 😛