Hacker News new | past | comments | ask | show | jobs | submit login

I wish it to be true :)

Disclaimer: I didn't feel the user experience you described. (and have a lot more experience with XUL than QML)

What I experienced is that actual performances of crossplatform "runtimed" toolkits are enough for desktops and acceptable for mobile devices, but the global overhead (compared to a binary using native OS widgets) exists, beginning with startup cost, memory consumption, i/o latency. In fact, the same constraints that VM-based languages have. And even more : the underlying GUI toolkit may be used in an unexpected way, strange GPU driver behaviours may pop up, how not to be bothered by OS fragmentation. And then an application may run flawlessly on a device with a given OS while on another it performs not that good.

While I think it's correct to say that VM-based languages does not have to blush in front of compiled programs when talking about raw computing performance, my experience (as an ex XUL-lover, I may be biased) make me think that this is still not true when UI is involved. Java has maybe the oldest (and most optimized ?) runtimed UI, and it does not convince me. OK, this may be a bad example : Java UIs are "runtimed" at a different layer. but seeing the length of the QML performance wiki page is a bit scary :)

Maybe the "1% overhead" is an unreachable dream, and maybe the native apps will become deprecated, but I think there are a place for improvements. How many attempts of crossplatform UI runtime exists ? Not that much. With hardware improvements, the overhead will be more and more acceptable. It s a huge work, and previous errors should be looked at (rant time : Mozilla: you should not have stopped to use native widgets - Adobe: Flex - QML: mimicking web dev like XUL did is nice !).

Though, I am really impressed by Qt and .Net SDKs and I would really love to see more free software and linux surprises from Microsoft with the Xamarin acquisition.

And, let's be utopic, the future is maybe about a standard API à-la POSIX for end-user applications, where OS vendors will agree on an app, and natively implement their own <button>, their own <menu>, their own <video>. They do if for the browser, for the "webassembly", why not for the OS ? Or the browser will be deeply integrated in OS and the "web" apps will replace all native applications. Or they'll still coexist for years.

OK, anything but embedding a webview would please me :)




I got lost at the VM references.

XAML engine is native C++ code, no VM. Since Windows 8 there isn't also a VM as such on the .NET side, given the AOT compilation support.

Similarly QML is only interpreted in the free version. Commercial Qt compiles QML into native code.


Yes, the java comparison is not really good, I wanted to make a "runtime" analogy. I didn't know for compiled QML.


You can read about the QML compiler here

http://doc.qt.io/QtQuickCompiler/


I believe it's more correct to say that the creation of the QML object tree is compiled to C++. The rest of it is byte compiled JavaScript.


"Compiled Qt Quick is an elegant solution to these problems: .qml files as well as accompanying .js files can be translated into intermediate C++ source code. After compilation with a traditional compiler, the code is linked into the application binary. This entirely eliminates the need of deploying QML source code, it reduces the application startup time and allows for a much faster execution on platforms that do not permit Just-in-time compilation."

http://doc.qt.io/QtQuickCompiler/


So the JavaScript is compiled to C++? They implemented emscripten?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: