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.
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?
Heres 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. Thats Mojito (and YUI3).
Weve 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
- 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.
I really like this post by Eric Florenzano because it exemplifies the potential of what were 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.
Control Tower to Mojito: Time to Land
To be fair: Mojito doesnt do all of that today. Thats 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.