8 ms·

People who think that just because it's in C++ it's harder than the average web app to write, and lack of ability to deploy e.g. on macos without owning a mac o

People who think that just because it's in C++ it's harder than the average web app to write, and lack of ability to deploy e.g. on macos without owning a mac or windows without having a windows partition (though there are solutions, but nothing as easy as what electron proposes). I also noticed that a lot of people tend to choose electron arguing that unlike Qt (which is under LGPL), Electron is under MIT, but it seems that they are not aware that it's only the electron scaffolding part which is MIT, not the whole electron framework which includes chromium, ffmpeg which are also LGPL. Though overall I'd wager that there's an order magnitude more cross-platform single-toolkit apps built with Qt than with other frameworks.

deleted 8y ago
[deleted]
funfunfunction 8y ago
Do most people choose Electron for the licensing or because of the cross platform benefits of a JavaScript codebase?
- electricslpnsld 8y ago
  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.
- deltron3030 8y ago
  It's the design culture JS is embedded in, more creative people, or full stack devs who can make it work but also pretty.
seba_dos1 8y ago
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.
- jcelerier 8y ago
  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
- chocolatebunny 8y ago
  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).
- kodablah 8y ago
  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.
  - seba_dos1 8y ago
    https://github.com/tpoechtrager/osxcross 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 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...
TheAceOfHearts 8y ago
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.
- martin_ky 8y ago
  > 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 https://woboq.com/blog/moc-myths.html

deleted 8y ago

[deleted]

funfunfunction 8y ago

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

electricslpnsld 8y ago
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.
deltron3030 8y ago
It's the design culture JS is embedded in, more creative people, or full stack devs who can make it work but also pretty.

seba_dos1 8y ago

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.

jcelerier 8y ago
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
chocolatebunny 8y ago
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).
kodablah 8y ago
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.
- seba_dos1 8y ago
  https://github.com/tpoechtrager/osxcross 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 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...

TheAceOfHearts 8y ago

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.

martin_ky 8y ago
> 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 https://woboq.com/blog/moc-myths.html