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/
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
https://docs.huihoo.com/qt/solutions/4/qtcopydialog/qtcopydi...