Experimental Qt and QML in the browser | Hacker News Reader

Experimental Qt and QML in the browser

dragly.org

58 pointsingve20 comments

It is definitely an amazing achievement to make a behemoth like Qt run in the browser, but at the same time it's also the worst case: a huge C++ code base with everything and the kitchen sink, built for traditional, big UI applications, which is already a big download if installed traditionally, in the end used just to get a few button on screen ;)

As a modern alternative, there are new, very slim immediate-mode UIs for tools out of the game industry which might not look quite as shiny, but render UIs very efficiently, with very little code to write and execute. For instance this dear imgui emscripten demo is a 325kByte download (1% of the Qt demo! and it gets smaller if you don't use all the different UI elements):

http://floooh.github.io/oryol/asmjs/ImGuiDemo.html

The UI is rebuilt every frame, and easily running at 60fps with very few drawcalls.

And people are doing amazing things with it:

https://github.com/ocornut/imgui/issues/123

https://github.com/ocornut/imgui/issues/539

Huh, I was surprised how smooth the imgui demo was on mobile (firefox on android). Much nicer than when people try to do similar with Dom elements.

Yes, but probably also very demanding on the battery.

Do most CRUD apps need to run at 60 frames/sec?

That IMGUI demo is awesome. I'd love to be able to drive it from regular JS, it would be really handy for all sorts of things.

It should be possible (and relatively easy) to wrap it into a module that's callable from Javascript, similar to what Alon Zakai has done with the Bullet physics engine (https://github.com/kripken/ammo.js/).

"Just be aware that the size of the examples is quite big because no optimizations have been done to reduce the size of the binary JavaScript."

The size is about 30MB, how much smaller would this get? Even a 50% shrink would be rather big.

There are still plenty of people who work behind a screen and a keyboard, with a hard disk of 500GB and connected to their LAN only... For those 30Mb is just nothing.

I know. I write web-apps for such people.

It still bothers me that things are getting so big :D

Look at it this way : the future of technology is (most of the time) to help people accomplish necessary (or new) tasks in an easier way. As someone who likes to program, future is : - network with infinte bandwidth - a computer with infinite memory and infinte speed (or, even better, a future when the programmer is vital but doesn't have to write code anymore :-))

So don't bother, just wait for it :-)

Having started programming on an Apple 2+ (64kb ram), I know what I'm talking about :-)

haha, sounds like the answer to the question "Why do applications get slower with time?" is wiz21c ;)

Blog post author here. I don't know how small it can become because I haven't looked into optimizing for size yet. However, we can look to the native Qt libs to get a ballpark answer to your question. I just tried gzipping the binary .so files of QtCore, QtOpenGL and QtQuick on Ubuntu and that takes up 3.9 MB. That is likely a theoretical lower limit of what needs to be downloaded by the user, but I don't think we can expect anything close to that after compiling to JavaScript. Perhaps WebAssembly will help reduce the size in the future.

In any case, I wouldn't exactly recommend building a blog using Qt this way. If you want to try building websites with QML, qmlweb is much better suited. I rather expect Qt+NaCl/Emscripten to be useful for larger browser applications, like 3D graphics software, games, scientific simulators, and so on.

In my experiments I found that gzipped asm.js is in the same ballpark as gzipped 64-bit x86 code. asm.js might come out 10..20% bigger, but not more. The absolutely important point is to make sure that the download is compressed (web servers typically do this for .js files).

There is a static size overhead of up to a few hundred kbytes for C/C++ runtime code which needs to be included in the asm.js file, and which normally lives in system dlls when running as native code, but this can be optimized by trying to minimize the use of C++ (e.g. iostreams introduce quite terrible bloat, better to just use printf). A lot of work has gone into emscripten to optimize the output size, also very recently (e.g. a linker pass which scans the code for duplicate functions and removes them, which sometimes helps for code which makes heavy use of templates).

Would dead code elimination be an option, if you are not using all of Qt?

In principle, yes, but I don't think Emscripten can do anything automatically the way things are now. The QML sandbox requires that almost all of QtCore and QtQuick is available because almost all code can be called by the user at runtime. Manually removing code you know is unused might be possible, though. I think I might have heard of some third-party tools that could help with this.

Chrome latest, I was unable to load any of the examples, not sure if it is a bandwidth issue or a javascript one though.

Aside from gaming, emulation and co , what are the business cases for emscripten ?

Blog post author here. It loads pretty fast for me, so I guess the problem isn't bandwidth. If you see any errors in the console (right click -> Inspect -> Console), please let me know.

As for business cases, I'm personally working on a couple of simulator front-ends in neuroscience and materials science that can be made more easily available by distributing them in the browser. If not the full version, a demo could be made to show the features. Also, I find it easier and more fun to make interactive illustrations for education in Qt/QML than pure JavaScript.

This is an amazing demo. The performance is very smooth on Firefox 45. The animations are beautiful and editing the QML and running it is a lot of fun. Thank you for such a great port.

Thanks for the kind feedback. I really only put the icing on the cake, though. The real credit for this port goes to msorvig and the other contributors. And of course to all Qt contributors who have made this amazing framework easily portable to new platforms.

qmlweb mentioned in the article seems more interesting

https://github.com/qmlweb/qmlweb

Reply on news.ycombinator.com