[Interest] QML vs Electron

[Filip Piechocki]

Hi,
recently I was comparing animation performance on i.MX6 DualLite SoC
between QtQuick and HTML. I'm not an expert in HTML so do not know if I did
things best possible way, but I took Servo rendering benchmark (
https://youtu.be/u0hYIRQRiws there is a link in a description) an reduced
number of elements to 60 to get sane results on such weak ARM device I
have. Then I reimplemented this in QtQuick. So the results are 8fps for
HTML and 60fps for QtQuick.

QML/QtQuick is quite easy and sometimes you'll be surprised that you
could've create what you wanted in such few lines of code. But on the other
hand, there are things that are not obvious, Qt docs can be lacking some
details on something and you may come up with something that looks like
hack rather than proper solution.

Last but not least - QML is declarative and it is hard to switch from C++.
I saw qml files filled with walls of imperative JavaScript code, like some
filtering done by copying elements from one ListModel to the other instead
of proper proxy model in c++, state handling by ifs spaghetti and some
properties like "stateOne: 1" etc. I always suggest getting some
professional QtQuick training if that is possible to avoid common mistakes.

BR
Filip

On Feb 15, 2018 5:36 AM, "Jason H" <jhihn at gmx.com> wrote:

> > > Anyway, you can lament it, but that ship has sailed.
> > > If you really want to know what I'm thinking, it would be to ditch JS
> entirely and use ChaiScript in QML.
> >
> >
> > Thanks for the response, Jason.
> >
> > If I understand your salient point here, you're advocating the
> "traditional"
> > approach of just maintaining device-specific, not-necessarily-related
> code
> > bases that duplicate the same application functionality?  So, use the
> > per-platform accepted coding frameworks -- C# for Android, ObjC for iOS,
> Qt
> > for dekstops, etc. -- and just develop the required expertise in each
> area?
>
> Not at all. Just the loftiness of Widgets everywhere is unlikely to ever
> be realized. Qt does a lot very well. I've heard lamenting that most people
> get QML wrong - that JS is not to be the application code, just the glue
> code. There certainly is appeal to that, C++ code is the most portable and
> most efficient, but in the end it is easier to just write JS instead of
> C++, though ChaiScript would bridge that gap. JS also bring in async issues
> and its own event loop.
>
> Anyway, at the end of the day, Qt is a success, and the intricacies of
> dealing with the various platforms is made manageable. I just assume there
> is no back button on the device. Android users never complain.
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180215/d76100ec/attachment.html>