Duetto (C++ for the Web) available for download: limited public beta


logo_duetto_quadrato_192Did we ever tell you that writ­ing a full-feature com­piler is not a job for the faint of heart? Dur­ing the last cou­ple of months we have been march­ing for­ward in our quest to bring a great, seam­less C++ pro­gram­ming expe­ri­ence for the Web. And we see vic­tory at the end of our journey!

Duetto is our clang-derived C++ com­piler which makes it pos­si­ble to really trans­late the value of C++ to Web pro­gram­ming. What we want is for you to be able to reuse your oh-so-hard-to-reimplement C++ code (like sim­u­la­tion libraries, or physics engines) in your shiny new HTML5-based app or videogame, with no need of rewrit­ing it in JavaScript. But not only.

We are aware, of course, that there are already other solu­tions, such as Emscripten, to solve this prob­lem. What makes Duetto dif­fer­ent is that it is a C++ com­piler with a C++ mindset.

We believe that the strength of C++ comes from enhanc­ing the plat­form capa­bil­i­ties, with­out try­ing to hide the lim­i­ta­tions from the devel­op­ers. In Duetto, JavaScript is our machine archi­tec­ture and an HTML5 browser is our OS. Our tool com­piles stan­dard, com­pli­ant C++11 code to JavaScript and exposes all the awe­some HTML5 fea­tures of mod­ern browsers, includ­ing WebGL. There is no mid­dle layer, no inef­fi­cien­cies, no cus­tom half-crippled wid­get library. You write you web page in HTML and CSS, and code the logic with C++. We truly believe this is tak­ing best of both worlds.

We have worked long and hard to pol­ish Duetto and we are now almost sat­is­fied by its capa­bil­i­ties and robust­ness. We are now ready to share this tool with the first 100 devel­op­ers that are going to share their inter­est, in order to col­lect the most feed­back and pro­vide the best pos­si­ble sup­port and experience.

Inter­ested in try­ing out Duetto for free? Visit http://leaningtech.com to get your copy.

If you’re not one of the 100 lucky beta testers, do not despair. We will be releas­ing Duetto in roughly a month. Just enough time to ham­mer out some bugs, add some more awe­some­ness and fig­ure out last details on our licens­ing model. Duetto will be released under a dual licens­ing scheme, so it will be an open source/free soft­ware project, avail­able for any­one. We will also be offer­ing paid com­mer­cial licenses for peo­ple which are not com­fort­able with free soft­ware libraries and/or want enterprise-grade support.

UPDATE: I for­got to link the incred­i­bly awe­some demo by Daniele Di Proi­etto. He used Duetto to port his own imple­men­ta­tion of the “Not tetris” con­cept to the Web.

  • http://www.kubuntu.org/ Lil­ian A. Moraru

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

  • John

    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...

  • John

    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...

  • http://www.kubuntu.org/ Lil­ian A. Moraru

    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.

  • John

    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.

  • Jonatas Esteves

    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.

  • Jonatas Esteves

    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.

  • John

    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.

  • Jonatas Esteves

    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.

  • John

    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...

  • Jonatas Esteves

    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.

  • apig­notti

    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.

  • apig­notti

    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.