The State of .NET GUI Frameworks

The State of .NET GUI Frameworks
   GUI development in C# has fallen to the sidelines in recent years. The main reason is the rise of mobile platforms and the fact that traditional C# GUI tools focus on Windows. That being said in 2018 we see a resurgence in interest in .NET based GUI frameworks. The most interesting are in experimental stage but the sheer amount of interest and the reaction from the community makes me believe that at least one of them will make it to production-ready state and will see significant use in the industry. For completeness I will list older frameworks. Note that I only have experience with Win Forms, WPF and UWP so the information on the other frameworks may not be correct. In addition the experimental frameworks will probably see significant development in the coming months and some of them may even stop development so if you are from the future make sure you look for the current status of each project. BTW do we have flying cars yet? Did Web Assembly make it?

Traditional Desktop


   The traditional .NET frameworks are the ones created in the time when Windows reigned supreme. They are mature and maintained to keep up with new Windows features but do not expect much in terms of new features.

Windows Forms – The original GUI framework for .NET. It is extremely easy to use and has the best GUI designer in history. To achieve these Win Forms sacrifices responsive UI paradigms. The UI does not reflow when the app is resized and concepts like docking require quite a bit of effort.  While it is Windows-only in general with some care it works with Mono on Linux and Mac. Win Forms is still my preferred framework when developing internal tools that need GUI. It is also great for teaching as it is almost pure OOP. Every control is defined as a .NET class and the designer tool generates actual C# which you can show to students.

Win Forms
The Win Forms Designer

Windows Presentation Foundation (WPF) - Released in the mid 2000s it was designed to replace Win Forms. WPF is the heavy artillery. It is full of concepts, supports powerful responsive UI but has quite steep learning curve. The WPF UI is defined in XAML and while a GUI designer exists most people find it easier to write XAML by hand and use the designer as a preview. Visual Studio is written in WPF. To be fair I do not see the use case for WPF these days. It can be used for GUI-heavy Windows-only apps but I do not see a lot of new software of this kind. You cannot expect WPF to work on other operating systems and because of how hard it relies on DirectX and other Windows-only tech chances that it will ever be ported are slim.

WPF
The WPF Designer

   Both Win Forms and WPF will be supported in .NET Core 3.0 as Windows-only packages. While that won't make them cross-platform it will bring some development goodness to these frameworks. For example you will be able to package the app with the required framework version so no .NET Framework installation will be required.

Mobile-Friendly


   Frameworks in this category are production-ready, widely used and officially supported by Microsoft. They focus mainly on mobile with controls suitable for different screen sizes and touch.

The Universal Windows Platform (UWP) - UWP apps are what Microsoft pushes as the future of Windows UI for a couple of years now. UWP GUI is written in XAML and steps on the shoulders of WPF and Silverlight (RIP sweet prince). UWP apps can work without changes on Windows 10, Windows 10 Mobile (if you can find one), Xbox and HoloLens provided that they do not require exclusive platform features like phone calls. The layout controls that come with UWP are prepared to scale on all these form factors and to accept input with touch, mouse, controller and even by hovering your finger in the air on the HoloLens. It would be great if the current Microsoft CEO did not sideline Microsoft's client platform by killing the phone, the Kinect and a bunch of client-focused services. As a result the demand for UWP apps is practically 0.

Xamarin - Xamarin allows developers to create GUI with the native tools for iOS and Android but write the code driving the UI and the logic of the app in C#. Since Microsoft aquired Xamarin (the company) Xamarin (the framework) has been free. Xamarin provides a library called Xamarin Forms that can be used to create cross-platform UI (the library also supports UWP). I personally have not used Xamarin but the opinion of the people who have vary wildly from "this is so buggy that it is basically unusable" to "it works like a charm, no problems at all". I guess it depends on the kind of UI you are building. Xamarin also supports building apps for Mac OS and publishing in the Mac App Store. Xamarin Forms uses its own subset of XAML and non-Forms UI is done with the platform's native tools.

Upcoming Desktop


Avalonia - Avalonia aims to provide a cross-platform alternative to WPF which sits on top of .NET Core (or Mono). It is a community-driven fully open-source effort. It seems that the idea is that Avalonia will be a desktop-first framework although they do have experimental support for iOS and Android. While I haven't experimented with Avalonia looking at their documentation it seems that some aspects are simplified compared to WPF which is a good thing. Avalonia does not aim for any compatibility with WPF so do not expect to just copy/paste the code of your WPF application. Their current status is beta and according to their documentation they are quite feature rich already. If the team keeps up the good work it has a good chance to become the de facto desktop framework for C# similar to how qt is the de facto desktop framework for C++. In an ideal world Avalonia will be able to challenge the Electron plague that is ravaging desktop application development. I have my fingers crossed.

Upcoming Mobile-Friendly


