Because it’s small and tastefully efficient.
There are already so many JavaScript frameworks out there. These are designed especially for desktop Web development by eliminating for the end user the myriad of browser quirks and differences. It’s hard to imagine doing desktop Web development without using one of those libraries There are also a number of frameworks designed for mobile Web development. The funny thing, though, is that they use desktop frameworks with add ons for mobile Web development. After using several of these and noticing how much unnecessary baggage was there because of the desktop heritage, I decided to create a framework that was specifically optimized for mobile Web app development. ChocolateChip has no desktop baggage. It has nothing, zero, zilch, nada in it for IE, Netscape Navigator, nor 1 .x or 2.x versions of desktop browsers. ChocolateChip instead utilizes the features available in the modern mobile browser engines used in iPhones, iPads, iPods and Android devices. We’re talking Webkit here, and that’s a good thing.
You know what I’m talking about, like when you want the first or next sibling element and you get an empty text node, or not, depending on the browser. ChocolateChip uses DOM level 3 methods, objects and properties to make DOM traversal easy. I know, you’re going to ask about the selector engine. We don’t need no stinking selector engine. Waste of code. I feel like laughing when I read that a framework’s selector engine is being updated to work with mobile. I have to repeat this, you don’t need a selector engine. You have something better that’s built in. That means it is faster than any selector engine could ever possibly be. It’s called querySelectorAll. It takes as its argument a valid CSS3 selector. Because ChocolateChip uses the browser’s native querySelectorAll feature, you can get elements in this way:
var firstPara = $("#intro p:first-child"); var para5 = $("section > p:nth-child(5)"); var evenItems = $$("li:nth-child(even)"); var externalLinks = $$("a[href$='.php']");
As you might have noticed, the markup looks like jQuery or Prototype. This is on purpose. ChocolateChip has two way of getting nodes. When you want to get a single node, you use the $() method. This will always return the first instance of the selector supplied. When you want to get a collection of nodes, you use the $$() method. This returns a collection in the form of an array, even if it has only one member. jQuery rolls the functionality of this method into the $(), whereas Prototype and Mootools keep them separate. After a lot of consideration, I decided to keep them separate. I didn’t want to do looping on collections behind the scene. I want you, the developer to know what’s going on with your code. The goal of ChocolateChip is to eliminate as much obfuscation as possible.
jQuery wraps everything up in the jQuery object, requiring that you use only jQuery methods on all returned nodes. ChocolateChip returns either a single node or, in the case of a collection, an array of nodes. This means that you can use normal JavaScript on everything that ChocolateChip returns. So, if you decide that you don’t want to use a ChocolateChip method, you can use whatever JavaScript you want to write and mix it in wherever you want with standard ChocolateChip methods.
Rather than writing methods to implement missing features in browsers, I use the native methods already implemented in Webkit. And, although my goal was to make a framework for mobile Webkit, it also works without modification on desktop versions of Safari, Chrome, Firefox and Opera. And as far as IE goes, you can forget everything before IE9.
But then, that’s the whole point. ChocolateChip was not written for desktop browsers, it was written for mobile browsers. If it happens to work for desktop browsers, fine. I will not, however, add code to ChocolateChip just to make it useable for desktop development. That’s not its purpose. Yet I will be looking to see what I can add to ChocolateChip to enhance its usefulness for mobile Web app development.
Because ChocolateChip’s purpose is for mobile, size is of supreme importance. To restrain it’s size as much as possible, I was forced to limit what I put in it. Due to the memory constraints of mobile Web app development, having a smaller framework means having more memory for the content in your app. Running out of memory will cause the mobile browser to crash. Do you follow what I’m saying? You want that framework as small as possible. And ChocolateChip fits the bill well. It’s just 8k when minified.
But if you are really determined to eat up valuable browser memory by using some other framework that also uses $ and $$, you can customize ChocolateChip to use whatever you want as an alias. If $ and $$ are already in the global name space, ChocolateChip will assign its versions of these to __$ and __$$. This is indicated below:
if ((!window.$) && (!window.$$)) { window.$ = $; window.$$ = $$; } else { window.__$ = $; window.__$$ = $$; }
In such a case, you can reassign __$ and __$$ to whatever other aliases you want to use. You would do this at the start of you own document inside the $.ready() block:
$.ready(function() { window.choco = window.__$; window.chocos = window.__$$; });
This allows you to write choco("p:first-child");
.
ChocolateChip is available in three flavors, dark (with full comments), regular (with comments removed) and light (minified). If you’re new to ChocolateChip, by all means download the dark version. Crack it open and read the comments. They explain each method, what arguments they take, what they return, syntax, examples, etc. If you’re in development and you want to be able to troubleshoot exceptions in your browser’s Web inspector, you probably want to use the regular one. And when you’re ready to go into production, you want to switch over to the light version. You can get them all from ChocolateChip’s online GitHub repository.
To see examples of what ChocolateChip can do, visit http://www.css3wizardry.com. That site has numerous posts about how to built out various mobile Web controls that work like native controls on the iPhone, iPad, iPod and Android platforms.