JavaScript seems to be an odd candidate for a language on the rise. After all it’s not new, and in fact is by most accounts a flawed language. Many would argue that it fails to deliver on the 3 pillars of Object Oriented programming; encapsulation, specialization, and polymorphism. Javascript is very loose in it’s typing, and the apparent lack of those types may drive a “classic” programmer out the window. We have functions as first class citizens and can pass them about without a care in the world. The endless flow of callbacks and a-synchronous patterns can quickly turn any well crafted script into an unwieldy goulash. Within the function body of an event handler we suddenly loose scope and find ourselves hanging from the window, looking in on our locally scoped friends we so desperately need. Yet somehow, someway all the “newness” and “hotness” and “hipster meta tech framework jargon ipsum” is leaning on the back of this once berated language.
With the death of Flash there is one way to script that all the browsers you care about can handle, and that is JS. It’s like our “too big to fail” banks and insurance companies. What happens if a browser decides “nah, I don’t like JS, we are going to introduce a new sexy, semantic language that is going to blow the doors of that antiquated piece of junk”, and stops supporting it? People stop supporting that browser. We have parity; Chrome, FF, IE, Safari, Opera etc … IE is no longer the hegemony it once was, and cannot push us around. In fact IE has to play catch up and support the magnificent modern feature set that webkit and Mozilla dream up.
With that, and the increasing efficiency of the JS interpreters we are driven to code the way of the JS Ninja. The FE days of sad code monkeys pushing pixels has given way to some seriously kick-ass client side devs who are moving this wave further and faster. JQuery is almost a forgone conclusion at this point – some of use are running multiple versions *gasp*. It has made selecting, parsing, and manipulating the DOM dead simple, normalized events and AJAX across browsers, gave us simple animations, and brought IMHO brought the first glimpse of sanity to Client Side Programming. WOW, the term “Client Side Programming” was an oxymoron at one point, wasn’t it? Now there is a sea of emerging frameworks, libraries, tool-belts(?) all calling for our attention and loyalty.
We recently built a prototype for client that was purely on the front end. With the help of local storage, an app experience was born that could be stateful for the user and provide an excellent preiview of a potentional product. After much researching and second guessing I arrived a set of libraries and frameworks to use in our venture. They were Require.js, Underscore.js(required by backbone), Backbone.js, and jQuery. Backbone has a hard dependency on Underscore, and looks for either jQuery or Zepto for DOM work. I was fimiliary with jQuery so that was an easy choice. The decision to use Require was inteded to provide structure and convention for JS dependancy management. Node has it’s own built in “require” and as someone who does not do a whole lot with Node – I was envious.
Backbone.js
Backbone claims to be a client side MVC. Model – View – Collection … I hear you, what’s a collection? Where’s the Controller? Backbone had a controller, once, but that is gone now and all that remains is the view – which is actually more like a controller, and where you might think view code should be exists JS templates. JS templates, oh right – and which templating library should I use; mustache, handlebars, underscore/lodash, srender? I’ll say underscore for the sake of simplicity as it’s a hard dependency of Backbone – but I hear people like the handlebars and mustache because they have opinions on logic in your templates. I digress – Backbone, right, so What’s so awesome about it?
- Nice “extend” synatx for dealing with JS prototype inheritence – very common these days
- Event Delegation – clean usage of jQuery.delegate, handles the “this” gotcha of the scope bounce with event handlers
- Patterns for binding views to data models – this is really where the juice is.
- Native underscore methods of collections (Array of JSON Objects)
- Reusable code patterns
Underscore.js
Underscore is the only dependancy of Backbone, but shouldn’t be needlesly tied to it. If there is one thing that you take away from this post, it’s that you should go get Underscore/lodash right now. Underscore gives MUCH needed functional tools to JS objects, arrarys, arrays of objects(collecionts) and has some other bonus love as well. There is NO reason why you should not be using underscore, unless your in some larger framework i.e. Sencha. Another glorius takeaway from underscore is that you can now reuse your BackBone data models and collections from Node in the browser, as it has brought all those functional compemenets up. Brilliant!
Require.js
You should be using AMD patterns for your JS, just like you should never use == and always use ===. Require isn’t perfect and can be ugly, but it’s better than nothing and comes with a handy dandy optimizer (r.js) – which runs on Node of course. The learning curve for me was steepest with Require. Not using a singleton global APP object pulls the rug to be sure – it takes some getting used to. In the end it results in better more re-usable JS code IMO.
There are many JS frameworks and plugins and helpers and tools, and it’s moving super fast. Being able to use one of these tools is the only way to learn, and decide if it’s right for you. There is no right way to use them, though certainly there are wrong ways but the most important thing is keep opening them up, diving head on, and hoping for the best. This is NOT an industry where you can sit still – and I like that way. JavaScript may give way to CoffeeScript of ECMA 6 or Dart, or who knows what – but right now you should know it and love it.