It all started with a simple DOM library for mobile use. I named it ChocolateChip, because I liked chocolate a lot and because if was really small.
On this blog, one post after another, I created prototypes of how to replicate iOS with markup, CSS and some JavaScript. After many posts I had the makings of a framework. These were all random, so I needed to bundle it all together. ChocolateChip was the glue, so I named the framework ChocolateChip-UI. That was six years ago.
As time passed, ChocolateChip-UI grew to accommodate new layouts, widgets and support for Android and Windows Phone, and could switch out to use jQuery. And then we made jQuery the default. So many changes…
Recently I was thinking about where to take ChocolateChip-UI. It seemed like it had everything it needed. I went and got some specialty chocolates and some good coffee and sat down to brood. I thought about the difference between Backbone and Angular. Backbone at least had models, where as Angular does not. Because of that, Angular has to run constant polls to compare the state of the raw JavaScript objects. The more you use Angular’s data binding, the more polls you have going and everything starts slowing down, especially on mobile.
In a system with models, it’s the model’s responsibility to inform the system when its data is modified. The system does not need to be running polls to observe the model. It should provide encapsulation and abstraction, protecting data from accidental modification by the system/developer. And so, I began tinkering until I had a model. I created some uses for it, fine tuned it, added some more features, etc. It was an object factory that returned a new model instance without having to use the “new” keyword.
I was pretty happy that ChocolateChip-UI would now have a model, but that got me to thinking – maybe ChocolateChip-UI could use a controller module too. So I looked at how the competition was dealing with controller behavior. And, in the end, I decided to take a completely different approach. I was creating a framework for mobile apps. These have unique challenges because they are mobile. So decided to base this work around the concept of mediators. These sit in the middle of an app’s interactions, like this image:
I used ChocolateChip-UI pubsub methods as the basis for my mediator module. But mediators have a number of unique features. You can control how many times a mediator can run or when it can run. Then I went back to my model code and updated it so that a model would automatically notify the mediator layer that it had changed. Like the model, this was also an object factory reusing the same pattern.
So now I had a model-controller for ChocolateChip-UI. I had always thought of ChocolateChip-UI as just a view. But it was a very passive and disconnected view because it had nothing built into it to enable working with other MVC frameworks. This meant that to use these required various workaround. It was not optimal, but it worked. I started thinking that maybe I could create a view module in the same way that I had create the model and controller modules. My idea was to enable a more component like pattern. I popped out the template parser from ChocolateChip-UI and put it into a new object factory. The object that this created knew about an element that it was associated with. This would be the container for any template rendering. It would automatically parse the element’s child nodes to extract a template. Or you could define a template in the view’s initializer. And you could define events in the view. And finally, you could bind a view to a model.
In the background the code would generate a mediator that would listen for any changes to the bound model. When a change would occur, it would update the rendered view.
So, I now had a model view controller framework. They had no dependency on ChocolateChip-UI. At the moment they were running on top of jQuery. While I was creating these modules, I kept comparing functions to mechanical ones. So, when I was done I realized I had something totally different from ChocolateChip-UI. It was time for a name change. I thought about vehicle names, but in the end I settled on TruckJS because trucks are powerful, they can carry heavy loads. You can count on trucks.
I then though I’d give a shot at rewriting ChocolateChip using the new patterns I used for TruckJS. But I was going to do one important thing. The new DOM library would be identical in API to jQuery so developers wouldn’t have to learn anything new to use it. In the end I had a DOM library less than half the size of jQuery with 90% of the functionality. But instead of the old Ajax syntax, I used the new Fetch API for remove server interaction. And instead of jQuery’s deferred object implementation, I went with the ECMAScript 6 Promises API. Fetch uses ES6 promises, so this was a perfect fit.
Then I though about routing, so I built a router. Then I added in data formatting and form validation. After that I began porting the widgets over. I wound up rewriting every single widget, changing their behavior to return objects and enabling the form-based widget to work with the new form validation.
TruckJS is a standalone framework without any dependency on other libraries or frameworks. You do not need jQuery, etc. It provides everything you need to build mobile web apps. But, if you really want to use jQuery with Truck, you can. You just have to load jQuery first. When Truck detects jQuery, it switches to using it instead of its own DOM library. I’m not sure why anyone would want to use jQuery. Its bulky and slow on mobile devices. But there’s always those special guys who think something can’t be perfect unless jQuery is loaded.
I’ve put up a site, TruckJS.io, with lots of documentation. And it’s available on Github. If you like ChocolateChip-UI, I think you’re really going to like TruckJS. It gives you the same tradition of great layouts and widgets for creating cross platform mobile web apps.
