Bringing C++ to the Web: some background on Duetto


logo_duetto_quadrato_192

While I am a big-time fan of C++, I don’t go so far as to say it’s “the best pro­gram­ming lan­guage ever, period.” As an engi­neer, still, I really believe it’s an extremely effec­tive tool for proper pro­gram­ming. Fans and advo­cates of more dynamic pro­gram­ming lan­guages such as Python, Ruby and JavaScript typ­i­cally con­sider C++ a bor­ing, ver­bose lan­guage with a pedan­tic com­piler that never stops com­plain­ing about seem­ingly unim­por­tant details.

Well, if you ask me, that is the most rel­e­vant fea­ture of C++. I don’t see it as a lim­i­ta­tion, but as a frame­work that helps struc­tur­ing my ideas into machine com­pat­i­ble form. Over time I have grown to appre­ci­ate that the C++ com­piler is a programmer’s best friend.

More recently I’ve also become fas­ci­nated with the incred­i­ble progress that browsers ven­dors have made in bring­ing standard-compliant mod­ern capa­bil­i­ties to the gen­eral user. While HTML5 can­vas and WebGL are def­i­nitely the most vis­i­ble addi­tions, we should not for­get about local stor­age, pro­gram­matic audio sup­port, video sup­port, web sock­ets and every­thing that is being stan­dard­ized. This exten­sive fea­ture set is amaz­ing and, to me, this depicts a future where almost-native appli­ca­tions and games are avail­able on every sin­gle plat­form through browsers.

So far, tak­ing advan­tage of the great plat­form that the Web is, has required pro­gram­ming in JavaScript. JavaScript is ter­ri­ble. I am no JS ninja, and I find it incred­i­bly frus­trat­ing hav­ing no hint about what kind of thing will be passed as an argu­ment of a func­tion, or if any­thing at all will be passed, for that mat­ter. How some peo­ple can build and effec­tively main­tain a large-scale code base in JS is beyond my com­pre­hen­sion. I am sure many devel­op­ers feel that same way that I do.

So we have some pretty awe­some Web APIs, tightly cou­pled in a pro­gram­ming envi­ron­ment that, to me, looks like a joke. Since that sounds like a prob­lem to me, and I like to solve prob­lems [1], I decided to bring my lan­guage of choice, C++, to the Web platform.

My solu­tion was to write duetto, a C++ com­piler for the Web. With a cou­ple of friends, we are try­ing to build a com­pany around it.

duetto is a C++ com­piler for the Web, not for JavaScript. Most of the work involved in writ­ing duetto was related to find­ing a way to gen­er­ate good JavaScript from C++. To do that, we wrote a spe­cial LLVM back­end, based on a cou­ple of (hope­fully) clever tricks. But we did that only because we had no choice. JavaScript is cur­rently the only prac­ti­cal way to deploy code to browsers. But in our vision JS is only a mean to our goal of enabling C++ as a pro­gram­ming lan­guage for web apps and games.

What we want to do is to pro­vide a bet­ter pro­gram­ming lan­guage for the Web, to take the most advan­tage of all the fan­tas­tic under­ly­ing tech­nolo­gies such as HTML5 and CSS, which do their job more than well. With duetto, design­ers can still work using tools they know, while devel­op­ers can write a sound appli­ca­tion logic in robust C++ code. And, by the way, we are not try­ing to pro­vide an half-backed wid­get library that would always be lag­ging behind what browser APIs can pro­vide. With duetto you access the browser directly, with no need of any mid­dle layer.

One of the intended uses of duetto is to port exist­ing C++ appli­ca­tions, espe­cially games, to the Web. But we also want to make it a pri­mary choice to write new web apps. One of the require­ments of mod­ern apps is con­tin­u­ous com­mu­ni­ca­tion with remote servers, for exam­ple to receive other users’ updates. This is why we have also intro­duced an exper­i­men­tal sup­port for trans­par­ent RPC to server side code.

Call­ing this RPC is actu­ally kind of lim­it­ing. Our objec­tive is to pro­vide a seam­less expe­ri­ence to make it pos­si­ble to write client and server side code in the same code­base and let the com­piler gen­er­ate the two sides of com­piled code. Take a look at some exam­ple code.

We are all stand­ing on the shoul­der of giants. In our case the giant is the LLVM/clang project. Gen­er­at­ing JavaScript required some improve­ments to the com­piler core that we hope to include in the upstream projects. LLVM pro­vide a large array of opti­miza­tions passes on code gen­er­ated  by clang, which means that JavaScript code reach­ing the browser has been already heav­ily opti­mized, low­er­ing the bur­den on the JS engine. In gen­eral, the JS gen­er­ated by duetto tries to play well with mod­ern JS engines, by pro­vid­ing hints that should make it pos­si­ble to gen­er­ate good native code. Cur­rently the code is generic, but we plan to explore the pos­si­bil­ity of gen­er­at­ing code tai­lored for each JS engine (e.g. Chrome’s V8 or Mozilla’s Spi­der­Mon­key). In the end this would be not dif­fer­ent from the CPU spe­cific opti­miza­tions that are avail­able on reg­u­lar architectures.

The release date for duetto is now get­ting really close and we are really excited about ship­ping it and see what peo­ple can do with this tech­nol­ogy. If you want to take a pre­view please visit http://leaningtech.com, there are still a few slots open in our extended beta program.

[1] Maybe I like solv­ing prob­lems too much, I wrote Lightspark because Adobe’s Flash Player was too slow in ren­der­ing full screen videos of kit­tens on my workstation

  • coldev

    SDL , SDLMIXER, LIBPNG, ZLIB ope­source LIBS are sup­ported ??? to fast port­ing process how emscripten?