[seanmcdirmid]

Back in 2009, using chromium instead of IE in WPF was the only way to do overlays (that wouldn’t burn air space) and effects efficiently. Since WPF has been stagnant for so long, I wonder if there still isn’t a better solution than using chrome.

[Const-me]

> if there still isn’t a better solution than using chrome.

A better solution is use WPF for the complete GUI.

Text & typography, raster and vector graphics are very compatible to HTML5. Effects, animations and templating are far superior. The only areas where HTML5 is winner are styling, maybe layout, and definitely the labor market i.e. it’s easier and cheaper to find a front-end developer than a WPF developer.

Also WPF is better integrated into Windows. Its easier to implement per-monitor DPI awareness (starting from .NET 4.6.2, released in 2016), easier to support accessibility (narrator & others), etc..

[m_fayer]

Believe it or not modern browsers are a clear winner when it comes to graphics performance. Sure WPF has a slick animation API that can do all sorts of things and a super-flexible "lookless controls" model, but the second you try to display a lot of data with anything fancier than plain text, you're in for a world of pain. Endless optimizing of visual trees and layouts, large data binding operations causing opaque and difficult to control UI-thread freezes that disable all your wait indicators, half-baked UI-virtualization support, it's not fun. What takes me days of fiddling to get to acceptable with WPF I can do with HTML5 and an easy to use battle-tested library in a few hours.

[Const-me]

Developed quite a lot of WPF apps but very rarely encountered performance issues you’re talking about.

> Endless optimizing of visual trees and layouts

Never did that.

> UI-thread freezes that disable all your wait indicators

I avoid doing lots of stuff in the UI thread. This is especially easy to do with modern .NET and async-await.

In addition, I design my wait indicators so they run on the composition thread, i.e. aren’t affected by the UI thread being stuck.

> half-baked UI-virtualization support

For me it usually works OK but I agree there’re probably some issues with this feature. I remember fixing problems when my code or markup did something that disabled the virtualization and ruined the performance. But it never took days, maybe a few hours.

P.S. The worst issues I’ve encountered with WPF wasn’t performance, it was stability. Once I’ve spent a lot of time debugging rare render thread crash. I still don’t know the reason but I’ve simplified my visuals a bit (namely, pre-multiplied a render transform with the complex vector shapes I was rendering) and the problem seems to gone for now. Another time it crashed when I opened a popup, and closed it too soon, like 10-20ms after the open. The popup was “loading, please wait…” progress bar so it only happened when opening very small files from very fast hard drives.

[mattkol]

Like you, I have developed quite a lot of WPPF apps and still do (my day job!). I completely agree with all the points you made. Especially the point on composite control handling it's own wait indicator is spot on.

However, I believe @m_fayer is right too. The performance issue can creep up on you if you are not constantly watching it.

The weak-reference used by DelegateCommand in most WPF framework implementations - Prism, MVVMLight, Caliburn.Micro can cause extra headaches if one is not watching it. I have seen memory clogs with InputBindings; I have seen unexplaiined performance issues with ColumnSpan, RowSpan usages, and others issues I can't remember at the moment.

Buttom line is one needs to take C/C++ mindset to WPF to achieve optimal performance - that is you may have to have a strategy to clean up after yourself (just like pointers) and not rely too much on Garbage Collector (GC).

[GordonS]

> The only areas where HTML5 is winner are styling, maybe layout, and definitely the labor market

You're missing a major feature - cross platform. WPF is Windows only.

As someone who has also built a few WPF apps (altho not for some years now), I absolutely hated working with XAML - the visual designer in Visual Studio was really buggy and brought any machine to it's knees. Doing things without the designer, hand cranking all that XML felt really clunky, and things like event handling and synchronisation were fiddly to get right.

HTML and CSS aren't perfect by a stretch, but at this point I think they're a great option for desktop UIs, especially if cross-platform is desirable (and I say this as a long in the tooth, Microsoft-stack focused architect).

[Const-me]

> You're missing a major feature - cross platform. WPF is Windows only.

You’re missing the context. The OP has created that Electron-like thing to embed into a windows-only WPF app.

> the visual designer in Visual Studio was really buggy

Expression blend was, and still is, much better. It’s not especially friendly towards programmers, initially I had to read quite a lot of documentation and articles. But now I use it a lot (albeit not exclusively) and enjoy doing so.

> things like event handling and synchronization were fiddly to get right.

For me, MVVM works in 90%. The trick is to recognize the 10% of things for which it doesn’t, and do something else like code behind, or programmatic visual tree manipulation/generation, or something else.

> I think they're a great option for desktop UIs

If that desktop UI is a thin interface between user and a web server/cloud, maybe. If that desktop UI actually does something locally, I don’t think HTML is a great option: shell integration, WinAPI interop (both need COM interop). Also JavaScript isn’t exceptionally good general-purpose programming language especially for medium to large projects, e.g. MS had to create a TypeScript on top of JS for their VS Code.

[GordonS]

> You’re missing the context. The OP has created that Electron-like thing to embed into a windows-only WPF app.

I didn't miss that, I was talking in a more general sense about HTML vs WPF.

> Expression blend was, and still is, much better.

I never did actually try this properly - I had a brief play with it years ago when it first came out, but it seemed like a toy; maybe I should give it a go now it's had time to mature.

> Also JavaScript isn’t exceptionally good general-purpose programming language

No arguments there, I'm a sense-confessed JS hater ;) Typescript however, is an absolute joy to use.

[jimmcslim]

> Expression blend was, and still is, much better.

I was thinking about Blend just the other day, and wondering if was still a thing?

[Const-me]

> if was still a thing?

Technically no, the expression was lost a few years ago.

But practically yes, the blend is still a thing. The latest version of visual studio 2017 comes with a corresponding version of it. It’s as useful for everything XAML as the expression one was in 2010 when I started using it.

[seanmcdirmid]

Doesn’t help if you need an embedded web browser control. Plenty of apps needed that, and IE has real air space and redraw issues to be used that way.