Porting QML to JS/HTML5

  • Hello everybody,
    I have recently started a project aimed at porting QML to JS/HTML5, so that a plain qml file can be rendered directly on a web browser.

    A small proof of concept is hosted here:

    Don't be shy! I'm looking for comments and support!


  • and a signal slot system between qml on the client side and the server app done in Qt ... and it rocks :)

  • I just test it. It's nice but you have a lot of work to do.

    It would be nice if you can port my qml+javascript application to html5+javascript .

  • Yes, true! There is huge lot of work work to do ;-)

    The small example posted is just an hack to prove to myself it is possible and valuable and to collect ideas and comments. Next step will be to organize the work and write a roadmap.

    Useless to say that volunteers are so welcome!

  • Have you looked at backbone.js? They've got a lot of stuff about binding to property changes, that might be useful.

  • Not yet: it looks interesting, in particular the model view. As to property binding, I prefer my hand crafted solution since it is more close to QML behavior. In fact in QML you state that a (sink) property is binded to one or more other (source) properties. For example

    QML: x: z+w
    JS: x : new Binding(["z","w"],function(){return z+w;})

    On the countrary backbone bindings let you bind a (source) property to other (sink) properties.

  • Would be nice if those binding dependencies (z,w in the example) could be calculated automatically, but guess that would require access to the JS parser. I wonder if somebody made a JS parser in JS, could be useful to automatically convert from QML

  • Yes, I agree with you and it is how is implemented the javascript core of the QML interpreter. As you suggest, my idea is to write a QML parser that generates the JS equivalent of the QML file, and I hope to write it in JS too.

  • I've been coding QML engine for Javascript/browser, too. It currently has quite bizarre --though working-- binding and scoping model and some classes implemented partially, for demoing. Text, Rectangle, Image, MouseArea, Timer, SequentialAnimation, NumberAnimation, and their parent classes, to be exact.

    I also started implementing QML parser on top of parser from UglifyJS (yes, there are JS parsers made with JS, see crockford too). It can now parse the most basic stuff and is very prone to infinite loops :P

    Engine is bit ahead of parser currently, and to play with it, you can try feeding parse tree for it (think JSON while writing it). Parse tree is intermediate format between the parser and the engine. Bindings in tree can be made with QMLBinding. Currently works with Opera and Chrome. Firefox works almost but it doesn't count length of text (in Text element) correctly, should be easy to fix.

    Developer testpad is available at http://lauri.paimen.info/pub/dev/qmlweb/test/testpad/testpad.html (works in opera and chrome). Source is minified, sorry. Please remember it's in alpha stage. You can try adding QML to textfield and parse&run it with "Run as QML" button. Alternatively, you can put parse tree to textfield and run it with "Run as parse tree", as the QML parser is not yet very advanced.

  • So wonderful! Exactly what I have in mind. Is it a public project? I would really like to contribute to it.

  • It is a hobby project initiated by the other guy and mostly coded by me. We are idling at #qmlweb on ircnet. One of the targets is to publish an article of the effort, which we are on currently (the deadline is in 2 weeks, all too soon). Currently the sources are not publicly available.

  • Yesterday (it's now morning in Finland) I added support for element methods as shown on example1.qml. It will take this week to finish the paper (the deadline is on Monday), after which I'm hoping to update the project to support Firefox, too...

  • Good morning! Nice to hear you will finalize the paper: I would be glad if could you send me a copy of it.
    As to the project, are you going to open it to external contributions when the paper deadline is over? Since I am interested in the matter, I would like to know if I have to keep writing my own solution, or if I can help you on your code base. Obviously I would prefer the second option: I think it is stupid not to join our efforts.

  • The paper is now done, I hope the reviewers like it.

    Some other project news:

    • The project will soon be open to contributions. I'm still figuring out what is the right license for this. GPLv3 perhaps.

    • Firefox is now supported. There is still minor issue with calculating text height, which is approximated in FF.

    • New QML Viewer page, which simply runs the QML given to it. Essentially it is Testpad with cleaned up UI. The neat thing about web implementation is that you can stretch the render surface to fit your screen without affecting the QML app, making it easier to deploy QML apps to different resolutions on web.

    • I also made a presentation about the project. The slideset is actually a QML application (who needs powerpoint anyway), and as we now have QML Viewer, you can view the presentation with it at http://lauri.paimen.info/pub/dev/qmlweb/test/testpad/viewer.html#../presentation.qml . If you want, you can download the qml (and two images it uses) and run it in native Qt QML Viewer, too.

    • Most of development tests/examples are now converted to QML (from parse tree). The examples are listed on (redesigned) testpad at http://lauri.paimen.info/pub/dev/qmlweb/test/testpad/testpad.html

  • Quite impressive!
    One small glitch that I noticed in your presentation, is that it seems to flicker at the beginning of a transition to the next or previous page.

  • True.

    Drawing, timing and animations were using independent timers resulting to rather undeterministic behavior. Now those all use tick from the engine, currently set to 25fps. AFAIK this is the approach of native QML engine, too. Animations now run "better" -- not faster as in fps, but faster as in real time/impression, as they now animate against the actual time elapsed and thus follow the duration given to them. Implementation also simplified a bit.

    Syncronizing Timer with the 25fps (40ms) ticker may break "high-frequency" Timers expecting 60fps (16ms) resolution, but that is really an issue of QML Timer specification. And well, there's nothing stopping to make the ticker 60fps, just sed "s/fps=25;/fps=60;/" qtcore.js

  • The weather in Finland has been so excellent that not much has happened to my effort lately.

    Anyways, I created a gitorious project so feel free to check the code out at https://gitorious.org/qmlweb (we discussed with zanettea and decided not to use his repository).

  • it rocks !!! I hopes that it will evolve ... seems very promising !

  • I wonder if this could be combined with QtGui in html5?

    You can see a demo of it at


    It's part "v3c-storyboard" (I couldn't call it "storyboard"
    because of a name clash) in Sourceforge.

    Comments welcome.

  • Depends. This far I've managed without, as the elements have been rather simple. However, if/as it gets more complicated in the future, middle layer may pay off. And more Qt-like, the better.

    I took a quick glance to the sources, and there was also Qt's signal-slot and event systems implemented. That's something I had on todo-list before rewriting binding code...

  • Well, then sooner or later we're going to have to take this to the next level and get a bit more organized, so the following issues have to be addressed.

    1. Where to host (I guess gitorious is the logical choice)
      This should also include showcase and doc web pages.
    2. What to call it/them: QtHtml5Qml, QtHtml5QtCore, QtHtml5QtGui
      seem over the top - any better names?
    3. I've namespaced everything under Qt, is that too much?
    4. (eventually) enable QtWebkit/Qml to step in with "real" c++
      implementations, even avoiding downloading the .js files whose
      functionality it replaces.
    5. Collaborators! I for one would love to hand over chunks of work
      (like the layout classes for starters) for willing participants.
    6. Implementation coverage charts / progress
      Thinking of "Uno", it's nice to see what features are done,
      todo, and tested as percentages. This means project planning,
      tools and an interface.
    7. Qt5 - should we aim for that exclusively?

    And of course anything else you can think of, insert/replace above.

    I've created a thread called "QtHtml5Script anyone?"


    as QtGui is something that might be of interest in its own right.

    I think following the Qt hierarchy/model is the most sensible


  • Sorry, when I said "uno", I really meant "mono" - see


    for some ideas.

  • I created a project in sourceForge called "qtjs".


    I also created a thread with the same name here.

  • Great!

    I'll probably borrow (rip off) some code there :P

    Just have to check that BSD and LGPLv3 are somewhat compatible.

  • Hmm.

    I think that QtJs would be useful in it's own right.

    I would suggest keeping them separate, just like they are (will be?) in Qt5 for that very reason.

    Also, the code available will change a lot until I get the fakery^W implementation layer into a better state.

    I'm working on that now, so borrowing and then modifying the code would not be a once-off.

    I thought that if I wanted to include the QtScript generator examples then it would have to be GPL as well.


    I sent an email about this issue to Nokia and am awaiting feedback.

    Yep, I just realized that I've got to change all those LGPL lines to GPL in the source, thanks.

    Finally, do give me profs when you embed a copy of the software in your project, like you should for any GPL project.

    Oh, and did I mention, collaborators welcome?

  • QtJs is useful on its own, but it also is useful for qml project. I've already forked UglifyJS code to the project to gain a Javascript parser. The preference (for bug fixes etc) is the original code/project, and keeping files borrowed to qml project somewhat up-to-date with the original.

    I am not a lawyer, but I don't see the GPL of qtscriptgenerator examples forcing you to use GPL on QtJs, as the examples can also be ran on qtscriptgenerator environment. Again, IANAL.

    I'm all for GPL. If you wish to enforce principles of RM Stallman, I guess the right license would be AGPLv3 with "any later version" and http://www.gnu.org/philosophy/javascript-trap.html clauses.

  • "I am not a lawyer, but I don’t see the GPL of qtscriptgenerator examples forcing you to use GPL on QtJs, as the examples can also be ran on qtscriptgenerator environment. Again, IANAL."

    It will if I want to package them with QtJs as examples.

  • Yeah, it's about packaging. Assuming QtJs works without the examples, you can deliver two packages with different licenses. I guess these can be even served from same svn repository as long as the file clearly indicates to which package/license it belongs. For qml project, I've BSD-licensed all the core parts (files in src directory) and the rest of the files (test files in test directory) are, well, unlicensed. I think those could be also licensed to some other license, though in the end, it may also be court/lawyers to decide.

    Now stopping the off-topic license speculation from my part.

  • That JavaScript trap link you posted got me to thinking.

    If I'm going to write a facility that can substitute native code for a JavaScript url (or several) then it could be put to use to allow arbitrary substitutions, as the link describes.

    Maybe this could be a general purpose plugin that can have wider applications.

    I'll start a thread called "JavaScript override" to discuss it.

  • While taking a break I read up on the SVG specification.


    I'm not QML savvy, but does it have anything in common with SMIL?

    Would "porting" it there make sense?

    I'm thinking of porting QtJs there too.

  • Have you looked at emscripten? http://emscripten.org/

    It's a c++ to JavaScript converter!

    I posted a message to the blog site about QtJs http://syntensity.blogspot.com/2011/07/emscripten-15.html

    I hope this helps.

  • Any progress on this???

  • Sorry for leaving this to stagnate.
    I'm not in the loop regarding QML, but "Qt for Google native client":http://qt-project.org/wiki/Qt_for_Google_Native_Client is the way I'm going.

  • As for the qmlweb project (porting qml to standard web browser), the project has been semi-active for a while now. It recently got second contributor, so it's not just me anymore. More developers are of course welcome.

    You can run very simple QML apps with the engine, but it is not yet production quality. It supports standard browsers (most post-IE8), and works for example on PS3 and iPad browsers.

    Demo app -- slides written as QML application -- is available at
    and code from

  • @lpaimen I'm writing a QML app and it will also have an HTML5 version. A tool like this would be so handy. I'll have to check it out and possibly contribute.

  • @trusktr Well but that would be excellent! I've been slow with this project but Anton (co-dev) has been steadily contributing improvements here and there. Since November he has been reworking bindings/property system, introduced DOM-based rendering frontend, support for Repeaters and so on, all kinds of exciting and neato stuff.

    But still the code ain't ready. The best way to get going is probably scratch your own itch -- try your QML app with the qmlweb engine and see what is missing and start hacking. Then just drop us a mail and we add you to qmlweb gitorious.org team to get your code into mainline :P

  • Sweet. Was it rendered in canvas previously? If so, 2D or 3D context?

    Just an idea (not sure if you already considered it) but perhaps the qmlweb renderer can be written using mrdoob's three.js (http://threejs.org) .

    Using three.js would mean that the qmlweb renderer could be written in a single code base using the three.js drawing API. Someone using qmlweb could specify for qmlweb to use the Canvas2D renderer, the WebGL renderer, or the CSS3D renderer. The internals of three.js would handle how stuff is rendered in each mode. All we'd need to worry about is writing the qmlweb renderer using the three.js drawing API.

    Here's an amazing WebGL example:

    An amazing Canvas2D example:

    and an amazing CSS3D example:

    2D stuff (e.g. for user interfaces) would basically just be done by creating a camera that doesn't move. It can be aimed downward facing the X-Y plain at 90 degrees, then 2D objects can be drawon on the XY plain, while giving them Z values that have tiny differences from each other to create layers. E.g. Z=0 for the base layer, Z=0.00001 for the next layer, etc.

    Using three.js would then mean that the 3D parts of Qt QML could also be rendered. 3D effects could also be added to "2D" user interfaces (e.g. new screen could zoom in or out, anything you can do with the QML 3D stuff).

    There's also the pixi.js library, that specializes in 2D graphics and uses WebGL for hardware acceleration, with a Canvas2D fallback for deices without WebGL. This might be easier to use initially for QML 2D interfaces, but it might be a barrier for 3D QML.
    There's plenty of other 2D libraries: http://stackoverflow.com/questions/11456758/is-there-at-two-js-counterpart-to-three-js

    What is your thought on using a library like three.js for rendering?

  • Update: I just discovered "asm.js":http://asmjs.org/.

    So what does this mean for Qt on the web?

    It means you'll be able to compile your Qt apps for any HTML5 browser, taking advantage of WebGL for hardware acceleration.

    What is asm.js?

    asm.js lets you compile C++ to JavaScript (using only a subset of the JavaScript language). Firefox's new OdinMonkey JavaScript engine is designed to read the subset of JavaScript that C/C++ apps are compiled to, and will compile the JavaScript to an assembly like machine code right in your browser, so JavaScript apps compiled from C/C++ can run a lot closer in performance to native apps, all in your browser.

    Apps compiled with asm.js run up to 500% faster in OdinMonkey than in Google's V8 using Ahead of Time (AOT) compiling instead of Just in Time (JIT) compiling (but it's only a matter of time before Google comes out with their own competitor to OdinMonkey).

    As a proof of concept, the Unreal engine has been ported over using asm.js. Try the amazing "demo":http://unrealengine.com/html5.

    Here's "Qt AnimatedTiles":http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-examples/animatedtiles.html running right in your browser (but not using WebGL).

    @lpaimen, what are your thoughts on this? It might be easier to go this route.

  • On some recent changes, Qmlweb project is now a KDE playground project, the latest code being at https://projects.kde.org/projects/playground/www/qmlweb . Anton has taken over the project (I didn't find time).

    Anton is also doing a presentation of this project in Qt Developer Days 2013 (in Berlin). If you are going, remember to check it out!


    When apps need some rectangles, texts and images -- maybe with rotation at most -- DOM does OK. DOM additionally provides a input that supports copy&paste. DOM or 2D canvas does not drop my eyes with greatest 3D transitions ever invented. On other hand, I get a good feeling when I get HTML5-capable device into my hands and the stuff runs there (even remotely). Device like PS3, N9, iPad or IE.

    WebGL/three.js have their strengths and weaknesses. If QML apps need the strengths and don't mind the weaknesses, using these serve the project well.

    I think the strengths of WebGL/three.js are the graphical capabilities and the weaknesses browser support and input element.


    Unreal engine demo is amazing yes. I got it running only on FF but it made me forget it is running in a browser. That is a good thing for a browser demo.

    Qt AnimatedTiles worked in Opera as well, downloaded about 10 seconds and started up in like 5 on my laptop. The performance was OK (~15fps) on Chrome. I wonder what numbers would be with qmlweb or standard HTML5 approach.

    Emscripten+asm.js (recompiling Qt to JS) is easy route, I think someone should take it and come up with results on running QML with it. Initially it might not perform very well but there will be plenty of low hanging fruits to optimize. Eventually it might perform OK. The codebase will be big due to compilation. Also, the more you depend on speedup provided by asm.js, the more you depend on it breaking into browser mainstream.

  • Hey guys, Hey guys!! So Famo.us 0.3.0 is coming out this month (http://famo.us). The goals of the project are amazing. Basically they've created a scene graph for the web. The version after 0.3.0 will blow your mind, mixing regular DOM with WebGL shaders...

    Anyway, I think that QMLWeb can take some inspiration from what Famo.us is doing, and if it did, and competed with Famo.us, QML for the web would drastically increase exposure to Qt and do huge things for the world.

Log in to reply

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