View source for QML: General purpose language or frontend for QtQuick

I often encounter a sentiment to dismiss QML as simply some hack to make QtQuick happen. The proponents of such sentiment often transfer all the love or hate they may have towards QtQuick into QML. This has wide ranging implications, for example when trying to establish support API in QtCore or similar foundational libraries. Why do we have to expose metatypes.json files for libraries that don't tie into QtQuick after all? Why should we annotate our value types with Q_GADGET? Etc. 

- Maybe create widget UIs with QML? Native Android? ...
- Why not use C++?
  - QML is easy to learn
  - Is compilation good or bad?
  - Easy scriptable
- Why not Lua, Python, bf, ...
- Applications that successfully use QML
- People love JS. Ulf hates it

- constructor arguments exposed to QML?
  - use required properties for that?
- continuation functions
- better solution to Component.onCompleted
  - common pattern: flag for "completed"

How do we get 10M more developers for QML
- By making it fast (compiled) and flexible (JS-like)
- has to work without Qt

Where is QML better than competitors? Why should I use it?
- easy way to create object hierarchies
- bindings

All of JS or only subset?
- make full JS optional, separate library
- decouple declarative syntax from scripting

Ecosystem, tooling, package management?