Yahoo!’s Mojito is Now Open Source


I'm psyched to announce today the availability of Yahoo!’s Mojito in open source, a ground-breaking JavaScript framework developed by Yahoo! for Web developers. Mojito is one of the Yahoo! Cocktails, our JavaScript-centric presentation platform for connected devices.

Notice how I said Mojito is targeted at Web developers. Why? Because we strongly believe in an open, unencumbered Web at Yahoo!. The ubiquitous World Wide Web that is present anywhere, and accessible everywhere.
By releasing Mojito to the developer community we are looking to enable digital media developers to build higher-end mobile experiences faster – leading to better consumer engagement and better advertising impact to unlock more market opportunities.

Tough Choices

If you want to build apps that reach all your customers, anywhere and everywhere, this might ring a bell. Today you have to make hard choices, mutex choices – I hate those. Build a desktop Web site? Build a mobile Web site? Build an app? Translation: an iOS app? Or an Android app?

Mmmmh. Must I pick one?

Here’s an idea: build a standards-based application, and tailor it to the device it runs on. Make it degrade nicely, on all the devices. Easier said than done, for sure, but having a solid framework in place helps a lot. That’s Mojito (and YUI3).
We’ve been working with Mojito for a while internally, building hybrid apps like Yahoo! Livestand. Or Fantasy Finance, a Web site. Or Fantasy Premier League Football, a mobile Web app. All three are built using Mojito because it lets you develop one codebase for any type of device. Think of the reduced effort!

I had a dream: a client+server framework

JavaScript frameworks are nothing new. We know there are already a number of them out there. However, Mojito brings something new and unique to the table.

  • Mojito is all JavaScript, that's good. JavaScript is the single most widely available programming language today, and that's something worth taking advantage of.
  • Mojito is a true MVC framework, that's better! MVC is a battle-tested design pattern, having proven its usefulness in desktop apps, in server-side apps, in, today, rich client-side applications. Those who ignore MVC... often reinvent it.
  • But the best part of Mojito is its ability to "blur" the client/server boundary, to let you write code that runs on the client, or the server. Or both.

Huh?! I hear you say. Hear me out: Mojito apps run on the client, using the client's embedded JavaScript engine. But Mojito also runs on the server, on NodeJS. Node is great, and we love it. Node’s focus is on efficient low-level constructs for I/O, while Mojito is about providing application patterns to help you structure your code, to make it more modular, more concise, and perform better.
Cool stuff, right? But we have a grander vision for Mojito. Think about it: having the ability to run JavaScript code on either end, we’ve built a framework for both. A framework that hides (a little, not too much) the execution site. A framework that lets you assemble and render data on the server, or, well, on the client too!

I really like this post by Eric Florenzano because it exemplifies the potential of what we’re doing: What “if we wrote our JS libraries so that they could run either on the server or on the client, and they did so in a transparent way”?

“Imagine a framework where the first page-load was always rendered server-side,” and desktop browsers subsequently “just made calls to API endpoints returning JSON or XML, and the client only rendered the changed portions of the page.” Mobile browsers with less power render on the server. And imagine that the app could “dynamically switch between rendering on the server and client, based on server load, or client speed”.

Pretty nifty, huh. This is what Mojito is built for.

Something else we've been thinking a lot about at Yahoo! is the notion of runtime context. The runtime context is e.g. the data connection available to your application, its speed and bandwidth. On Wifi you can do a lot... But if your user walks out to the parking lot, how's your app going to react?

Peak mitigation is another example of this: how do you degrade nicely in the face of spikey traffic? Or what to do if the device your app is running on is nearly out of power? How about shifting some of the power-hungry operations to the server, to save a precious few minutes of battery life? Bet that would make your user happy.

Interesting problems!

Control Tower to Mojito: Time to Land

To be fair: Mojito doesn’t do all of that today. That’s why we decided to open source Mojito. We want to help develop better standards for high performance Web apps, and mitigate partial connectivity issues using a – this is the most important part – non-proprietary solution.

To get there we need your help! Go to GitHub today and experiment with manually specifying which parts of your Web app run where (we call it the affinity: client or server or both).

To recap: you want to write an app for the largest audience, wherever they are. Using Mojito, you can write an app that adapts to different devices. Not only in terms of presentation, but also in terms of computation, i.e. some processing can be done on the server, or the client, up to you.

I had a glimpse of the future, and it had a minty taste: learn more about Yahoo!’s Mojito and join us on GitHub to make it do more.