I have faith that the Qt project won't spend time shipping this if it doesn't offer advantages. Give them time, and a little benefit of the doubt based on a very long history of excellence.
I would argue that Qt's problem is:
* Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)
* Getting started with Qt is painful and integrating it into an existing codebase even moreso - get ready to suffer with C++ linker nonsense
* You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
* The "deploy" bit is completely left to the reader, Qt doesn't help you write apps and ship them end-to-end. Contrast this with Electron which has a pretty strong (albeit a bit mysterious) packaging and auto-update pipeline
Qt experts will argue on all these points, "It's a library, it shouldn't do XYZ", but at the end of the day, Qt is a means to ship Desktop and Mobile Software, and by ignoring the entire Developer Experience from end-to-end, they miss the mark.
* Getting started: I agree it is painful. There's a definite learning curve here. I believe it's worth it obviously, but that's obviously subjective.
* Language choices: There are binding for quite a few other languages. There's a lot of pyqt projects out there. But I disagree that C++ is painful - it really depends on who wrote it. Well written C++ is pleasant, poorly written C++ that abuses things is awful. The javascript portion does suck tho, you are right. It will improve, but it doesn't improve quickly.
* Deploy bit: you predicted my argument here. I favor the system package manager.
Edit: To clarify, if you provide the parts of your application that are proprietary as statically linked libraries wherein the recipient can relink to a modified version of the LGPL'ed library then that satisfies the LGPL.
1: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Not saying it makes sense, just that groupthink is strong.
It doesn't play ball with IP business and NDA rules that are common place in the industry.
I find it quite acceptable.
- Willing to give your work for free the same way as taking Qt's work? No problem, LGPL has you covered.
- No issues with dynamic linking, still wanting to use the work of others for free? No problem, LGPL has you covered.
- What to sell it for lots of cash? Then give the Qt guys a piece of the cake back and be happy they still exist.
I wonder what are the nice parts of JS web dev, collecting new frameworks and build tools every week, or functions as packages?
In fact I am pretty opinionated that some of the new UI goodies are only exposed via QML, which wouldn't be a problem if people stopped writing logic there.
You can absolutely use it for free in any project, as long as you conform to LGPLv3.
Regarding JS: You're not supposed to write more than glue logic in JS - well, that's the practical experience. For some reason, the Qt company recommends more JS use than that.
I think the main reason that's a commercial offering is that developers of proprietary software like shipping binaries instead of human-readable QML files.
So you're saying there are projects where I cannot use Qt? The fact is, there exists projects that do not have the option of using Qt without paying for expensive licensing. Such projects should at least consider using Electron which might have significant non-technical advantages for them.
It is cool that what many consider to be the best commercial desktop GUI is also open source, I will admit that much. Still, we shouldn't complain too much when many projects choose to use Electron, it's licensing is just so much more permissive which is a significant advantage for many projects.
"I don't want to pay for software, so here take a bloated browser as fake native app".
I don't think QT and Electron are architecturally equivalent.
Electron uses components that are under LGPL (Chromium for instance) so it's basically exactly the same license questions than with Qt.
Deployment is a little bit of a pain but they actually provide software to help - macdeployqt and windeployqt bundle everything up into a dmg or a zip.
You aren't forced to use QML. I kind of hate it and QtWidgets are much more mature - I just use those. Sure maybe they aren't being developed so much but they're still maintained. I don't think they'll go away for a long time.
Qt is great.
Can anyone explain why it is free to use if you link with dynamically, but not statically? (I've seen this point come up a few times in discussions about Qt here on HN.) I know what dynamic and static linking mean, but not clear about the connection to free vs. paid Qt use. Is it something obvious that I'm missing? Only thing I can think of (admit I didn't think a lot about it yet) is that if you use it for free with dynamic linking, deployment is more of an issue, vs. just shipping a self-contained statically linked app.
Thanks in advance.
long story short: it's actually false, you can entirely ship your app linked statically with Qt under LGPL and still comply with the license. However, you have to ship your .o files: basically, what the LGPL requires is for people getting your app to be able to relink your app with their custom version of the LGPL libs (so Qt).
uh... yes you can. It's LGPL. Chromium and libchromiumcontent used in Electron are also under LGPL and this does not cause problems anywhere.
https://github.com/Timmmm/robocut/blob/master/CMakeLists.txt
Also they already build tooling for Qt such as Qmake and Qt Creator, it seems to me their goals are clearly to make those goals attainable, it may not be as perfect as the alternatives but it does do a decent job at the very least, but I do agree, the licensing does keep me away from using Qt usually just because I never know where a pet project might end me up.
I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"?
> You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
I'm looking at the Golang bindings for Qt (to implement my point above.) Have you considered it? Is Go something you'd consider?
Usually software licenses for commercial development tools have a few more zeros, or not even that, forcing one to schedule a meeting with their sales people.
Before the FOSS movement, startups somehow managed to pay for their software.
I would love to use Qt but their licensing and terms just immediately kill it for me: https://www1.qt.io/faq/#_Toc_2_5
You can make commercial software using one if the open source licenses. (Of course; otherwise it wouldn't be an open source licence.)
Qt with Rust is progressing well.
The only other options is the hybrid approach which uses native widgets like wxWidgets, but this means you're limited by the lowest common denominator.
I think most people consider visual studio to be an exception, not the norm. Whether or not visual studio's performance success represents what the typical developer should be expected to get when writing idiomatic JavaScript in Electron has probably not been fairly evaluated in the face of popular performance slugs like slack.
One of the best things to happen lately is reader view which does make a good chunk of the web match my theme. There's always been plugins, custom css, etc to work around this failing of the web.
The only issue I have with non homogeneous UI is that it is often an opportunity for not so gifted developers to become creative in term of basic UX and we often end up with no obvious way to go back, non discoverable features and other UX fails.
Use of native controls and their benefits is greatly exaggerated and it all comes down to some murky-feely subjective opinion.
Given that, why would you use this instead of just building a compiled package for a targeted platform?