Qt or Phonegap



  • Both Qt and Phonegap are crossplatform frameworks. Phonegap usage is now widespread may be because of its support for html / css. What are the chances of Qt against Phonegap as a crossplatform mobile framework. Qt support for html5 is not as easy as its support for Qml.



  • I found this table "feature":http://phonegap.com/about/feature/ and must say unfortunately for now Qt not so powerful on crossplatform mobile area.



  • As of now Qt has no mobile presence. But this would change once the Android and ios ports are completed. I was wondering whether even after this, it will be difficult for Qt to catch on.



  • [quote author="qxoz" date="1361254328"]I found this table "feature":http://phonegap.com/about/feature/ and must say unfortunately for now Qt not so powerful on crossplatform mobile area.[/quote]

    Not so portable might be more accurate. But hey, what do you expect, phonegap is html. I never quite understood all this bragging about "cross platform applications" - it is html, what is so exceptional about it working on every platform that comes with a basic browser... Same limited performance, same limited features...

    Not to mention out of those many platforms, the only ones with considerable market presence are iOS and Android and to a lesser extent BB, all of which Qt will probably support by the year's end. Plus desktop platform support which seems to be lacking in phonegap.



  • Ok, so the features are there. How useable is the API?



  • Phonegap has a plugin interface available. Just about any native feature can be exposed via this and there are lots of these plugins. How good they work is questionable. Though Qt may be better, lots of people may choose phonegap because of the 'easy' and 'familier web technology' tag.



  • IMO the bar of what passes for an "application" has been lowered dramatically. There are even applications without an actual practical application. I guess that goes with progress, it was the booming availability of cheap mobile devices with limited screen real estate that mandated the introduction of "applications" whose sole purpose is to replace a standard website view, optimized for large screen desktop systems. And it is not like this cannot be achieved simply by using a different CSS file and some minor modifications in the html markup, but the evolving fandom has spoiled people into being whimsical and insisting on a visual representation their beloved company insists to be considered the best.

    So in the end we have tons of applications with limited to no application which rely on inefficient technologies and are huge resource hogs, which is a perfect match to an industry, eager to sell more and more. Bloated, slow and inefficient code is the perfect justification for getting a new, slightly better device, which the industry carefully releases in gradual, incremental cycles, so that whatever you get, it is trash you are ashamed to be seen with in 2 years.

    I really wonder what will happen in a decade, when semiconductor manufacturing process hits the physical limits and this vicious cycle cannot be sustained anymore. Thankfully, by that time we humans will have completely different things to worry about, such as fighting pointless wars for the last bits of fertile land and fresh water. Hardly anyone will remember the glorious days of blind, fanatical consumerism and scripting languages pimped into being dominant means of application development...



  • [quote author="utcenter" date="1361260136"] But hey, what do you expect, phonegap is html. I never quite understood all this bragging about "cross platform applications" - it is html, what is so exceptional about it working on every platform that comes with a basic browser... Same limited performance, same limited features...
    [/quote]
    Yes you are right, but why Qt tries evolve exactly in same way. I mean QtQuick apps also based on some kind of browser where runs QML. In that way in future Qt can lose its unique as native multiplatform tool and become one of many scriptable tecnologies.



  • ' Qml, a css and javascript like language '. Text taken from Qt website. The same reasoning. Its like css and JS. It should be easy. Don't know why, but everybody is feeling the need to support something like html / css and a ' modern ' language like Javascript.



  • I can tell you why: it is easier to work with designers that way. That is good to reduce time to market, which really is needed in this age of apps-for-everything, whether you like that or not.



  • Yes. That may seem a valid reason. But in our experience, these UIs that the designers create don't perform well like the native UI and they need lots of tweaking here and there to look good. So I'am not convinced. The moment you do something extra on these UIs, they become sluggish. I guess the major reason for using phonegap is that existing skillset can be used.



  • I would say Qt has good chances if use QML+C++ where pretty UI being created by QML and heavy calculations on native code, but i am not sure about that.



  • There is a difference, QML is only markup, JS is only used to glue things up. I myself am not a big fan of QML but it still allows native C++ extension. And don't get me wrong, JS performance is pretty decent compared to Python or Ruby, especially on V8 and with JIT, but I won't be comfortable implementing anything calculation intensive with it.

    I myself am fairly new to programming, used to be a designer for 5 years and video editing for another 4, and what would suit me best is a C++ API on top of the visual facilities of Flash. I've done some Flash development and I really like the capabilities as well as the visual editor, the only downside is ActionScript, which is a bad performer too, plus a few totally awkward syntax decisions and really annoying.

    I'd imagine a "Flash like" frontend with a public native C++ backend would make THE PERFECT development framework for me. I honestly wish I had the money to hire a team to implement something like that.

    And certainly not interpreted, I'd really prefer markup being used for native code generation rather than on the fly interpretation. It saves plenty of resources and improves start-up and performance. Interpretation may be a good option for prototyping, but in the final stage only platform native binary.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.