> Qt is big and complicated.

I'd encourage every developer considering Electron to give Qt/QML a try. It merges the declarative nature of WPF with a nicer syntax and the ability to use JS directly in the QML file, obliterating the need for converters of formatters (that plague XAML/WPF and JavaFX). Writing custom components is trivial and intuitive, with zero syntactic overhead (if a QML file "MyCompX" is present, you can instantiate its contents with "MyCompX" without any additional setup).

For Android, it has the advantage of being able to hot-reload the UI without jumping through hoops (simply serve them over HTTP and install a small reload handler in your app that can be triggered either from the app of by something like a UDP message from the host). (Change one like in the app's main and you are able to pull the QML files from a local directory so you can modify them on the tablet without a PC or internet connection ...)

I'm actually reluctant to mention Qt/QML because I consider it to be my secret magic silver bullet for portable (non-web) UI development.

Regarding the license (there's a lot of misinformation, including Qt's main site trying to coerce you into using the commercial license): if you link dynamically, commercial usage is not a problem (LGPL). (This is usually only an issue on iOS.)

The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API: offering a version that only exposes the QML editor and interface generator, and ships qmlscene as execution runtime and an option to deploy the QML-only application with a rebranded qmlscene (embedding the QML resources and a custom icon). To be clear: this all exists right now, but with the C++ part enabled (which will scare off some developers even if they can create applications without it).