run JavaScript code on the server side of a Web interaction, rather than just on the browser side. That’s what Mojito is about.
The etymology explains everything. Lots of Web applications run partly on a server and partly in a browser. The code directing things on the server side, usually written in a language like Python or Ruby, is called a “module,” and the code executing actions on the browser side, usually written in JavaScript, is called a “widget.” Fernandez-Ruiz’s team designed self-contained packages of JavaScript code that can run on either side. They’re both modules and widgets—hence the name “mojits.” (Add some mint and lime juice, and it’s a short step to “Mojito.”)
The point of a mojit is that it can start running on the server side long before the code has been fully reassembled and executed on the mobile-browser side. Once the mojit finishes loading on the device, control is handed back to the browser, but in the meantime, the server sends the browser a low-bandwidth image—a kind of mirror. “We execute the same JavaScript on the server, render a page that is usable, and give that page back to the browser so that the user has something he can click on,” Fernandez-Ruiz explains.
The login page in Livestand is a mojit. So is the scrolling, 3D publication gallery. That means the app works seamlessly for users, no matter how much new content they’re accessing during a given session, or how good or bad their network connection might be. “We are shifting computation from the client to the server side, so your user experience as a whole is better,” says Fernandez-Ruiz. But the developer experience is also better, since mojits consist mostly of JavaScript, HTML, and CSS3 (the style sheets that control the look and formatting of Web documents). Only a few elements of Livestand are written in the iPad’s native Objective-C, Fernandez-Ruiz says.
Yahoo expects to open-source all the code behind Mojito “a few weeks from now,” Fernandez-Ruiz says. He says the aim is to allow other mobile developers to experiment with hybrid server/browser architectures and build smartphone and tablet apps that will run well even in parts of the world with poor wireless connectivity.
Chromeless Web Runtime
The second ingredient in Cocktails doesn’t have a brand name yet, which is why it’s currently going by the somewhat clunky name “chromeless Web runtime.” (In keeping with the cocktail theme, I suggest “Rusty Nail.”) This boils down to an effort to bypass the browsers baked into the main mobile platforms. On the iPhone and the iPad, for example, developers who want to include a “Web view” in their apps—that is, any browser-like page that calls information from the Web—are usually forced to use the mobile Safari browser that comes with iOS. That’s a frustration, says Fernandez-Ruiz, because “the browser environment is fully managed,” meaning the local operating system handles key tasks like allocating and deallocating memory. This is a key function on mobile devices, which, as a rule, have less RAM to go around than laptops or desktop machines, and third-party developers would ideally like to control it themselves, or at least have a better picture of what’s going on.
“Chrome” is developer-speak for the buttons, borders, and other common user interface elements in a browser or application window, but by extension it describes the whole relationship between a mobile operating system and its native browser. To create Chromeless Web Runtime, Fernandez-Ruiz says his team asked “How can we create a browser without a browser? In other words, a Web execution environment where you get a DOM [a document-object model], a JavaScript engine, all the stuff you would normally get with a browser, but you provide your own chrome?”
In Livestand on the iPad, when you think you’re opening a Web browser, you’re not actually opening Safari—you’re running Chromeless Web Runtime. The JavaScript in the mojit is being executed inside a
