I'm not sure whether I should be impressed, consterned or scared.
It's the sort of things I would love as a developer (Hey ! Portability! Less code to write ! awesome mature toolkits !) and I would never want as an user ( Hey ! It's the same as old Qt apps, except five time slower !).
Is everyone today equipped with at least 4-core 3GHz i7s or what?
Text Edit demo is barely responsive on my Athlon 64 X2 4600+ in recent Google Chrome beta (25.0.1364.84) on up-to-date debian wheezy. To the point it's unusable, unfortunately.
I admire the project, it must have been a great fun to build it and it is impressive achievement. Really!
I still hope it may be optimized more, so it will be truly responsive. Even then it doesn't mean it's the right way to go. Web developers, please, do not write your websites as Qt apps to compile them later with emscripten-qt!
It is not optimized at all yet - still using software rendering in pure JS. Will be more interesting with hardware acceleration, I intend to work on that with the author of these ports.
Interesting. I did find it pretty fast or I wouldn't have written that. I was using Chrome 24 on Mac OS X 10.8 on a 2010 i5 MacBook Pro, so my computer is definitely not the latest and greatest. I guess there must be some difference between the rendering engine on the Mac and on Linux, but I don't know enough to say what.
Well, this is no more than a showcase. On my fairly modern computer with powerful graphics card it is unbearably slow even in Chrome, while remember, Qt used to run on embedded devices with no hardware acceleration whatsoever . Everyone and her granma is excited about web technologies, but this is not the future I want.
Native Client approach is a lot more promising, despite not being welcomed well in the industry.
it might be more of a canvas issue than anything. emscripten gets some good results most of the time (something like 10x speed down compared to g++ -O3).
Canvas (and webGL notably) support is there, but its super flaky and hard to make fast.
And at which point in history 10x speed down has become acceptable? In certain industries people are trying to squeeze the last bit of performance out of their code, fine tuning cache usage, SSE and whatnot. I just don't see it as an innovation in technologies, quite the opposite in fact.
Remember Emscripten is not the last word, it only demonstrates such translators are possible, and I believe is still the only such example thus far. Given a small team the experience might be significantly improved, especially considering Emscripten works by translating LLVM bitcode, even though a less lossy source translation approach may be possible.
JS might be the first 'architecture' for which standard C's pointer arithmetic and casting restrictions get put to truly good use.
When comparing to other portable systems (python, for example), it's "pretty good".
Plus all the messy porting of C libs to different platforms go away (you just need one SDL-to-canvas wrapper instead of 5 different implementations). It allows for a concentration of effort.
It sure may be, but JavaScript can't be "extremely" more portable than, say, C++, since all JavaScript engines with majority market share to date are implemented in C++.
Also its portability is not an inherent property of JS, it is because of the history.
...but the problem is that relatively few business GUI applications do nothing. The front end has no purpose other than to trigger some kind of backend action, or update some database, or read some data from some source and display it.
...and that backend, non-QT code, which talks to system libraries, is never ever ever going to compile to javascript.
So other than tech-demo, what's the use case for this?
To answer your question, I'm not sure what is the use for this, since you know, it does not compile to coffeescript /sarcasm. But in all seriousness, I did not post this to advocate it's use, but because I found it somewhat strange.
I'm not dissing this project; I think the c++ to javascript compiler is really neat.
I just don't think I've ever seen any real QT applications that would compile and run with it; they all talk to databases or system services, which isn't supported.
Good news for browser centric thin clients/devices, I suppose. There was a lot of criticism of devices, particularly Chromebook, that rely on the cloud; that you're fairly limited by what you can reach via the browser. Well, it looks like you can reach a lot more now.
I hope we can look forward to getting rid of pointless apps that are forced on you just to read a web page though. That's really, really annoying.
Because you can write web applications without having to use crippled, half baked JS frameworks. GUI programming was solved over a decade ago. The things we do in the browser these days, in terms of complicated web apps, mostly consist of reinventing the wheel. Backbone, ember, knockout, etc are all toys with missing wheels in comparison to a serious GUI toolkit. In contrast, Qt is well tested, very well designed and elegant. It's been around since 1992 - 21 years old!
Porting 'legacy' QT apps with too much functionality in the QT bits to a browser hosted environment could, I imagine, form a case in favor of simplifying software delivery. (That, or forcing a desktop upgrade to i7's. Think of the kickback opportunities!)
In practical terms, most of the publicly available stuff is demos. It's easy to create demos of open source projects and publish them immediately.
It takes longer for commercial codebases to be ported, pass all the stages of productization, and be officially launched. My prediction is for a few such projects to show up later this year.
With that said, there are some uses of emscripten that are not demos. For example emscripten was used to port the crunch decoder to JS in gl-matrix, and that might well be used in non-demos. Also there are educational sites using compiled languages like repl.it as another commenter mentioned. I've also seen a few other practical uses, e.g. of sql.js in sqlfiddle.
It doesn't have to be commercial to be more than a demo. Sql.js was a great concept but hasn't been updated in 10 months (unless there is a fork that is maintaining it), even though it has major issues.
I know you Mozilla guys don't have time to maintain ports, but are you doing anything to encourage open source devs to actually use and maintain this stuff? I'm working on an emscripten port of a game myself that I do want to actually maintain and improve upon, but I get the impression that I am in the minority.
> I know you Mozilla guys don't have time to maintain ports
I used to have time to maintain at least sql.js, ammo.js and box2d.js, but recently work on asm.js and some porting projects has monopolized my efforts I'm afraid. My hope is people that use it will maintain those.
> but are you doing anything to encourage open source devs to actually use and maintain this stuff?
Do you mean ports like sql.js and ammo.js that I began, or new ports people make?
I don't know how to encourage people to work on my ports - either they do or they don't ;) I ask for help and mention the projects, but it's up to people to be interested of course.
Regarding other people's ports, I definitely try to support them as much as possible. Fixing bugs that those ports encounter is always high priority for me.
> I'm working on an emscripten port of a game myself that I do want to actually maintain and improve upon, but I get the impression that I am in the minority.
There are a few serious/long-running ports, like jsmess and nebula3. But most ports are more short-term: they accomplish the goal, and then not much is left to do.
There are also commercial emscripten ports, but most commercial work by nature is secret until it launches.
I'd love to see a (either ported or native) Unix in javascript that can run all these ported programms. I know emscripten already does have a filesystem and stuff. But I mean something bigger, something with filesystem backends for webdav and local storage, a shell, process management and all the usual stuff. I'd be a victory over the walled garden, because today everything speaks javascript.
No, thanks. I'm already frustrated by all the crappy "native" (non-ported) javascript applications that never work as expected, so let's not keep adding to this.
It's the sort of things I would love as a developer (Hey ! Portability! Less code to write ! awesome mature toolkits !) and I would never want as an user ( Hey ! It's the same as old Qt apps, except five time slower !).