I have been a full time enterprise .NET developer since Microsoft released the beta version of .NET in 2001. By the time WPF and XAML came around in 2006 I was freelance developer in the investment banking industry, building high-performance desktop software in .NET WinForms . I immediately saw the potential in WPF and made it my speciality there and then, and for the last 12 years I have become a battle-hardened WPF/XAML pro, having worked for over 11 investment banks — building, writing and debugging crazy-complex trading platforms.
I’ve done everything — literally everything — from coding up high-performance custom controls that run directly on the render thread (no dispatchers or XAML there), to taking crash dumps from traders production machines in order to investigate multi-threaded deadlocks — been there — done that many, many times.
So, its 2018 and WPF/WinForms is now a legacy platform.
I don’t remember the WPF technology stack getting any significant updates over the last 12 years, so it dies pretty much how it started. Its apparent replacement is the so-called ‘Universal Windows Platform’ or UWP (previously it was ‘WinRT’ — no ‘Store’ — no ‘Metro’ no……??), however there is one huge and massive issue with UWP on the desktop, and that is it isn’t designed for the desktop.
Nonsense!, you might say — but Its true. UWP will never been an enterprise desktop software development technology stack, and I will tell you exactly why in the next paragraphs.
The ‘Mobile First’ Fallacy
The Enterprise doesn’t care about mobile — it really doesn’t. Sure there are a small number of enterprises that need delivery guys with handheld devices , and those devices need to have mobile software written for them, but they are in a tiny minority.
The few mobile enterprise apps currently out there are more about productivity triage — a quick glance while you’re getting a latte — nothing more.
Your email app on your iPhone isn’t designed for you to use 8 hours straight at your desk. The spreadsheet app on your iPad is pretty useless for a whole day’s work. You NEED a big screen with mouse and keyboard to do an 8 hour shift on the company’s CMS system, and no mobile-first setup is going to be even remotely productive for 99% of enterprise employees.
However, UWP is a mobile-first platform. Its designed for small devices that are being used by people touching a screen with sausage-shaped fingers. Yes you can have the app adapt to different screen sizes but its still the same issue — powerless and simplified, with low levels of information density — if that’s all you needed, then you’re going to build a web app instead anyway.
The ‘I Want To Touch My Screen’ Bias
Enterprise users are not going to spend 8 hours at their desk stroking their laptop’s screen (assuming they even have laptops). Why would you? A mouse and keyboard are 100 times more effective, and 100 times less likely to give you a repetitive strain injury.
Sure, if you get to take the laptop home you can use it to play films, and finger through the boring stuff with your pinkie — I get it, but enterprises do not buy their employees touchscreen laptops, unless there’s a really niche requirement — which is very rare.
So why then is UWP optimised for touch? What’s all this inking lark?
Yes, drawing on your computer screen has been around for decades and it never caught on — for very obvious reasons.
However, because touch is front and centre in the UWP platform philosophy, we cannot take advantage of the super-accurate mouse and keyboard input devices that have been so amazing for so long. Information density is very low in a UWP app, which is a massive no-no in enterprise desktop software development.
As an example, Adobe have just release a design tool called XD that’s a UWP app. Compare its usability with its main (proper desktop) rivals like Photoshop and Sketch. The comparison is startling. XD feels like a small mobile app with limited capability, and it’s because that’s exactly what it really is.
The Information Density Conundrum
Information density is a massive requirement for complex desktop apps in the enterprise. If your app is simple, with not much going on then its gonna be better being a web app, so if you say you need full-fat desktop apps then you know you need power and high levels of information density.
I’ve worked with banking traders building single apps that span 6 x 21 inch monitors, and every single pixel has a purpose — one time, they even wanted the grid headers hidden to allow for more rows, because they could remember which column was which anyway and the extra 4×80 millimetre space was worth the sacrifice. I know this is an extreme example, but the standard UWP control templates have massive amounts of space around all of the interesting bits.
You could re-template the entire suite of UWP controls to improve information density, but that is a huge undertaking, and I can tell you from experience that there are a lot of assumptions hard-wired into the UI/UX Microsoft built that would make that task pretty much impossible.
Without decent information density, enterprise developers are going to have to stick to WPF — and hope that Microsoft doesn’t ‘Silverlight’ it — i.e. throw it in the dumpster while no-one was paying attention.
The ‘UWP Runs Close To The Metal’ Flaw
One of the differences between WPF and UWP is how the application is built and run.
WPF is compiled down to MSIL (intermediate language) and BAML (optimised XML for markup). When a WPF ‘compiled’ build is run, it gets transformed ‘just in time’ into executable code by a runtime application (the CLR) which after 20 years has become a hardened bullet-proof abstraction layer for the WPF application to sit on top of.
When things blow-up in WPF land, they do so in an orderly fashion, with plenty of opportunities for the developer to inject they favourite debugger into the meltdown and have a meaningful opportunity to work out what’s broke.
UWP however is compiled down to machine-executable code as part of a COM package, with a dressing of metadata information to support development tools. When a UWP app runs, it runs super-optimised and close to the metal — YAY!
Sounds like a good thing doesn’t it? Well it is if your job is to just lash an application together. However, when it comes to debug time you are going to be in a whole world of pain. Forget the fact that any minor piece of incorrect coding can randomly crash an app entirely, there is very little opportunity to see what’s failing in your beautiful user interface.
Stick a breakpoint in the dependency property metadata callback method and all you get is an unintelligible COM error code. No stacktrace, no human-readable clue as to what went wrong.
This may not be a problem when you’re building an app — just keep tweaking things until it works, but supporting production apps being used by real (and important users), make this situation an unacceptable nightmare.
The ‘You Only Need Web Apps’ Fake News
Web apps don’t cut it. They don’t cut it as replacements for serious desktop apps. Over the last 20 years, all desktop apps that could have become web apps have been migrated already — they weren’t supposed to be desktop apps in the first place, but until ASP.Net became the go-to technology for mediocre apps — desktop apps were the only choice.
Almost all desktop apps that remain are still desktop apps for a reason. I know frameworks like React and VueJs are knocking on the door, but those web technologies can only cannibalise the existing web application universe.
So we have progressive web apps now — So What! Progressive web apps are a great technology but they have no impact in desktop world.
BUT, we here that progressive web apps (or PWA’s) are going to revive Microsoft’s fortunes. Really?
The Answer (Maybe)
There have been rumours that Microsoft are going to be switching focus back to their roots — desktop application software development — Thank F**K For That!
It makes total sense. They have abandoned mobile, tablet use in on the decline and desktop is where Microsoft will always be strong.
Apple don’t sell laptops (or desktops) to the enterprise. They are too expensive, and buying managers don’t care how sexy the employee’s computers are, they would buy a laptop that looked like a toaster if it was cheaper. The desktop technology of choice in the enterprise will always be Windows — there simply isn’t any alternative — and that’s how it will be for the foreseeable future.
Microsoft must switch their flagship technology stack from UWP to WDP — from ‘Universal Windows Platform’ to ‘Windows Desktop Platform’, and these are the things that Microsoft need to do to make this happen.
Take the existing WPF technology stack and make it run close to the metal , but WITH sensational stability and debugging support
Port all of the good bits of UWP over to the new desktop stack so that we have the best of both worlds (c’mon Microsoft — after 12 years this stuff should already be in WPF!)
Re-skin the entire UWP control library and optimise it for good information density on desktop, making the mouse and keyboard the primary interface.
Improve the tooling so that we can have full hot-reloading on any aspect of desktop development. Have you seen the Google Fuchsia hot-reload demos? Us desktop developers want that — NOW! (and I’m not talking about the half-baked ‘edit and continue’ for C# and XAML currently available in UWP).
Start making desktop development the focus — not ‘Mobile First — Cloud First’ but ‘Enterprise First — Desktop First’.
DO NOT kill WPF until it has a fabulous enterprise-first replacement.
If you do, all us faithful Microsoft developers will become React or Angular developers and Desktop development will no longer exist.
Us hard-core, seasoned desktop developers remember the good old days. We know our customers want us to build incredible desktop experiences that absolutely maximise the productivity of their large and diverse employee base. We know that enterprises are not interested in mobile, nor are they interested in touch screen technology. Web apps have been done where required, and PWA’s aren’t on any enterprise roadmap. As for HoloLens and Xbox — please, don’t make me laugh.
Desktop software is at the very heart of Microsoft’s success, and always will be. However, if us jaded developers don’t get the tools and frameworks we need, then its game-over Microsoft — it really is.
If you want to connect with me on LinkedIn, my profile is here