C++ is arguably one of the most complex popular programming languages out there. With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++. A good comparison could be writing plain Ruby vs writing a Rails app.

I'll admit my experiences with Qt have been fairly limited relative to my web work, but picking up QtWidget seemed like it had a much higher barrier of entry than a web tech stack. Although I'll also recognize that QtQuick and QML greatly seemed to streamline the whole thing, especially for getting started. Based on my experiences performance with QtQuick still left a bit to be desired, but it was still an improvement over most Electron equivalents.

It's also worth noting that these comments mostly apply for people going for a mostly-native look and feel. If you want to completely customize the look and feel of widgets, as many modern apps have recently begun to do, I think it might be easier to get started doing that with the web stack. Then again, I recognize that this just might be my inexperience talking.

It also depends on the kind of app you're trying to build. I've written lots of personal apps using server-side rendering and a tiny bit of JS and I love how easily I can deploy and access it from all devices. That's a kind of versatility you just don't get with native.

IMO, most web developers could probably learn a lot from giving Qt and other native toolkits a try.

> With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++.

This is a common misconception of beginner Qt users or people who just looked at Qt superficially and decided not to use it, because it's not "regular C++".

You use Qt with 100% pure C++. Qt itself is written in 100% pure C++. The part that confuses people is the metaobject compiler (or MOC). This is a simple code generator tool that provides additional features like runtime type information and reflection. It does not modify your source code, only generates some additiona, 100% legal C++. Granted, this requires an extra build step before invoking the C++ compiler. But Qt's build system handles this automatically, and it's not really difficult to integrate into any other build system.

Starting with Qt 5, you don't even need to invoke the MOC compiler, because in many cases, the features provided with generated code were replaced by new C++11 functionality.

If/when C++ gets proper metaclasses and programmable compile-time code generation, there will be no more need for MOC, because all of its functions can then run in a single compilation step.

There's a great blog post debunking the myths about the QT metaobject compiler - https://woboq.com/blog/moc-myths.html

Do most people choose Electron for the licensing or because of the cross platform benefits of a JavaScript codebase?

Probably neither -- I'd wager that Electron's popularity among web-centric companies is due to the prevalence of JavaScript programmers in these shops. With Electron there is no need to hire anyone new (or eat the cost of programmers retooling) to roll out a desktop app.

It's the design culture JS is embedded in, more creative people, or full stack devs who can make it work but also pretty.

I have no idea about other platforms, but on Linux it's extremely easy to set up a cross-compilling environment for building macOS, Windows and Android applications. I'm not exactly sure if I want to have the applications I use be written by people who can't even bother to do one-time setup of their compiler toolchains if there's no ready-made script on GitHub that does it automatically, like there are for Electron.

I have a Qt app and don't have a mac. Can you point me to where I can create the self-contained dmg or app file w/ all the icons and such on Linux that works on mac? I am familiar w/ Qt's mac tooling that is only shipped with the mac install, but if "it's extremely easy" on Linux, I'd really like to know.

https://github.com/tpoechtrager/osxcross for the compiler and libraries. You might be even able to simply install Qt there using MacPorts, so no manual compiling or unpacking the SDKs into osxcross's rootfs should be needed. A properly configured CMake project will make an .app file for you automatically (although if you'll want to bundle dependencies as dynamic libraries instead of using frameworks, you might have to fix linking paths with a script like https://gist.github.com/artm/3668431 - that was the hardest thing to figure out for me)

macOS icon file can be created with png2icns, Windows one with icotool.

Overall, the whole process is easily scriptable. I'm making small games in C with Allegro 5 and I'm using only GNU/Linux. It wasn't hard to make scripts to automate the whole process of making builds for Windows, Linux and macOS. Android was a bit more tough, but manageable - I wanted to have it all done with CMake instead of Android Studio though, so that probably made it harder. The hardest was "HTML5" build with Emscripten, but it works now. It's a pity that iOS is off limits for that though...

> https://github.com/tpoechtrager/osxcross for the compiler and libraries.

yes, I know osxcrooss but it is not legal to use if you aren't developing on apple hardware which makes it a bit cumbersome. Grep for "Authorized Test Units" in the xcode license linked in the repo.

It literally says (section 2.2, Permitted Uses and Restrictions):

"Install a reasonable number of copies of the Apple Software on Apple-branded computers"

It's likely enough that such a statement will be considered void when tested in EU court (as you can safely reverse engineer software for interoperability purposes) that I don't care.

> (as you can safely reverse engineer software for interoperability purposes)

but here you're not reverse engineering, you're copying proprietary software for which you don't have a license. Reverse engineering is allowed if you have the right to use the original software ; you certainly don't have the right to reverse-engineer e.g. a software that you would find on a CD somewhere in a park without a license attached.

I'm afraid this doesn't replicate macdeployqt. There are many quirks that are not being taken into account here. My Qt app does not use cmake, it uses qmake. I have certain static compilation needs. Also, I said I didn't have a mac, so how do I get the OSX SDK? Your original statement about "extremely easy" is clearly false (you even mentioned a "hardest thing" which is custom per-OS scripting). I hope it's clear that this is why Electron is popular. I don't see how this can be seen as extremely easy from anyone's perspective and it's the mindset that drives people towards Electron.

That's exactly what I mentioned in my first comment. There are some hops to take, but nothing that could actually stop any competent developer.

Sure, you can use Electron right away, you don't even need to understand what you're doing. That has probably a great value for people who want to learn or for scrappy hobby projects, but shouldn't matter for anything serious.

cross-compiling isn't the major issue. It's the toolkit. Yeah a cross-compiling C/C++ environment is fairly straightforward to do especially if you just want to do a commandline utility that can be done with the C or C++ standard library. But having any sort of GUI toolkit (such as Qt).

how would it work on macos ? If you have graphical apps you have to link against the various Cocoa frameworks, and those are (legally) only available on mac machines