Hacker News Reader

Comment by stephendause | Hacker News Reader

Cool! Do you have any Web programming experience? If so, how would you compare/contrast the experience coding in Qt vs. JavaScript? I have ~1-2 years of experience programming in each, and I tend to prefer Qt because to me, it seems easier to make components that are truly reusable. On the other hand, there are numerous advantages to Web programming, such as the fact that it's easier to deliver content and it's ubiquitous.

View on HN

Thanks! I come from the embedded world and my preferred language is C - hence the need for a calculator that can wield bits like this. I wrote this tool around 4 years ago and it was my first attempt at creating anything that wasn't a CLI tool or bare-metal firmware. In other words, I can't really compare this experience to anything!

I guess the reason I chose Qt over any web-based frameworks is I wanted a standalone app that would launch in a fraction of a second and just do its job. I don't think a webapp (if that's what they're called) would give me that. At the time, it seemed that Qt would work well and, as a bonus, be cross-platform. I had some Python experience to boot which helped.

Edit: I do have a personal site at https://www.fellerts.no/ but it's entirely static, no real js to speak of.

But Qt is a quite huge dependency, and has sort of turned into a commercial product. If you were starting to develop something similar today would you still choose Qt for it..

Good question. If I want fast and cross-platform, GTK might be a more viable option today. What would you choose for a project like this in 2023?

Qt hands down. I don't consider GTK particularly usable or friendly, especially outside of Linux.

This is so bad, even on Linux, that the experience of trying to package a GTK4 libhandy application to the distro I use made me permanently switch from Gnome to KDE.

I'd pick the native toolkit for wherever I want to use it. If I want it on Windows, I'd use C++ & Win32 / WinRT. On mac, Swift + AppKit. For iOS, Swift + UIKit. For Linux, probably C and GTK (I mostly use Gnome-based distros).

I'd go 100% native because that's how you make the best app for that platform. I also enjoy working with different toolkits and if I wanted this on more than one platform, I think I would enjoy designing and building it for different environments. For example the version I'd make for my small screen touch-based phone would probably be significantly different than what I'd want on my keyboard and mouse equipped big screen desktop.

A multi-platform or web-based solution would have too many compromises.

Slint? https://slint-ui.com

Some years ago JavaFx would have been a reasonable choice.

Qt is not turning into a commercial project. It has always been a project which is dual licensed under GPL (and later some of the modules were also licensed under LGPL) and a commercial license.

It's just that the Qt company always tries to make it non-clear that Qt is not open source to drive their sales.

Regarding bloat, Qt is quite modular and if you want just the widgets you only need QtBase and none of the additional modules.

most components are LGPL not GPL. also after I think it was Qt 5.6, they switched to LGPLv3 instead of v2, so the anti-tivoization clause applies.

Could you give an example (source code link) of a "truly reusable" component?

It's old but I still use it just fine with modern Qt versions:

https://docs.huihoo.com/qt/solutions/4/qtcopydialog/qtcopydi...

https://github.com/sintegrial/qtsolutions

One that I have been thinking about lately is the `QEnumComboBox` [1]. It takes the concept of a combobox (i.e. drop down list/`select`) and combines it with a python `Enum` to produce a very commonly desired functionality: allowing the user to select a value and then converting it to an `Enum`. This to me seems easily reusable because it encapsulates that functionality in a clean way. I can't think of a corresponding example in a JavaScript framework, but I would love to see one. I think this might be more difficult because one can't really pass types at runtime.

I think instead of "truly reusable" I should have said something like "requires minimal configuration." I think Python's reflection capabilities allow one to supply less boilerplate when writing PyQt apps. This is just a subjective impression that I have, and unfortunately I am having trouble elaborating on this in a way that I think would be effective. That is why I asked the author what they thought, since I am wondering if anyone else has had this impression. However, I will think about this more, and I might provide more examples if I can think of them.

[1] https://pyapp-kit.github.io/superqt/widgets/qenumcombobox/

I'm sure there's a million things out in reactland for this, but even in vanilla JS it's pretty simple. I'd write it something like this: https://github.com/JacksonKearl/JSEnumComboBox/blob/main/ind..., demo at https://jacksonkearl.github.io/JSEnumComboBox/

Neither JS nor Python really have types at runtime or any other time, but you can approximate them with Objects and/or Classes (of course, I repeat myself ;) ). With some TS magic you can even get the `setEnumClass` call to be well typed, though if I were building it from scratch I'd make the EnumClass prop immutable, too many weird corner cases otherwise.

I've never worked extensively with Qt myself, but when helping out a friend making Maya plugins in Qt we'd occasionally hit SEGFAULTS from writing seemingly mundane Python that'd crash all of Maya. That was enough to turn me off of it, but looking through the docs you linked there are some compelling components. It's nice to have a component library separated from a specific framework (in the React/VUE/etc. sense)... I don't know of any in JS. Every framework seems to think their (incompatibile with everything else) approach to reactivity is the hold grail, and being modular across it would be impossible.

Though reconsidering, I suppose Qt is sorta the same... it's just another framework and their "signals" aren't Python. Ah well.

Diving deeper, signals are weird... they aren't even really part of the underlying C++! Some sort of strange new modifier Qt invented at the level of `private`/`public`/`protected` and such. https://doc.qt.io/qt-6/signalsandslots.html

I am not aware of Qt being the problem here, having built large Qt apps that run stable (coding in C++ only). I guess it is rather an issue with the Python to Qt interface.

Reply on news.ycombinator.com