[opinionated rant warning, trigger words possible]
It's not Qt's fault in any way. I was there when the internet arose, was there at Qt 2, I saw attack ships on fire off the shoulder of Orion... The siutation has come about because the confluence and timing of several factors:
0. Multiple platforms
1. HTML, JS, CSS as the web platform (herein the 'web')
The web was incrementally by people who had no idea what they were building. That is not to blame them for incompetence, but they had no idea what they were really building up to. Considering all the resources were not local, and could not be trusted, I think they got a lot of the issues, save for a few: XSS, CORS, etc. right. Hindsight is 20/20 so naturally any approach that comes about after you can see the clusterF that was created will have an advanage. The Web though, it had a few key things that were superior to development at the time, it was far faster to make anything, the browser provided reasonable protections. 25 years later, we can clearly see the mistakes...
But it's incremental approach is like boiling a frog (urbal legend by the way), but the Web as succedded because it is the most open with lowest barrier to entry. You need a free browser and and text editor and your non-validating HTML wll be displayed somewhat appropriately (insert jab about IE.) and shared with the world population in milliseconds. It's an attractive platform for people who want to get into computers and don't have much experience. No dealing with compilers, etc.
'Uncle Bob' Martin has observed that the number of software devs doubles ever 5 years. (My insight: This is why most code is bad - people have been trying to get software to work at all, not how to have it not fail). It takes time to develop, to have it fail, to see the requirements change and stragagize around that. Most of those people coming in are doing HTML, CSS, JS. With those warts and all. Our environment is not any better, C++ is not attractive syntax, compiler warnings, compiler inconsistencies. It is too discilpined for most wanting to get 'into development'. This is why it is not Qt's fault.
Electron, ReactNative, are just those Web people taking the path of least resistance to a new platform from the one they already know. If you have a hammer, you're looking for nails that your hammer can handle.
Where you may lay a valid complaint at Qt is it's licensing has not been as permissive as the web. It still isn't, (BSD would be best) but with the advent of LGPL option from Nokia, the main objections are no longer substantially relevant.
Your focus on CPU cycles is misplaced. While clocks have flattened out and you might see this as pressure to be more perfomant per clock, cores have continued to increase. My phone as 8 cores. Also, as an edge case the memory bandwidth across mulitple cores can be higher than one core. Therefore, the proper approach is to focus on coding software that scales across cores, not clocks.
I have other complaints about the Web (a lot of undisciplined engineers inventing a new framework every three months because the last one lacked 'a' feature they wanted). (But I guess it's good for their resumes?) None of the Web stuff properly supports inheritence either. (Maybe new JS classes)
I have been pushing for a web-ified version of Qt for a while now. I attempted mappng QPainter calls to a HTML5 Canvas (I called it 'Vaudeviile', GNOME called their 'Broadway') and got some promising results. There was some interest in it too, but I never got ti far enough for anyone to buy in. QPA was a new thing back then and undocumented and I couldn't find enough docs on QPA to make it a platform. Now, we have the WebGL plugin tech preview. I've been trying to steer it's development, but I don't have buy-in from Qt engineers.[1][2] There are architectural decisions that are being made today that I would like to change to make it possible and secure, and they are not being considered in scope. Imagine a QML web app server, serving QML apps over WebGL. The tech preview sounds like that, but it's just 1-socket-1-client-1-instance. If we could properly adapt QML for web, we'd have a completely superior web development paradigm. But I don't know if Qt wants to enter that space?
[1] https://codereview.qt-project.org/#/c/215908/
[2] https://bugreports.qt.io/browse/QTBUG-65241?focusedCommentId=387476&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-387476 <-- the right idea
Sent: Thursday, February 15, 2018 at 6:23 AM
From: "René Hansen" <ren...@gmail.com>
To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>
Cc: interest <interest@qt-project.org>, "Nikos Chantziaras" <rea...@gmail.com>
Subject: Re: [Interest] QML vs Electron
From: "René Hansen" <ren...@gmail.com>
To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>
Cc: interest <interest@qt-project.org>, "Nikos Chantziaras" <rea...@gmail.com>
Subject: Re: [Interest] QML vs Electron
In my opinion Qt, (as a company), is directly responsible for the mess that is Electron and todays scape of the app-world. I worked for Nokia back in 2011, when they were trying to build, and miserably failed, the next-gen phone os platform, entirely as a web-runtime. The switch to a Qt/QtQuick approach on top of Meego was such an improvement in speed and overall resource usage. Being able to natively bridge with ease, while still keeping the door open for _javascript_ devs. was, and still is the single most killer combo out there.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
