Hacker News Reader

Comment by nakkiel | Hacker News Reader

    In Qt 5 the entry point for applications can be QML instead of C++.                                                                                                   
    We expect that all UI will be written in QML. JavaScript will become
    a first class citizen and we expect that a lot of application logic
    will be written in JS instead of C++.

This is very worrying. They are basically moving from being a tool to being a platform or a beast of that sort. They are going to adopt V8 too. It all shounds like they are trying very hard to be the next cool thing. In other words, they are building a totally different beast and risking they fanatic user base.

In the end, I'm under the impression that there's a brillant guy who has been recently hired and who is backed by the execs. That guy came to the office one morning with his 7 pages "technical" proposition (because the guy has a bit of technical background, y'a know) and said Qt was cool stuff but he had a vision for the app^Wproduct.

Or.. they are trying to kill Qt.

Oh, and I'm disappointed.

View on HN

Qt has been a huge platform for some time now. It's what I call the Boost syndrome: if you want to use a small part of Qt, you have to shove your whole arm in the machine.

This should get better in Qt with the big modularisation effort that's happening.

QML is the logical progression for UI/UX design. Its going to make it easier to build innovative user interfaces and I fully believe you will still be able to build apps that look and feel just like the traditional QWidget based interfaces we have today. You can see this in some of the examples posted on the Qt Developer blog.

I lead the frontend development for a very large (and successful regardless of what the press says) command and control system. We completely decoupled our UI from our logic years ago into config files, and use QtScript for GUI events. This allows us to deploy on a large number of form factors with a single code base. Performance has not been effected as the logic is still C++. QML will be a huge improvement over that because it makes it so we don't have to manually build effects using QPainter, QGLWidget, or QGraphicsView.

I understand being resistant to change, but I am 100% behind them looking forward, building for the future, and not just assuming we will to continue doing things the way we do now.

I think it's a logical progression. In the future, all UI scripting will likely tend toward JS. After all, it's what the front-end devs know. It's easier to learn for 'artistic types' than C++, Web frontend devs know it, and ActionScript is also JS-ish these days.

Note though, that you don't have to use the scripting framework. You can define your GUI simply in C++ if you want.

Point of clarification: ActionScript and JavaScript are both dialects of ECMAScript.

Now, it isn't just that JS is easier to learn for 'artistic types', but it really is a quicker development process than traditional C++. My worry would be performance, just like everyone else. If you have already decided that a web application isn't good enough, why are you going to be okay with the JS penalty?

For the performance-critical parts you can still use C++. A web application does not allow that. Heck, as I said in my grandparent post, you can still use C++ for everything if "JS is not good enough".

Most people in the real world care about development turnover time. And as you say, developing in Javascript is a lot quicker than in C++, so why not write the non-performance-critical parts in JS?

Funny enough, I have written a piece of a web application in C, connected by JNI. It's even easier with CPython. Certainly, you can't do that with client-side JS, but could you imagine mixing desktop-side JS and C++ in the view?

That said, the piece that is in most need of performance in a desktop application is often the GUI itself. Imagine Microsoft Word taking a split second more when it updates the ribbon, for example.

Perhaps there is an exception for desktop apps that need direct connections to hardware.

Games have used scripting for GUIs forever. If performance is important somewhere it's in games. So I wouldn't be worried at all if it is used for "boring" desktop apps.

As long as the drawing is fast (which is the case, as it is handled by the GPU), it really doesn't matter in human time whether it takes 0.01ms or 0.001ms to react.

Reply on news.ycombinator.com