[Interest] QML vs Electron

Thu Feb 15 12:52:27 CET 2018

Obviously its not a responsibility of Qt as a company (but, I suppose, they
can promote Qt even harder). The overall technical level of todays
developers gets lower, unfortunately. Business requires fast solutions and
doesnt care about any foreseeable future. This demand creates
low-skilled-developers proposition: "noone cares about resources today"

On Thu, Feb 15, 2018 at 12:23 PM, 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.
>
> 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.
>
> 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?
>
> 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...
>
> 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.
>
> Oh well, at least laptops with 16GB of ram are easy to come by these days,
> and it being wintertime, I guess it's nice that all those wasted CPU cycles
> at least help to keep me warm. /end-of-rant
>
>
> /René
>
> On Thu, 15 Feb 2018 at 07:37 Jean-Michaël Celerier <
> jeanmichael.celerier at gmail.com> wrote:
>
>> > They don't really compare. Electron forces you to write the entire
>> application in JS. With QML you only have to write the UI in it. The rest
>> stays C++.
>>
>> As much as I like C++, the company I work at has been doing pure QML apps
>> and they certainly have been developed faster that the equivalent in C++
>> would have, with no particular performance problems (but so much bugs
>> though... landmines and unimplemented features (looking at you QtMultimedia
>> and fonts!) under every step).
>>
>> -------
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Thu, Feb 15, 2018 at 4:39 AM, Nikos Chantziaras <realnc at gmail.com>
>> wrote:
>>
>>> They don't really compare. Electron forces you to write the entire
>>> application in JS. With QML you only have to write the UI in it. The rest
>>> stays C++.
>>>
>>> For desktops, you should be using Widgets anyway though. QML just
>>> doesn't integrate well. It's made for phones, not desktops. It seems like
>>> it was developed in a period of time where everybody was out of their
>>> freaking mind about desktops either dying or all of them becoming glorified
>>> tablets. But we all saw how well Windows 8.0 was received...
>>>
>>> Desktops aren't going anywhere anytime soon. And widgets are the
>>> *perfect* framework for them. QML is nice for mobile.
>>>
>>>
>>> On 15/02/18 03:45, Bob Hood wrote:
>>>
>>>> I'm starting to see more and more software being written in, or being
>>>> ported to, Electron[1] (e.g., Skype's latest v8 update now uses Electron).
>>>> I know QML is supposed to be Qt's solution to cross-device development, so
>>>> I'm wondering if anybody here has had opportunity to actually use both, and
>>>> what insights they might have in terms of comparing QML's declarative
>>>> design to Electron's HTML5 approach.
>>>>
>>>> Full disclosure: I'm a hard-core Qt C++ developer, and I've made no
>>>> secret of the fact that I'm not crazy about QML.  However, it's getting
>>>> harder and harder to avoid having to be cross-device in my development, and
>>>> while I know Qt Widgets can run on mobile devices, but it seems like a
>>>> heavy weight and somewhat inelegant approach.  Something more designed for
>>>> the task might be my only/better option.
>>>>
>>>> On a related note, has anybody done a QML (e)book yet that is focused
>>>> on its uses in cross-device development?  The last/only one I saw seemed to
>>>> focus only using QML to create interfaces from scratch, and that just
>>>> turned me off, coming from the widget-rich environment of Qt desktop.
>>>>
>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>

-- 
Best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180215/4037b977/attachment.html>