-
Notifications
You must be signed in to change notification settings - Fork 215
The Zen Of Mojito
My presumption is that the question of "What is the philosophy of Cocktails [Mojito]" is raised so you can help to understand what constitute "best practices" when developing for the platform and so you can ultimately try to predict the direction of the platform, how it's likely to evolve, and what it might look like when it becomes a fully-authentic implementation of its underlying philosophy. You want to grok "The Zen of Mojito".
Here it is:
It's Mojits All The Way Down.
The central philosophy of Mojito is that you create applications using mojits. That's it. In the "ultimate expression" of that philosophy everything you ever author is a mojit of some flavor.
Let's face it. We're not there. Today you have a few things in Mojito which are not implemented using a mojit pattern (middleware etc.) but, if you want to predict application authoring and platform evolution using your newfound understanding of the Zen of Mojito, you might want to predict that if it's not a mojit now, it'll likely evolve to look a heck of a lot more like a mojit. You might predict that if the current mojit design and API don't cover your common (80/20 => 90/10) use cases, it will evolve to cover them. And you might further predict that a platform built entirely around the idea of authoring mojits is a platform which will eventually cause a whole lot of mojits to be written, shared, tested, discarded, reinvented, refined, and distributed over time.
So we're gonna use mojits. Ok. Great. Rockin'. What the heck is a mojit?
A mojit is a fully-encapsulated, self-contained, asynchronous, MVC component.
Let's break that down.
A mojit is fully-encapsulated. A mojit is self-contained. A mojit is asynchronous. A mojit is MVC. A mojit is a component.
Cool. These are things we can use to begin to understand best practices for a Mojito developer. You can build mojits and check yourself against the philosophy by asking if these "rules" hold true for you:
- Since mojits are full-encapsulated you don't go poking around on their slots. You message them.
- Since mojits are self-contained they "collaborate" they don't "contain". Your mojits work in teams (via events).
- Since mojits are asynchronous you must develop in terms of callbacks, "promises", and events.
- Since mojits are MVC you can expect to find a "model", a "view", and a "controller" somewhere.
- Since mojits are components you can expect to use more than one, in fact a lot more, in an application.
These are useful tenets since they can help you answer questions about your work like:
Q. How do I share data between mojits? A. See Rule #2 -- put the data in an event and fire it. Mojits that care (i.e., have listened) will be notified.
Q. How do I manage session state? A. Today you do a nasty hack...but you can predict there may eventually be a...wait for it..."SessionMojit". Why wait, build it now :). A' How can I predict this? See "The Zen Of Mojito" aka "It's mojits All The Way Down" aka "What's missing today will be a mojit tomorrow."
If you find yourself violating any of the previous rules you can pretty much bet that you're a) overlooking something, b) doing it "wrong" in a "Zen Of Mojito" way, or c) working in an area where a new mojit is needed. During these early days, there's admittedly a lot of "c" happening but check yourself against "a" and "b" and hit the mailing lists/forums before filing a ticket. The key point is that with the entire development community focused on building a single thing—mojits— we expect most gaps to be closed pretty quickly.
BTW, point #3 above is a direct result of Mojito's deployment target environments. On the server side, Mojito runs on Node.js (whose philosophy I'd argue isn't "keep it small", I'd suggest it'd be more correct to say it's "It's Async Everywhere—Build Accordingly". Big or small, if you build something for Node.js that ignores an async-everywhere philosophy you "did it wrong". But back to Mojito :). On the client side, Mojito runs in Web browsers where asynchronous events from the user and/or server drive how things work. Both server and client are async, so mojits are asynchronous.
Ok, so I lied. It's not really "Mojits All The Way Down." Eventually you'll hit things like "middleware" and other "system components". When you do, and you need them to adjust to your needs, you'll find yourself wanting to create "addons".
In any system there are always some components which are built in, things that just "come with". In Mojito, the one you'll interact with constantly is the ActionContext (AC), but there are others.
Mojito isn't intended to be a "closed system" which you can't adjust—just the opposite—Mojito is intended to be a system you adapt to meet whatever evolving needs your applications may have. So how do you "adjust" Mojito's built-in components to meet your needs? You use an addon.
Addons are mixins for system objects.
Addons are collections of methods and attributes (aka properties) that Mojito will apply on your behalf to specific objects in the system. This approach lets you adjust and/or augment the system behavior upon which your mojits depend. At the present time, addons are used almost exclusively to augment the ActionContext...but the philosophy of Mojito with respect to customization, and hence with respect to addons, is that you can augment anything.
Long-term you can expect Mojito to evolve such that you will be able to define addons for every system component—at least all those that wouldn't open the system up to potential security issues. And you can expect any current inconsistencies you might find in how addons are organized or applied to be addressed as we migrate to a fully unified and universal addon implementation. (The same can be said for mojits).
Now, given that Mojito thinks in terms of extending behavior via addons, Mojito does NOT rely on JavaScript inheritance for customization. This is by design and likely to remain true—even though there are a few areas where you might see value in the introduction of an inheritance hierarchy.
So, to summarize, you create new "non-core functionality" by creating mojits and you adapt "core functionality" using addons.
Admittedly, as an industry we've been trying to build "Software IC's" since the early 80's at the very least—and mojits could be considered just the latest in a number of attempts to solve that problem.
And admittedly, the leveraging of HTML5 (and all the things which aren't strictly part of the HTML5 specification but which are lumped in just for the fun of it like CSS3, etc.) isn't "new" either. Our entire industry is "going HTML5" whatever that means to the speaker and listener at the time.
We could say something shallow and market-driven based on the fact that Mojito does it using a single language on both sides of the wire. A language which runs in the most ubiquitous virtual machine ever deployed—the JavaScript virtual machine you'll find in every web browser regardless of whether it's in a desktop machine, phone, tablet, kiosk, or refrigerator. Something like "We're the only platform to...." ;)
But there are numerous other platforms going "All JS". Mojito is not the first, nor will it be the last.
So what's truly new?
If there's anything "new" or "magical" in Mojito, it's the combination of the vision for mojits and the vision for automatic management of mojit resources.
A mojit is MVC. So we've got a Model, a View, and a Controller. And we've got all the "assets" related to those three primary components. CSS files, images, static JavaScript includes, template files, etc. And we need all of them to be in the right places at the right times, on the client, on the server, or both. And we'd like them to be context-sensitive in terms of their device targets, languages, packaging, and delivery. This is where the ResourceStore steps in.
The ResourceStore is the heart of Mojito. Without it your mojits and their assets don't end up in the right places at the right times in the right configurations. The ResourceStore reads your configuration data from various JSON files and uses that metadata to help it determine how to construct and deploy your application components (aka resources).
The ResourceStore is also, IMHO, where this whole "Write Once, Run Anywhere" noise around Cocktails/Mojito comes from. And that's unfortunate since it misses the entire Zen of Mojito to say it's about Write Once, Run Anywhere (WORA). The ResourceStore isn't about WORA, it's about smart deployment of resources appropriate to the context. That does NOT say "Write Once" although it does shoot for "Run Anywhere".
We've all seen that WORA simply will not work for anything complex.
Imagine writing Eclipse in a browser. Can it run without code changes on your iPhone? Should it? How about the iPad? When it runs on a 13" Macbook Air should it show you the same display, run the same models, use the same controllers, as when it runs on a desktop with a 30" Cinema Display or a pair of 24" monitors where you might want to work on 2 screens at once? No. And Mojito MAKES NO CLAIMS TO THE CONTRARY.
What Mojito DOES claim to do is to make it far easier for you to manage the complexity of developing for the plethora of modern deployment targets, to do it using one language (JavaScript), and to do it with one, scalable, conceptual framework for your work (Mojits/Addons/Assets).
Mojito does all this while also providing you with a set of command-line tools to help optimize your development workflow.
One of the things Mojito provides, which also isn't "new" but it's certainly very handy, are tools specific to creating, testing, debugging, and deploying your Mojito applications. These tools are collectively bundled into the "Mojito CLI (Command-Line Interface)" and many of them make use of the same resource management metadata Mojito uses at runtime. They're "Mojito-aware" so they give you a high degree of leverage.
Current example CLI commands include:
mojito start // start the mojito server
mojito lint // run jslint on the code
mojito test // run unit tests on the code
mojito build // create a deployment package mojito create // create a new Mojito application, Mojit, etc.
As Mojito evolves, you can expect to see these tools evolve as well so that you can count on Mojito to provide you with a single, unified, development system.
So that's the vision. The "Zen Of Mojito" or the Philosophy if you will.
As many have commented on this thread, there are some warts, some big, some small, but all of which I believe take focus away from the goal state the Zen of Mojito implies/promises. Binders and MojitProxy are a good example.
In today's Mojito client-side development, you have an awareness that you're talking to a proxy. You shouldn't know that. In a pure implementation, you'd ask for a handle to an object, the model, the view, or the controller, and you'd get an object back. You'd message it. You'd fire events. It'd "just work" and you'd move on. Today you get a MojitProxy or a "binder". You invoke(). You're forced to be aware of intimate details of the fact you're not really talking to the model, view, or controller. THAT is "leaky abstraction". The abstraction Mojito wants you to have is that you're working with a Model, a View, or a Controller. Those three are what a mojit "IS". You should be able to move the Model, View, or Controller around between client and server and just keep writing identical code. Today you see these other things called binders and MojitProxies. Those effectively leak where your Mojit is running...and that shouldn't happen. Trust me when I tell you those are not what! we think you'll interact with when Mojito is fully authentic.
Today you may be forced to write middleware (usually to work around session, request, and page state storage concerns). You shouldn't have to. You should be able to accomplish your goals by configuring a set of middleware/filters which do what you need and at most using an addon or two for some light customization. Of course, the middleware stack is very new so it's not covering the 80/20 or 90/10 stuff completely yet. But that's truly a short-term concern. Mojito development is NOT going to demand that you consistently write something other than mojits and addons when Mojito is fully authentic.
There are other less obvious examples, but I hope I've done a good job in giving you a better sense of the concepts that drive Mojito's future design, and what those imply for your development today and moving forward.
Thanks for listening,
Mojito Uchi-dechi
March 2012