Uno Platform (Uno) - Uno aims to bring UWP to iOS and Android. The platform provides the APIs and XAML support for UWP apps on top of the Xamarin platform. In addition they can translate to Web Assembly and run in the browser. Their browser demo is slow to load but once it does it works with reasonable speed. You can live edit XAML and see the result on the side. Their main goal is Android and iOS and the Web Assembly work seems to be more of a future thing. Uno is probably the most ambitious project from the ones listed here as it aims for compatibility with UWP. If Uno is a success it can turn UWP into a success. I am a bit sceptical about the result and if this thing works at all I expect the same reactions that people have to Xamarin ranging from "it is great" to "it is a total crap". Uno advertizes Windows First development approach where you basically develop and debug an UWP with all the goodness Microsoft provides like edit & continue and then you can check how it works on iOS and Android. To use platform specific features or implement platform specific UI Uno goes for the shared project model where you have one project for each target platform and a shared project which all of them use. This is the same scheme that was used to share code between Windows Phone 8 and Windows 8 back in the WinRT days and I think it was quite good. If I find some time I intend to port BF for WP to UWP and then use Uno to port to iOS and Android. If that works I will try porting SC2 Master. If only I had all that time...

Platform Uno Architecture
Uno Architecture

Upcoming Web


Bridge.NET - Bridge.NET is essentially a C# to JS compiler. It levereges Roslyn goodness to provide a quality compiler. They use TypeScript definition files to provide type information for JS libraries for their compiler. I personally am not a big fan of the compile to JS approach but it is probably the best way to do web in C# today. I assume that integrating existing JS libraries with this project will be easier than integrating it with the other projects. The people behind Bridge.NET have put a lot of effort into porting a good portion of the .NET framework so you can use the standard library you know and love. If you go with the Bridge.NET route your UI languages will be HTML and CSS

