The State of the GUI

[Adam Wilson]

I was reading the hijacked JAXLondon thread about GUI's and started 
replying but decided against hijacking the already hijacked thread again.

I've been working with UX toolkits since the earliest days of my career 
and it was one of the first things I looked for when I started using D 
in 2011. Needless to say I wasn't impressed. As a result I've done some 
fairly extensive research over the years on, not just the effort 
required to bring one to D, but also on what people are actually using.

This discussion invariably falls into a firefight between two camps, 
native-widgets and non-native widgets. I know that this topic can bring 
out the rage-trolls so I want to state upfront that the native widget 
camp is the losing bet if we care about the future. Please allow me to 
explain.

At this point in time HTML/CSS/JS is by far the most prevalent UX 
toolkit in use today and not a single modern website uses the native 
widget theme. The bare minimum is Bootstrap.

In terms of the usage of publicly available software to sample the HTML 
stack is utilized more than all other stacks combined. Next up is mobile 
apps, but even here usage of the default theme is in the trivial 
minority, the vast majority of mobile apps use themes that closely match 
the websites they are derived from.

I think this is a key point. The theme itself is now part of a brand and 
using the native toolkit would be a branding disaster. American Express, 
Facebook, or Google aren't in the business of showcasing Microsoft's, 
GNOME's, or Apple's branding, they want their apps to showcase their own 
brands.

Somewhat unusually for Microsoft they recognized this shift in industry 
early and starting with WPF in 2006 they have allowed you to completely 
customize the look of widgets. WPF actually began as an (however 
misguided) attempt to improve on the UX capabilities of HTML/CSS. They 
continued this direction with Silverlight and most recently, UWP. UWP is 
intended as the long-term replacement for the Win32 UX API's and 
Microsoft is no longer developing the Win32 API's, it's just bug fixes now.

However, WPF suffers from it's own scope and Microsoft's inherent 
myopia. WPF is massive, over 30,000 classes, it's Windows only, and it 
can be agonizingly slow in certain usages. In theory it could be ported 
to other systems, but it's heavily tied into DirectX so it would be an 
enormous amount of work in practice. They addressed some of the problem 
with Silverlight which worked on OSX (but only in Safari) and cut down 
on the number of classes significantly. That said, Silverlight never 
caught on as a replacement for HTML/CSS and was unceremoniously canceled 
in 2011. Both projects were developed by DevDiv which meant that they 
had great tooling but did not necessarily utilize the OS level API's 
very well. UWP was developed by WinDiv as the next-generation UX API for 
Windows.

I've never used GTK or QT, but my understanding is that both have 
retrofitted some amount of theming into their toolkits but neither 
approach the capabilities of WPF or HTML/CSS.

There are other reasons that native toolkits died however. The first is 
data visualization. What can be expressed in 10 lines of WPF code would 
take anywhere from 100-1000 of Win32 code to depending on the 
visualization. Non-native toolkits allow UX designers to express the 
data using the most intuitive visualization for that data, without being 
constrained by the native widget toolkit, and often allow the designer 
to do so in a trivial fraction of the time. The amount of time required 
to implement the best visualizations can easily be cost-prohibitive.

The second is Electron. Electron is a terrible framework for a host of 
reasons. But the one thing that it achieved is the 
write-once-run-anywhere (WORA) desktop UX toolkit. If you use the native 
toolkit you are stuck writing a different interface for each toolkit. 
That again is cost prohibitive and indeed is a large part of the reason 
that Microsoft dominated the desktop in the 90's and 00's. Companies 
only wanted to build one UX so they built for the most common OS, which 
at the time was Windows. Now with Electron you can design a UX once, 
using all the HTML/CSS talent you already have an deliver to any 
platform that Electron supports. VS Code looks and functions identically 
on all three major platforms.

Another is that in my experience even native toolkits, such as DWT, that 
can be used to build cross-platform interfaces tend to produce mixed 
results. You run into a plethora of minor issues surrounding differing 
Fonts/Paddings/Margins etc. So even though the toolkit itself may be 
cross platform you still need to create three separate interfaces to 
iron out these small but noticeable details. Electron and non-native 
widgets solve these problems entirely.

Native toolkits are a dead-end. The future of non-Web UX is non-native.

So why doesn't D have ANY useful bindings UX library bindings?

The answer, I think, is that almost every case, the UX toolkit in 
question was designed for a specific language, Qt->C++, 
GTK/MacOS/Win32->C, SWT->Java, WPF->.NET, etc. and these toolkits are 
often deeply integrated with the languages they are implemented in.

And it is for this reason that I understand why the native toolkit camp 
pushes so hard for D to get a native widget toolkit. Somebody else has 
done the hard work of building a C API for a high-quality toolkit. The 
problem is that it's really a C+Preprocessor API. I maintain the only 
current bindings to DirectX for D and even I haven't ported most of the 
Macros. And Win32 is loaded with macros.

Then there is the fact that by definition, any UX toolkit requires an 
absolutely gargantuan number of interfaces to achieve the desired 
result. My DirectX interface is tiny compared to the Win32 UX 
interfaces, and it's something like 16000 lines of D code, without macros.

And none of this is even counting the tooling ecosystem that would be 
recreate from scratch. Qt has QML, WPF and UWP have different flavors of 
XAML. There are special pre-compilers. The list goes on. So when 
individual sets out to bind a UX toolkit they inevitably flame-out 
because the amount of effort required to get something simple working is 
enormous.

And that brings us to the final problem with UX in D. The amount of time 
it takes to bring any UX toolkit into D is

Just before it's release Tim Sneath published a list of MSFT developers 
who were actively blogging about WPF. There are 19, and I strongly doubt 
that is everyone. But it would be fair to say that it took at least 20 
people 5 years to develop WPF (2001-2006). WPF had MSFT, Qt had 
Trolltech/Nokia/etc. Gnome has RedHat and more. Electron had GitHub.

The underlying theme here is that it takes an enormous pile of resources 
to make a good UX toolkit. D has never had the kind of corporate backing 
that the other toolkits have. So it should come as no surprise that 
large scale projects, like UX have been unattainable to date.

The D community, for all it's wonderful attributes does not have a 
"team" mindset. And this bears out if you audit code.dlang.org. The 
projects are universally the herculean efforts of one person, and 
occasionally a small number of secondary contributors.

The way I see it. We either pull together around a unified vision for a 
UX toolkit written in D from the ground-up or we wait (im)patiently for 
a benevolent corporate benefactor to appear. It's that simple.

I do have a vision for a non-native, WPF-like, UX toolkit written 
entirely in D. I estimate that it will take a minimum of three extremely 
dedicated, multi-disciplinary, individuals about three to five years to 
complete with the help of a constellation of secondary contributors. I 
have a rough design sketched out and I'd be happy to post it here but 
this message is already getting to long.

This isn't the first time I've asked for help. And to be perfectly 
honest, I expect the same crickets response I've gotten before, but if 
you are interested and willing to dedicate yourself. Please let me know.

I firmly believe that a non-native, cross-platform, UX library will open 
D up to a whole new market of users that are desperate for something 
better than what they have now.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;