[Interest] QML vs Electron

[René Hansen]

On Thu, 15 Feb 2018 at 16:53 Jason H <jhihn at gmx.com> wrote:

> [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.
>

I should probably have disambiguated my use of Qt and QtQuick a bit more. I
completely agree, that writing a C++ application in Qt, would never entice
the kind of developers working with web technologies in any case. What I do
argue though, is that QtQuick might have. Had it offered a path of
resistance on equal footing, with those web based options, more web
developers might have taken on the investment of learning to build UIs in
QML vs. HTML and CSS, while keeping their application logic expertise
within Javascript.

The hero on the current product page for QtQuick reads:

"CSS and JavaScript like declarative language with a cross-platform IDE and
native runtime performance."

Furthermore, C++ is mentioned five times on that page, while JavaScript
only has that single appearance.

If I was a JavaScript developer looking for options to build native apps,
I'm not sure I'd even know that this was something of a competitor for
Electron, React Native etc. Market positioning for QtQuick has a lot of
room for improvement, if it wants to be a contender.

I think you're on to something regarding the licensing, which Benjamin
Terrier also expands upon later in this thread. Electron et. al. are all
MIT Licensed. A license pretty much anyone, even those unversed in general
opensource licensing, has come to know as a "no strings attached / do
anything" license, making adoption of software under it a no brainer. I
don't think most people understand, exactly what they are allowed to do
with the (L)GPL to the same extent, as well as what obligations follow.
Heck I still regularly use tldrlegal.com myself, because I forget the
differences between various licenses.

Licensing isn't an easy thing and obviously The Qt Company still needs to
make money. If QtQuick wants to be as prolific as it's alternatives, maybe
the licensing question is one to revisit however. In my experience
technologies seem to seep into organisations through grassroots. If Qt was
licensed completely carefree for the odd tinkerer and app maker, that
person might "bring Qt to work" on a future projects within said
organisation.

Taxing big corporate use, while exempting smalltime adoption, even
commercial, might be the way to go. This is just speculation on my part
though, I have no idea how a licensing scheme like this would work in
practice.


>
> 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)
>

Hear hear.


>
> 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" <renehh at gmail.com>
> *To:* "Jean-Michaël Celerier" <jeanmichael.celerier at gmail.com>
> *Cc:* interest <interest at qt-project.org>, "Nikos Chantziaras" <
> realnc at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180220/820b1334/attachment.html>