3 ms·

If your budget is limited you're better off using HTML. It's significantly cheaper and gives more consistent and less janky experience than QtQuick.

by marwis 3y ago

bigyikes 3y ago
This is how I’m developing my application with Rust. The UI is completely separated from the core of the app, and the core can be compiled natively or target Web Assembly. I’m building the UI with HTML and JS (by the way, Web Components feel way better than React) and running the whole app in the browser (via WASM). Eventually, I’d like to create native applications for all platforms, but I don’t have the time to spend on that right now. When the time comes, I’ll be able to easily remove the HTML frontend and bolt on a new one written specifically for the target platform. This lets me prioritize dev speed in the short term and native UX in the long term.
justinclift 3y ago
Whether or not that's true depends on the existing skill set of your developers. :)
ahartmetz 3y ago
QWidgets is the one to use if you want to blend in. Qt Quick is highly productive, but native styling is, AFAIK, not completely there yet. It's getting better, not sure how good it will get.
- marwis 3y ago
  The original article is about mobile development where AFAIK you're supposed to use QML. I don't know the state of QWidgets on iOS/Android but my guess is it's even worse than QML if at all possible.
  - ahartmetz 3y ago
    Right, QWidgets are not very suitable for mobile. QML is... very suitable for custom (especially touch) GUIs, native styling is WIP. Seems to be done with higher priority than desktop native styling.
    - rubymamis 3y ago
      Yeah, lack of native styling in QML sucks. Although, customizing Qt Quick components is SO easy and straightforward.
LtWorf 3y ago
From my work experience: it's not cheaper. Paying people to reimplement stuff that is already implemented and functioning, and then pay them to fix the bugs, and then pay them to make it accessible.
- ahartmetz 3y ago
  I once took part in a project where we created a QML based implementation of a previously Node.js based embedded app. Node.js took ten people two years, QML three people six months - and no callback hell. Lots of caveats though: I'm not sure how experienced the Node.js guys were - team QML was fairly experienced (and competent in general). JS GUI frameworks have improved a lot respectively become available in the first place. Recreating something is always easier than creating it the first time. We used the same backend parts that were probably co-developed with the Node.js frontend (but AFAIK not counted in the two years, ten people). We heard that the Node.js version had quite high velocity initially, but slowed down greatly when it came to polishing. Like more than half of the time spent on the last 5%. The QML version also ran more smoothly.

If your budget is limited you're better off using HTML. It's significantly cheaper and gives more consistent and less janky experience than QtQuick.

by marwis 3y ago

If your budget is limited you're better off using HTML. It's significantly cheaper and gives more consistent and less janky experience than QtQuick.

bigyikes 3y ago

This is how I’m developing my application with Rust. The UI is completely separated from the core of the app, and the core can be compiled natively or target Web Assembly. I’m building the UI with HTML and JS (by the way, Web Components feel way better than React) and running the whole app in the browser (via WASM). Eventually, I’d like to create native applications for all platforms, but I don’t have the time to spend on that right now. When the time comes, I’ll be able to easily remove the HTML frontend and bolt on a new one written specifically for the target platform. This lets me prioritize dev speed in the short term and native UX in the long term.

justinclift 3y ago

Whether or not that's true depends on the existing skill set of your developers. :)

ahartmetz 3y ago

QWidgets is the one to use if you want to blend in. Qt Quick is highly productive, but native styling is, AFAIK, not completely there yet. It's getting better, not sure how good it will get.

marwis 3y ago
The original article is about mobile development where AFAIK you're supposed to use QML. I don't know the state of QWidgets on iOS/Android but my guess is it's even worse than QML if at all possible.
- ahartmetz 3y ago
  Right, QWidgets are not very suitable for mobile. QML is... very suitable for custom (especially touch) GUIs, native styling is WIP. Seems to be done with higher priority than desktop native styling.
  - rubymamis 3y ago
    Yeah, lack of native styling in QML sucks. Although, customizing Qt Quick components is SO easy and straightforward.

LtWorf 3y ago

From my work experience: it's not cheaper. Paying people to reimplement stuff that is already implemented and functioning, and then pay them to fix the bugs, and then pay them to make it accessible.

ahartmetz 3y ago
I once took part in a project where we created a QML based implementation of a previously Node.js based embedded app. Node.js took ten people two years, QML three people six months - and no callback hell. Lots of caveats though: I'm not sure how experienced the Node.js guys were - team QML was fairly experienced (and competent in general). JS GUI frameworks have improved a lot respectively become available in the first place. Recreating something is always easier than creating it the first time. We used the same backend parts that were probably co-developed with the Node.js frontend (but AFAIK not counted in the two years, ten people). We heard that the Node.js version had quite high velocity initially, but slowed down greatly when it came to polishing. Like more than half of the time spent on the last 5%. The QML version also ran more smoothly.