I finally got to mess around with PhantomJS and Jasmine, and couldn’t find a resource that gives clear, concise, accurate information, without language specific or build tool specific coupling, so I decided to write it myself.
Fortunately, it is way simpler than I thought.
PhantomJS is a standalone, cross platform command line application which does not require any specific server environment or programming language support.
One of the good things about Backbone.js is it doesn’t tell us how to do things. It leaves it for us to decide what are the best practices for writing views (or any components).
This is also one of the worst things about Backbone. it makes it almost too easy to take the wrong path, and write views that will be hard to maintain.
The principle we should follow when writing a view is to keep it encapsulated, and keep it as “dumb” as possible – a view should know only the bare minimum it needs to know in order to do it’s job, and do bare minimum it has to do.
Writing tests for your code may not reduce the number of bugs, but it will make fixing the bugs you inevitably find easier.
Obviously, we can take advantage of the AMD architecture, to help us write modular tests (or “specs” in the BDD language).
To get a better sense of the challenges and different approaches in unit testing, I wrote the exact same tests three times using three different testing frameworks: Jasmine, Mocha and QUnit. Continue reading →
Backbone gives us a very powerful set of tools. It gives us models, views, and routes – all event driven, consistent and beautifully embrace underscore.js functionality. Being a library rather than a framework, Backbone doesn’t give us application structure. That “glue” we need too initialize the app and glue all the pieces together.
Since coding is by far easier than explaining, I programmed a Todos app in order to demonstrate how this can be done with Asynchronous Module Definition (AMD) using RequireJS. Continue reading →
PubSub (or the observer pattern) is obviously the hottest pattern in client side development, and I would like to take a shot at trying to refine the best practices for using it in a flexible and robust way.
The definition provided in the original Gang of Four book on Design Patterns states:
“Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically”
As in any design pattern, an important part is to keep the application loosely coupled and with high cohesion. Continue reading →