Technology Temple

Can you tell us please if it com­piles Qt appli­ca­tions alright?

I am con­fused — the only rea­son one would use C++ is per­for­mance, C++ devel­op­ment is sig­nif­i­cantly harder than JS, espe­cially since C++11, and trans­lat­ing C++ code to JS totally dimin­ishes the per­for­mance ben­e­fits. So why would any­one develop web appli­ca­tions in C++ and then con­vert it to JS? If any­thing, the other way around makes more sense...

You wish, Qt relies on a lot of APIs that are not acces­si­ble from JS. Plus it is a ginor­mous frame­work, it would take a lot of time to cre­ate workarounds for all of it...

You are one of the devel­op­ers? Just wanna make sure this is the sure answer to my question.

Emscripten can do this but the per­for­mance of the OpenGL appli­ca­tions is not that fantastic.

“Qt relies on a lot of APIs that are not acces­si­ble from JS” — this doesn’t really make sense. Isn’t all the code being parsed into JS? All the code Qt is using is C++, there are no closed source files, every code the Qt libraries are using is actu­ally open C++ files.

Qt links to many other plat­form libraries, some­thing that is not acces­si­ble from JS, at least not directly.

I haven’t devel­oped Qt itself but have devel­oped with Qt for years. While the intro­duc­tion of the Qt plat­form abstrac­tion inter­face did make it eas­ier to port Qt to sup­port new plat­forms, it still relies on native code linked to native plat­form spe­cific libraries.

Just head to gito­ri­ous and browse a bit through the Qt sources to see what I mean.

The C++ code is already writ­ten and peo­ple just don’t want to reim­ple­ment com­plex, highly opti­mized library code.
Also, you’re clearly out of the loop to think native code is still sig­nif­i­cantly more per­for­mant than good imple­men­ta­tions of JIT-compilers. Trash your books from the 90s and start read­ing the research papers from this cen­tury. Espe­cially the research at Mozilla (see asm.js). This is read­ily avail­able today.
WebGL is an API. It’s as native as OpenGL.

You’re miss­ing the point. This is use­ful to build new Web apps based on your work­ing C++ libraries, or to facil­i­tate port­ing your apps to the Web plat­form. Not a “throw your GUI app on this com­piler and it’ll reborn as an Web app”.
You can throw your com­plex C++ logic at it, like a dynam­ics lib, a scene­graph or a ray­tracer, so you don’t need to reim­ple­ment it in Javascript.
I’m pretty sure you can eas­ily rebuild your Qt GUI in html+css.

And the sur­vey says you are wrong! No amount of JIT-ing brings per­for­mance on the same level as native binary. Java comes clos­est but is still about 2 times slower on aver­age, same for mem­ory foot­print, JS is even worse.

WebGL is an abstrac­tion layer, and a poorly imple­mented at that, numer­ous tests show iden­ti­cal work­loads being sig­nif­i­cantly slower com­pared to native OpenGL. With time it may improve, but I wouldn’t be hold­ing my breath...

Com­plex and highly opti­mized code is exactly the kind of code that you will not be able to trans­late into JS. Only basic, self-contained code that doesn’t access hard­ware fea­tures or native plat­form spe­cific APIs has any chances of actu­ally work­ing after such a translation.

Fur­ther­more, what about main­te­nance? C++ and JS imple­ment OOP under fun­da­men­tally dif­fer­ent par­a­digms, and I really can’t imag­ine main­tain­ing such a code base to be a pleas­ant experience.

You should really do a lit­tle more research before mak­ing such arro­gant and erro­neous claims.

I’m sorry, I didn’t mean to sound arro­gant. You have some valid points. But not all com­plex C code need to access hard­ware or platform-specific APIs. Like I said on another com­ment, dynam­ics, scene­graphs, ray­trac­ers, are all com­plex in them­selves, and nobody wants to rewrite that. These per­form nicely in trans­lated Javascript.

I didn’t say per­for­mance would be on the same level. I said it’s not sig­nif­i­cantly dif­fer­ent. At least it’s not for many workloads.

