[Interest] QML vs Electron

[René Hansen]

On Thu, 15 Feb 2018 at 13:40 Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:

>
> > On 15 Feb 2018, at 12:23, René Hansen <renehh at gmail.com> wrote:
> >
> > 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.
>
> That phone can still be built, and it’s what I want too.  Ubuntu’s version
> looked promising until they dropped it.  Jolla did their version.  (Now if
> only they could ship their tablet, and refresh the phone hardware, and sell
> lots of them.)  Next puri.sm is up to bat.  Everyone is finding it hard
> to compete with the duopoly though, so far.
>

It definitely can, but money flows where hype goes and I've yet to see a
big player rising to the task and succeeding at scale. Personally I think
Meego would have been the one, had it not been for the whole Windows Phone
pivot / disaster.


>
> > As an engineer, being witness to the rise of Electron based apps, has
> left me completely baffled so many times. How could Qt have such a major
> head start and still fail to position themselves, as the de facto cross
> platform development framework. I mean, they even *had* Javascript, fer
> crying out loud! I've never been able to come up with a good reason for
> this. I've resorted to thinking that, either, A, Qt didn't *want* to be
> dominant in that space, and has spent efforts expanding in other markets or
> B, they've had one of the worst marketing divisions in modern tech history.
>
> OK, from your perspective are there a few small, achievable features we
> are still missing?  Or mostly just marketing focus?
>

In my opinion it is both. It's about growing the ecosystem through
marketing and outreach, while lowering the bar of entry by building better
primitives and tooling for working with Qt. It is something that the JS
world has been exceedingly good at. Pretty much any obstacle you can run
into as a new JS developer, has been solved by someone else, who most
likely built a tool or framework to help you out. That is only the case,
because that person found it easy to build and share said tool or
framework. And so on and so forth.

Now, as an example, let's pick, (and pick on), NPM.

Fundamentally I think the way that NPM is being used to dump every little
code snippet is such a broken paradigm, that it's not even funny. It is,
however, very hard to overlook how much it has catapulted growth in the
community. I do think, that what is so deeply broken about NPM, is
something that can be solved by guidance and cultivation of a different
mindset though. Other package managers doesn't suffer this problem to the
same degree.

I know it's easy to look at all the completely ridiculous tendencies, that
*do* come from the JS community at large and balk at the whole notion of
using it as a driving example and you wouldn't be completely out of line.
Choosing *what* to learn from is important here. Paramount I'd say, is
their ability to *dumb* things down enough, that anyone, regardless of
skill level can start building applications from day one.

And yes, I do know that qpm exists. Last I checked though, it wasn't
officially endorsed by Qt; the last commit is ~ a year old and it currently
houses 105 packages. NPM has almost 600K... It would go a long way if
developers knew Qt officially supported an initiative like qpm, or
otherwise grandfathered something similar itself.

Another thing is UI toolkits. If you want to build apps with web
technologies today you can have your pick of the litter of Bootstrap,
Semantic UI, ZURB Foundation, etc., etc. and what they all have in common
is that they are incredibly comprehensive and just so easy to use. QtQuick
Controls 2 is a good start, but lacks so many of the ready made components
offered by other toolkits. It is still very much BYOB.

And what about testing? In JS, the landscape is very rich when it comes to
testing frameworks. Jasmine, Mocha, Sinon, Unexpected. The list goes on. In
e.g. Ruby you have something like RSpec, a personal favourite of mine.
Minitest, Cucumber, etc.. All very extensive frameworks with tons of
documentation and examples for every little corner case. There's even very
specific guidelines and best practices attached to most of these
frameworks, which not only works as examples for newcomers, but also as an
educative tool in learning how to write better tests.

Compare that to testing in QtQuick. It is quite frankly close to a zero
value offering by Qt. The entire QtTest module is comprised of three
classes and the reference documentation is this single page;
http://doc.qt.io/qt-5/qtquick-qtquicktest.html. There's a lot of unrealised
potential for improvement here. In my opinion, all project templates in
QtCreator should come with a predefined structure where test examples are
included. Everything from example unit tests, to more involved BDD point
and click tests for the UI. Driving best practices from the get go would go
a long way.


> > Imo building native apps completely on top of a web-runtime, will
> *never* be a good idea. I don't care how much Javascript developers, are a
> dime a dozen, it's just plain bad engineering and I weep a salty tear, when
> I see something like Atom take a good 6 seconds to launch on my 2015
> MacBook Pro, while eating away 359MB of memory, before even opening the
> first file. (I'm not an Atom user, this is just an example)
> >
> > How can that be acceptable, in, any, way?
>
> IMO it isn’t acceptable, and so far it’s still possible to pretend those
> apps don’t exist.  I hope that continues.
>
> > I know, QtQuick does ship a web-runtime in order to execute JS, but go
> and try to open the "texteditor" example from QtCreator. It flies open even
> in Debug mode, and consumes about 24MB on launch. It is an entirely
> different beast!
> >
> > How on earth could Qt drop the ball so hard on this one…
>
> OK so maybe you are kindof focused on text editors or apps that contain
> editors along with other stuff?
>

Not really. I just used the texteditor example, because it was the closest
one compared to Atom. I'm a Vim user, so I have no stake in the editor
wars. :)


>
> I think maybe a fancier editor (like Creator’s) should be available as a
> reusable component: as easy as importing it and using it in any QML app.
> But management probably doesn’t expect us to make a lot more money by
> getting us ready for the 1980’s like that (even though text editing is
> still just as relevant as it was then).
>
> > Every single time I have to run an Electron, or
> insert-name-of-other-js-based-app, I get that sour grape taste in my mouth,
> because it didn't have to come to this. I really do blame Qt.
>
> Well the idea that the browser could be used to build applications goes
> way back… Active Desktop is about the earliest attempt I can remember.  I
> think the web needs re-architecting too, so having one efficient platform
> for applications regardless whether they are online or locally hosted is
> not impossible… but we’re too dependent on the existing web.  Incremental
> improvements are easier, but won't make it more elegant as long as every
> layer must remain, for backwards compatibility.  As long as the current web
> architecture continues, the temptation to make apps portable via
> browser-based UIs will continue.


> You could also blame Java for not becoming the eternal universal
> platform.  In one way, that game was over way before Qt Quick got started.
> And yet it lives on in Android, despite taking so long to get there, and no
> longer being “cool” by then.
>
> (disclaimer: opinions are my own)
>
>
I agree, Palms webOS also seems to be going strong regardless. Well, and
this is also my personal opinion, if more people in the past 5-7 years, had
had Qt on the table when choosing a hybrid application architecture, I
think the reason for something like Electron, React Native etc. to exist,
would just never have happened.


/René
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180215/1ba7e4a7/attachment.html>