Linked by Thom Holwerda on Mon 9th May 2011 21:14 UTC, submitted by Elv13
Permalink for comment 472544
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/19/13 23:02 UTC, submitted by M.Onty
Linked by Thom Holwerda on 06/19/13 22:28 UTC
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
More News »
Sponsored Links



Member since:
2005-11-29
QML sort of lets you have your cake and eat it too. You have full access to the native platform on "metal" level (C++ & Qt), while allowing you to write as much of the code in "scripted" environment on QML side.
I don't see how you're eating your cake too, when Javascript is a typeless language, which can lead to all sorts of weird quirks when unexpected things happen.
It's a much neater concept than e.g. with C# / Silverlight, where you are forced to write almost everything in C# - and C#/CLR is still not "low level enough" when you really want that (to conserve RAM, hand tuning the algorithms to optimize cpu cache use, whatever).
I don't know, the CoreCLR in Silverlight 5 is pretty damn fast now and is still tiny. In fact, last time I checked, the CLR's JIT engine still outperformed Javascript JIT engines.
If most of the time is spent in QML/Javascript, I don't see how you can claim the performance benefits of being "closer to the metal" while using an interpreted/JIT'd language.
I'm not sure if QML is interpreted or if its compiled to an intermediary language (XAML on WPF is compiled to BAML a binary representation, and XAML on Silverlight is interpreted)