Com­plex and highly opti­mized code is being trans­lated to Javascript for a long time now. It’s pro­duc­tion ready. hence Duetto’s com­ing out, but it’s not a new con­cept at all. It’s at least the 3rd imple­men­ta­tion I’m aware of, only for C++. There’s more for other languages.

WebGL is an API with many dif­fer­ent imple­men­ta­tions, some bet­ter than oth­ers. Many are sim­ple abstrac­tions over Direct3D and OpenGL like you said. But we might see it imple­mented as an OS-level API soon enough.

I don’t mean to sound arro­gant, but peo­ple have REAL uses for this, and you are the one who came to a release announce­ment of a real prod­uct peo­ple want to use and com­mented say­ing you see “no rea­son” and “makes no sense” to you. You also asked “why would any­one”, which I think I answered on my first com­ment. Again, I’m sorry for my choices of words, I’m not a native Eng­lish speaker.

So 2 – 3 times is not a sig­nif­i­cant dif­fer­ence? Maybe you won’t mind hav­ing your pay reduced 2 – 3 times then

Surely, it is noth­ing like inter­preted Python or PHP, but 2 – 3 times is still unac­cept­ably slow for core libraries. Most cer­tainly inap­plic­a­ble for trans­lat­ing a high-performance C/C++ library to JS, there is a good rea­son those libraries are writ­ten in C/C++ and only used by the lan­guage runtime.

I’d rather deploy a plat­form native binary to the client sys­tem and use that through JS, it is a far more effi­cient solution.

I am not native speaker too, and there is a say­ing in my native lan­guage “there is a pas­sen­ger for every train” and even though it is mostly used in the con­text of unat­trac­tive peo­ple find­ing mates, there maybe peo­ple who will find this use­ful, oth­er­wise it will be too big of a pity for all the efforts invested. Surely, LLVM did most of the work but still...

Man, it’s just a say­ing, not meant to tar­get any­one specif­i­cally. Don’t take per­son­ally every­thing you read on the Internet.

Code com­piled to asm.js on Fire­fox runs on aver­age 2x slower than native code today. And it is get­ting faster. It will even­tu­ally get so close you won’t tell the dif­fer­ence (except mem­ory use). Duetto is nice in tak­ing a dif­fer­ent, bet­ter approach to mem­ory use and still get­ting pretty close in performance.

Javascript VMs are not los­ing any to the Java or C# VMs anymore.

C++ is def­i­nitely used for per­for­mance rea­sons on tra­di­tional archi­tec­tures. But I would not say that is the _only_ rea­son to use C++. It is a lan­guage that scales, one that has actu­ally been used to develop com­plex, large scale sys­tems such as Oper­at­ing Sys­tems, game engines and... com­pil­ers for C++. Beside this, in our opin­ion there are many other rea­sons to develop web apps and games in C++:

-) Is easy to find expert pro­gram­mers which are pro­fi­cient in such lan­guage
-) The strict syn­tax require­ments helps you spot errors or poten­tial prob­lems before run-time.

-) Using a real front end com­piler makes it pos­si­ble to enable an exten­sive range of opti­miza­tion which low­ers the bur­den on the JavaScript JIT com­piler. More­over, the com­piler can gen­er­ate JS code opti­mized for each tar­get engine, sim­i­larly to the machine spe­cific opti­miza­tion used on reg­u­lar processors.

You talk about trans­lat­ing C++ code to JS, but I think you’re miss­ing a point here. Yes, Duetto trans­late C++ code to JavaScript, only because cur­rently there is no choice. We gen­er­ate JavaScript code which behave nicely with mod­ern JS engines, but we would be very happy to sup­port other, even more effi­cient ways to deploy com­piled code on the browser. The real prob­lem is that cur­rently Web APIs (offered by the browser) are tightly cou­pled with the JS lan­guage. We are try­ing to do decou­ple them and let peo­ple use a robust, proven lan­guage to pro­gram the absolutely awe­some plat­form that the Web is. JavaScript is just a mean to such end.

Well, get­ting Qt to work is def­i­nitely pos­si­ble, but it would require a port­ing effort sim­i­lar to the one required to bring Qt to a new plat­form, not unlike port­ing them from X11 to Win­dows. Still, I expect that low level parts of the library which depends less on plat­form capa­bil­i­ties could be portable much faster.