Well there have been some other articles that talk about using Qt, python's built in browser or Python+GTK over electron/HTML5 apps. There are a lot of people out here sick of things like Slack/Discord/Atom which each have the entire Electron framework that weigh in at 80 ~ 150MB.

I'd be all for using GTK or QT if there were just better well supported bindings, with good documentation and examples, for languages like Python, Ruby, Rust, Scala, etc. I know some people love C++ and the newer C++11/14 seem to have cleaned up a lot of cruft (although GTK is in C unless you use Gtkmm), but I think the barrier to entry would be easier if their other language bindings had better docs.

All that being said, this does feel very ad-like. Qt is commercial. I wonder if they're trying to push this stuff and make it look organic.

I've been wondering for a while now why Electron isn't separate from the application bundle itself. Having an app simply declare its supported version of Electron and downloading one version for all apps to use would make a lot more sense in terms of disk space.

I guess disk space is considered one of those "commodities" nowadays. I disagree (typing this from a 64GB SSD Mac) and HATE Electron apps for this reason. (Xcode, too, because it eats up disk space, but that's talk for another day)

Qt has very good and well-documented Python bindings (PyQt).

Also, QML has bindings for a lot of languages if you're not comfortable with either javascript or C++ for your backend.

I used to call Qt ".Net for people who can't have anything better".

When you code in Qt you rarely, if ever, are exposed to the hairy parts of C/C++. If anything, it feels like coding in C#. Nesides UI there are a gazillion helper and utility classes for everything from networking to threading to string handling. And with QML there's even less C++ :)

I actually just migrated a small Rust application to C++ with Qt because I have to use DBus and Qt has a very nice DBus library, which Rust has not. (In general, DBus hates runtime environments that don't have an event loop.)

It's pretty hard to have asynchronous calls without an event loop ;)

Using DBus synchronously is, strictly speaking, wrong unless you can PROVE that there can be no deadlocks; talking to the DBus daemon itself synchronously is generally safe though. Unfortunately QtDBus encourages synchronous calls. Maybe you remember desktop hangs in early KDE 4 related to global shortcuts - that was me not knowing that rule at the time.

There's not many votes, it's just that the front page algorithm likes to freshen up its listings once in a while. While I'm not really sure of the specifics, I know for a fact that posts with low votes and low engagement make it onto the front page with seemingly no reason (source: this happened to my first blog post, but eventually got a number of votes and comments)

Edit: anyone who wants to read the (largely uninformative and unsubstantial) white paper/advert, here's a non-infowalled (is that a word?) link: http://content.cdntwrk.com/files/aT05NDQwMzEmdj0xJmlzc3VlTmF...

Edit 2: scrolling through, I found this gem of a quote: "Even with static linking, Web executables will be five times bigger than Qt executables. Hence, Web applications will take five times longer to load than Qt applications."

That's completely false. Program load time is not directly correlated with size of the executable in a 1:1 ratio. The correct answer is "it depends."

Edit 3: on page 10, they don't acknowledge that HTML/CSS/JS is easier to learn than C++, and also they don't acknowledge HW acceleration for animations in CSS (thus smooth animations).

No registration link: http://www.embedded-computing.com/i/944031?source=hub&expand...

I did. I like it, for its wandering off the beaten path.