Not having to rewrite applications for Web, iOS and Android fat-clients is one of the holy grails for development organizations. Google have a shared-code approach that is worth understanding, and some appropriately sized companies should consider copying it. Google’s Garrick Toubassi, has a perfectly concise blog entry on it, and some of the Inbox-team developers discussed the technologies on a Reddit interview/IAMA thing.
Thomas Broyer points out to me that that Closure compiler is the crucial piece of the toolchain for the Web client, and that it is compilation not transpilation that the team use for the process in question.
The shared code amounts to 70% of the code for each client. The other
30% (including view logic) would be idiomatically correct
(platform-native) for the client technology in question. E.g. for iOS
that’d be the products of Interface Builder and XCode. I’m not sure what
the web app uses for the rest of the UI logic. While I prefer the
AngularJS way of doing things, the Inbox team is already invested in GWT and the Closure compiler for the
transpilation compilation, and there’s a greater capability with that technology. My memory of GWT though, is that it is harder to test with Selenium (divs without a predictable means to locate them).
All three sets of source, whether shared or unshared are in the same trunk.
The server app
The backend was written once of course, deployed once (horizontally), and shared by all the clients. It could be Java, but that’s not certain, as Google might have also made it in Go (or C++ if they consider this a heavy-lifting service which is unlikely).
Shared code elsewhere at Google
Watch all of Jeremy Manson’s presentation at the JVM Language Summit in July, as there a lots of interesting nuggets in it. Given the context of this blog entry, the detail we’re interested in is that Google is keen to make C++ interoperation with Java much better. In particular it is much more debuggable. You could write shared code in C++ and use it in an iOS, Android or Web application. The trouble is that would have to be a Web 1.0 application, as you can’t invoke C++ code in browsers (at least in a cross-platform way), meaning you’d have to leverage it in the server-side web app. Inbox’s UI is certainly a push-the-bar Web 2.0 app, for the web deployment.
Dropbox on sharing code
Dropbox uses some shared C++ code for it’s Android and iOS clients. Their strategy could allow them to target the “Windows Phone” platform another day too. Unfortunately C++ can’t be used easily in a web browser version of the app. Dropbox is such a specialist app, that they might be able to convince end-users to install a plugin though.