Hacker News Reader

Comment by ahartmetz | Hacker News Reader

Except on Windows, where Qt looks more "standard" than whatever MSFT's current "standard" framework is this week, and on Linux, where GTK and Qt are the native frameworks. If you handle these with Qt and your budget is limited, you might want to handle more platforms with Qt.

View on HN

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.

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.

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

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.

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.

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.

Yeah, lack of native styling in QML sucks. Although, customizing Qt Quick components is SO easy and straightforward.

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.

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.

Reply on news.ycombinator.com