The confusion may be ending, and Yahoo's Mojito may be part of the solution. Yahoo built Mojito by taking the best ideas from the various server stacks and creating a framework in JavaScript on top of Node.js, a server-side tool that might be called a cult. You write your code for both the server and the client in JavaScript, and Mojito keeps it working smoothly. (If you use some of the NoSQL databases, you can program them in JavaScript too.)
[ Also on InfoWorld: Node.js tools: Server-side JavaScript comes of age | First look: Google Dart vs. JavaScript | Keep up with application development developments with the Fatal Exception blog and Developer World newsletter. ]
Node can be incredibly fast, but it achieves much of this speed by operating without a safety net. If your code locks up, the entire server locks up with it. The most cultish devotees feel that this can be dodged with careful coding. Mojito encourages this care by offering the well-understood paradigm of Model-View-Controller, or MVC. Splitting the code into small distinct parts that serve predetermined roles makes it less likely that you'll lock up the server. That's the theory, but of course nothing can stop a determined programmer.
Mojito's MVC structure emulates the ideas and design paradigms that emerged from other Web programming worlds. The Java server-side programmers are so devoted to frameworks like Struts that you could get yourself stabbed in a Java bar if you even hinted that MVC is not right for all things. The paradigm succeeded because it brought some order and roughly approximated the way that development teams are organized. The people who are good with visual design end up in charge of the View; the people who organize the data (often DBAs) create the Model; and the programmers handle the Controller that makes decisions about what the data can do (the business rules).
Mojits and MVCThe Mojito framework makes excellent use of the MVC paradigm. Each Web application is broken up into mojits -- shorthand for Mojito widgets. Mojits are rectangular areas of the page that are meant to be fairly independent. You should be able to mix and match mojits if you're careful in your coding; you may also want to get them talking with each other.
 
 
Each mojit has its own M, V, and C, which are written, more or less, in JSON, HTML/CSS, and JavaScript respectively. The biggest difference from other MVC approaches is that the model and controller are split into three parts. One part has code for the server, one part has code for the client, and the third has code for both. All three parts live next to each other, not in different stacks maintained by different people. I think this will be a great improvement for development teams because it breaks down the silos and frees us from the need to maintain people with different focuses.
The documentation suggests that Mojito is quite smart about this: "If your application is configured to deploy code to the client, Mojito will determine whether the client can execute JavaScript before deployment. If the client cannot execute JavaScript, your application code will instead execute on the server."
There aren't many details on how to exploit this, but structure is there for you to separate the code as you need. You have to be careful how you use the structure, and in the spirit of Node, you do the work on your own -- it's up to you to avoid any traps. A mojit on the server won't be able to manipulate a DIV on the client, for instance. It's worth noting that one recent project, Opa, promises to use the compiler to make automated decisions about where the code will run, but that level of hand-holding isn't provided here.
The Mojito framework is also designed to be smart about devices; to be more precise, it's designed to help you deliver different code to different devices. If your website visitor is using a smartphone, for example, the framework can dispense a different View built with a different template and a different set of local functions. This device sensitivity is essential these days, and the Mojito team was smart to build it into the framework itself.
YUI on the serverA big part of the framework is the Yahoo User Interface Library, known as YUI. This is a well-known and copiously documented collection of JavaScript tools that began life manipulating DIVs on the client. Now with Mojito, you'll be configuring your server-side Node application by calling the same YUI object. Most of your server-side JavaScript code will call YUI's add method to link your functions to events. The YUI is now doing heavy lifting on the server too.
Your Web application's events and much of its structure are defined by JSON files. I guess these are a step up from the endless opening and closing tags in frameworks like Struts that were built when XML was hip, but I quickly grew tired of hitting those quotation keys all of the time. Someone is bound to write a nice Web interface to these files so that we don't have to add so much glue punctuation. One version of my code crashed until I counted the curly brackets correctly, a task made easier by a parser that issued intelligent complaints about the mismatching.
Your affection for Mojito will depend on your affection for YUI. It's much simpler to use YUI widgets in the layout of your Web page because YUI is baked into all of the layers. This is largely a stylistic decision because the YUI has most of the functionality you might desire. It's fully formed and ready to go. The look and feel, though, may or may not be what you like. Some people assert that Yahoo Mail is the best out there, but others disagree. If you like Yahoo Mail, you'll probably be happy with what you create with Mojito.
The Mojito framework is also a good way for Yahoo to extend the reach of its APIs. It only takes a few lines of code to issue a call written in the Yahoo Query Language (YQL), the lingua franca for accessing Web databases like Flickr. The other parts of the Yahoo empire, including Yahoo Maps and Yahoo News, take the same style query. If you rely on any of these APIs, you'll be even more interested in Mojito.
There are still some limitations. I wish Mojito had some coupling with databases because that's what many developers are going to want to do. Node frameworks such as RailwayJS and Locomotive offer Rails-like connections to traditional databases. If you want a quick CRUD scaffolding to create, update, or delete rows in the database, one command can build them for you.
Web apps without SQLThe Mojito documentation on data access talks about cookies and Yahoo Query Language, not SQL or NoSQL. The counter-SQL argument is that the data should live in its own realm in a JSON-compatible server that takes RESTful queries. The Rails-like integration is too much, and it shackles the developer. Leaving the database connection out of Mojito frees it.
The Yahoo team should forge a tighter alliance with the major NoSQL databases that speak JSON and JavaScript already. MongoDB, for instance, which takes queries in the form of JavaScript functions, is a natural partner. A difficult question is whether there also needs to be better integration with MySQL and other traditional databases. These continue to have strong followings, and if Mojito wants to gain access to shops with legacy SQL databases, the project will have to consider tighter integration. Or maybe they'll just insist that the legacy stores start answering RESTful queries with proper JSON.
Will Mojito succeed The speed of Node will continue to attract new experimenters who quickly discover they can't build an entire Web application in one file as many of the hard-core Node lovers do in their early demos. As soon as they discover that raw Node programming can produce inscrutable code that's nested in endless layers of curly brackets, they will be running to frameworks like Mojito. Mojito's structure and JSON configuration files unpack much of this complexity and spread it out over a number of directories and files. Some JavaScript programmers may be a bit put off by all of this atomization, but the structure has served the MVC community well over the years.
The flexibility of using pure JavaScript on both the server and client should also be very attractive. Several other projects, including Google Dart and Opa, are trying to create new languages that offer the same code base for client and server, but these approaches require learning yet another language. Mojito runs regular JavaScript, which will be handy when you encounter the weird, edge conditions of the language and need to program around them. There will be differences among browsers for the immediate future, and adding another language doesn't always smooth them over. Despite the improvements offered by the newer languages, most developers will prefer to write native JavaScript.
I think Mojito can have a long and happy life with Web developers who yearn for the structure provided by popular MVC frameworks but are tired of writing different languages. My guess is we'll go through several more rounds of cross-pollination among the various projects fighting for attention. Yahoo did a nice job of extending YUI to handle much of the work on the server. When deeper connections to the various data stores appear, we'll finally have a strong enough structure to build serious applications using only JavaScript.
This article, "Review: Yahoo Mojito gives server-side JavaScript a lift," was originally published at InfoWorld.com. Follow the latest news in software development, JavaScript, and HTML at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
Read more about application development in InfoWorld's Application Development Channel.