I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.
Or I could say the same about Qt's QML.
(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)