CSHTML5 (C#/XAML for HTML5) - CSHTML5 allows you to compile XAML and C# to HTML5 and JS. As far as I know it uses JSIL to compile IL code to JavaScript (in contrast with Bridge.NET which generates JS directly from C#). It also provides an implementation of XAML to HTML. It seems like this project is best suited for porting existing WPF and Silverlight solutions to a more portable web. My reservations for projects which compile to JS still stand.

Blazor - Blazor aims to provide the ability to program for the browser using C# insted of JS. Unlike Bridge.NET it does not compile C# to JS but uses a pipeline based on Mono to compile C# to web assembly which will supposedly result in less leaky abstractions and better performance. Microsoft are funding the development but are very cautious and call it an "experiment". This project seems to have most traction with the community compared to all the other upcoming projects. With Blazor your UI languages are HTML and CSS but it comes with its own React-like framework which uses Razor as a templating language. In addition to full client side rendering Blazor supports a form of server side rendering where snippets of HTML are sent over a web socket to the client. This can be very useful for Electron applications running in tandem with .NET Core because there will be no latency between the client and the server and you can use actual .NET Core for your logic and use the web tooling only for rendering. I hope in the future they add real server-side rendering which allows the server to ship HTML for the initial page load - a method used by the SSR tools for React, Angular and Vue. This will allow C# devs to do real, full-stack C#. The interoperability with JS libraries is somewhat more complex than the one provided by Bridge.NET and CSHTML5 but is still quite reasonable and doable. In my opinion from all the up and comping projects Blazor has the best chance of success because Microsoft are behind it, and it has impressive traction with the community. In addition it is less ambitious than projects aiming to bring XAML to non-Windows platforms which means that it will encounter less technical problems. If I manage to find the time I intend to port this website to Blazor. This time I will pay someone to do a proper design/CSS I promise.

Frogui - Frogui compiles C# code to Web Assembly using the same Mono-based pipeline which Blazor and Uno (when targeting web assembly) use but it aims to provide its own set of UI controls and render them to HTML and SVG. The UI language is supposed to be C# used as a form of DSL with a proper API for constructing the UI. A GUI designer which will work similar to Win Forms is also on the roadmap but the controls and layouts will be inspired by WPF. This project is in earlier stages of development compared to others mentioned here and is quite ambitious which makes me a bit skeptical. I will certainly be happy to see a UI declared in C# but designing a good API for that is not an easy task and even if it is done there is still the rendering to the underlying HTML that must be done properly and with minimum abstraction leaks. In theory starting clean (no XAML, no Razor, no JS) may provide the best results but there is a massive work required to make this a shipping product.

Honorable Mention - Script#


   The first project to attempt compiling C# to JS and used in production was Script#. I think it is currently abandoned but at one point was used in large projects like Outlook.com Today you should most probably use Bridge.NET to achieve the same goals but Script# was built in the times before Roslyn so it is in a way a more impressive achievement. It shows that the desire of C# devs to avoid writing JavaScript and the lengths they will go to achieve it is at least a decade old. As far as I know Script# was a single person effort and was quite leaky in its abstractions but still many people adopted it because they think JavaScript is so bad that the sacrifices were worth it.

Update 20.08.2018


   Since I published the article people have pointed out about some projects I have missed

GTK# - GTK# is a set of bindings for the popular GTK+ UI framework for .NET. For some reason I thought this very old project was on its way out but it seems like it is in a very healthy state. It comes with an XML-based design tooling called Glade#. In my opinion Glade's XML looks worse than other options for layout languages. GTK# was used and is still used for the tools in Mono including MonoDevelop/Visual Studio for Mac. I wonder why this solution is not more popular. GTK# is definitely a desktop framework and mobile does not seem to be a goal.

Qml.Net - Qml.Net enables .NET developers to use Qt GUI library in their .NET projects together with its QML UI language. QML looks nice but it includes some minor use of JavaScript. The documentation mentions the use of V8, Chrome's JavaScript engine, which makes me feel uneasy. I somehow do not think I should be bringing a JavaScript engine in my app just to draw UI. From the GitHub page I fail to understand if Qml.Net supports anything but desktop development right now.

Eto.Forms - Eto is very odd UI framework which I fail to understand completely It seems that Eto controls are in fact wrappers of WPF, GTK#, Win Forms controls. This allows you to build somewhat portable UI by using your Eto UI in different apps. There does not seem to be a designer tool and controls are defined in code. The project seems more mature than Qml.Net, Uno, Frogui and Blazor but Eto's iOS and Android versions are still not ready.

Conclusion


   There is definitely an increasing interest in modernizing C# front-end development which means that the desire to write GUI in C# instead of JS is definitely there. With so many projects out there we can expect that at least one will become a significant success and accumulate the needed support from large companies and community know-how. Web Assembly in particular will give rise to many non-JS frameworks targetting the browser and it is good to see that the C# community is on the forefront of these efforts. I guess our disdain for JavaScript is the strongest.
Tags:   english programming 
Last edited by:   Stilgar
on   13:24 20.08.2018
Posted by:   Stilgar
21:55 19.08.2018

Comments:

First Previous 1 Next Last 

Posted by   Guest (Unregistered)   on   09:14 20.08.2018

Posted by   Guest (Unregistered)   on   12:07 20.08.2018

Great to see a post like this. Really gives a nooby a great introduction to the world of c# in regards to desktop, mobile & web.

Posted by   Guest (Unregistered)   on   13:28 20.08.2018

and dont forget powerbuilder! https://www.appeon.com/

Posted by   tzachs (Unregistered)   on   15:39 20.08.2018

You also missed set, which is used in Visual Studio for mac, I believe: https://github.com/mono/xwt

Posted by   Guest (Unregistered)   on   16:04 20.08.2018

Posted by   Stilgar   on   17:35 20.08.2018

I'm getting overwhelmed :)

Posted by   Guest (Unregistered)   on   00:40 21.08.2018

But, but ... the javascript fatigue.

Posted by   Guest (Unregistered)   on   12:24 03.09.2018

I left the Microsoft stack 9 years ago. This article tells me i made the right decision. This is a shit show

Posted by   Guest (Unregistered)   on   16:49 24.01.2019

Please take a look at WiseJ https://wisej.com/
This is a comprehensive, mature and fully supported re-implementation of WinForms to web. I am using it for my newly developed corporate apps, and cannot be more satisfied.

Posted by   Pablo (Unregistered)   on   23:25 27.04.2019

What's "odd" about Eto? It's the most straightforward library of all of them, very easy to use. Like Avalonia but without requiring you to learn XAML.

Posted by   Stilgar   on   16:43 06.05.2019

The lack of declarative UI language coupled with the fact that I have never seen anything wrap WPF makes it odd to me. Not saying it is bad or anything.

Posted by   Guest (Unregistered)   on   21:23 18.07.2019

What's wrong at home with that user supporting WiseJ?
I work in a Company which uses WiseJ for web applications, it is such a crap...

Man, you wrote this in 2019... if you run a web development company using wise, reconsider not making suffer your developers... WiseJ doesn't even have basic web development features, and if you make it through all those layer to work properly, you still remain frustrated.

Please man, make your devs a favour...

Posted by   Guest (Unregistered)   on   16:54 28.08.2019

We use Wisej for an extremely large and complex business web application and we are extremely satisfied with the framework. We tried several times to rewrite the app using asp.net, then angular, then hired an external “web development” experienced company, it all failed. The app is simply too big for angular or aspnet. Those guys consider 50 forms a large app. We have 2,300 and 25,000 controls. Only Wisej can handle that!

Posted by   Guest (Unregistered)   on   16:58 24.06.2020

The user complaining about wisej is probably a troll.

Posted by   Guest (Unregistered)   on   14:07 18.01.2021

I couldn't agree more. WiseJ is simply so fabulous that nothing else I know comes even close. We modelled our app off the Responsive WebPages Demo of WiseJ and have our application built with WiseJ entirely supporting the MicroServices Model.

Now here's how we did it.

1) Used the Responsive WebPages Demo and then replaced the custom Navigation Bar in the demo with a more beautiful Navigation Bar from WiseJ, then chose ElegantIcons as its icon fonts.

2) Open the pages of our app in beautiful WebViews that instantly open up in tabs on the homepage (almost like an MDI app).

3) Open full pages from entirely different applications (including those of services running on Linux in iFrames docked to fill in tabs of the webview, such that you could click a menu item and we could open up Google.com and it opens up without any addressbars such that you could swear that Google.com is running from our webserver.

The memory footprint of WiseJ also is absolutely light. Better than Blazor IMHO. Delightsome.

- G, Nigeria

First Previous 1 Next Last 


Post as:



Post a comment: