If i understand: - your UI is written in QML. - you are using Asteroid to turn DDP protocol messages into JS events? - are you then reactively changing the QML markup and asking QT to re-render your UI? I'm interested how this part works.
How granular is the reactive rendering, ie the whole page every update, or just changed components (like reactjs DOM diffing)?
Have you dealt with other client side things like routing and page changes, or is it currently content for QML widgets?
How far does QML allow native widgets like tab controls? Does a QML app end up just as janky as html5?
Did you look at just having a QT application that would talk DDP? I guess QML looks like json/markup so it's more appealing for porting an existing meteor app, and it's markup rather than code, but some mapping to QT would presumably give much more control?
How do you deal with client side logic? If QML is just a layout descriptor markup, if you need actual logic client side, how do you bridge between that and the meteor backend? I see Asteroid allows you to send data back and call Meteor.methods. Oh I see QML actually anticipates modules in JS: http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-e... http://doc.qt.io/qt-5/qtqml-modules-topic.html
Does QML support a webview component? In which case you could also mix in some pages just as webviews if you didn't want to rewrite your whole app in QML? Then again only attractive if the QT webview component uses latest chrome renderer at an OS level, and no JS bridge was required back to your app... that would be like a turducken anti-pattern.
Overall very interesting, thanks for sharing!