51–60 of 88 posts
The article does seem to ignore the licensing side of things, where QT is more expensive/restrictive if you're not developing open source projects.
The article does seem to ignore the licensing side of things, where QT is more expensive/restrictive if you're not developing open source projects.
It's pretty disingenuous to say that complying with the GPL is more expensive and restrictive. Purchasing a comparable closed source software suite, or developing it in house, might be less feature complete and more expensive. It's "restrictive" in the sense you need to comply with the GPL which probably gives much more freedom than most closed source licensing terms [2].
Earlier quoted context omitted.
And licensing. Qt is LGPL or commercial. HTML is (in practice) more liberally licensed. (Edit: not GPL, but LGPL. Which is almost as bad for embedded systems as GPL itself is. How do you let the user relink Qt or replace Qt with their own version, in the field? Nightmare. Just pay up. Qt LGPL is (or was) fine for desktop apps pre app stores. Now, not so much.)
Qt has been LGPL as well for years now.
Earlier quoted context omitted.
What I'm missing are some points regarding: - Maintainability: Who will maintain a Qt application once it's deployed? How fast can a Qt application become modified? - Cost for/of developers/development: How easy is it to find good Qt frontend developers/maintainers? - System upgrades: How will HAM upgrade its appliances? I assume he's talking about HAM as BSH (Bosch and Siemens Home Appliances). They're currently hea…
The cost of hardware at scale dwarfs the cost of software. If it means paying 5 people a %25 percent premium to save $1m then it's probably worth it.
I wonder Espruino was not mentioned so far. Their approach could speed up dev time by a lot.
Or maybe some kind of next gen HTML that is targeted for maximum performance (like webassembly is to javascript).
Ideally we would have UI framework that can target both web and native. Or maybe some kind of next gen HTML that is targeted for maximum performance (like webassembly is to javascript).
There's even project(s, or at least one) out there that seem to have had this idea (https://github.com/status-im/react-native-desktop), but few people working on them. I would be 100% unsurprised to see no Electron people doing this, so if you really want to see an alternative, and are looking for cool open source projects to devote time to, maybe something worth considering. It's not an easy feat at all - this thread alone (https://github.com/status-im/ideas/issues/34) kind of explains why.
In my opinion, this is unlikely to ever take off in any serious form, and Qt will continue to generally be the "it exists but nobody really considers it unless Electron is 100% out of the question" option. There's simply too much momentum in terms of new UI components/capabilities/what-have-you that the browser runtime brings to the table that Qt (be it SDK or community built components) cannot match.
Good luck getting any serious technical support with Qt. At least with HTML5 there's a huge amount of users and technical resources. I was never able to get answers to any technical questions that weren't trivial.
Ideally we would have UI framework that can target both web and native. Or maybe some kind of next gen HTML that is targeted for maximum performance (like webassembly is to javascript).
What is ideal about that?
Ideally we would have a vehicle that can target both trips to the local shop and a vacation to Morocco. What? I like having a separate bicycle and airplane.
Good luck getting any serious technical support with Qt. At least with HTML5 there's a huge amount of users and technical resources. I was never able to get answers to any technical questions that weren't trivial.
Even setting aside the argument that, sure, it'd be nice if people paid one another for good work... that's just a hellaciously slow turnaround time. The greater mindshare in the web ecosystem makes dodging a bunch of issues much easier.