Category Archives: Development Tools

How CoccyxJS uses RequireJS to define its own dependencies but can also be used from the global name space

images-1RequireJS is a great asset when you want to write highly modularized applications, but when it comes to using RequireJS to write highly modularized JavaScript libraries that are meant to be shared with others, then there are challenges. It is a fact that for what ever reasons, not everyone is enamored with RequireJS; they just wont use your library if it means they also have to use RequireJS for their own applications. I think that it is telling that many of today’s most popular libraries do not directly use RequireJS internally to define their own dependencies and modules because they don’t want to discourage other developers from using their libraries by imposing RequireJS as a dependency.

The ultimate solution to this problem would be if there was a way to create a library that is itself built using RequireJS, which defines its own modules and dependencies using the RequireJS define method, but that can also be used in the old “global” fashion that most libraries still tend to adopt and users like. It is easy to draw a comparison to jQuery, which is both AMD compliant and capable of being used from the global name space, and say, “just do it the way jQuery does.” The problem with that is that although jQuery is AMD compliant, it actually doesn’t use RequireJS at all to define its own modules and inter module dependencies.

As you can guess, I struggled with this very issue myself while developing CoccyxJS v0.6, which will be released very soon. I wanted to use AMD modules to break up CoccyxJS into its logical components and have its components declaring their own dependencies upon other CoccyxJS components, such as define(‘views’, [‘application’, ‘helpers’], function(app, helpers){…}); for example, but I also didn’t want to discourage the adoption of my library just because I chose to implement it using RequireJS. After some thought it dawned on me that conceptually it should be possible to have my cake and eat it too, to use RequireJS in a way that would make CoccyxJS a compliant AMD module, usable by applications that are also using RequireJS, and usable by application that access it from the global name space as well.

The solution I employed is actually quite simple and I offer it up to anyone else who is considering developing a library they’d like to build using RequireJS, but who also don’t want to discourage its adoption.

First and foremost, CoccyxJS is built as one would build a library that is intended to be used from the global name space. The difference though is that it also defines its own inter dependencies between its modules using the RequireJS define method. In order to get this to work, so that it can be used both as an AMD module and from the global name space, you never use modular dependencies as arguments to define’s callback functions and you never define your modules by returning objects from those callback functions.

For example, in CoccyxJS, the views module is defined as define(‘views’, [‘application’, ‘helpers’], function(){…}). The views module declares its dependency upon both the application module and the helpers module, but it doesn’t use them as arguments in the callback function. By declaring its dependency on these 2 modules, the callback function won’t be called until they are loaded and resolved. Internally, anything that is exposed in these two modules is done so in the old fashioned global way, by tacking them onto the single global variable, Coccyx. By the time the callback function is called, everything that the views module needs from the 2 other modules has already been placed into the Coccyx name space. For example, the helpers module, in total, is shown below:

define('helpers', [], function(){
    'use strict';

    var Coccyx = window.Coccyx = window.Coccyx || {};

    Coccyx.helpers = {
        //Returns true if s1 contains s2, otherwise returns false.
        contains: function(s1, s2){
            var i, len;
            if(typeof s1 === 'string'){
                for(i = 0, len = s1.length; i < len; i++){
                    if(s1[i] === s2) {
                        return true;
            return false;
        //Returns a deep copy object o.
        deepCopy: function(o){
            return JSON.parse(JSON.stringify(o));
        //Pass one or more objects as the source objects whose properties are to be copied to the target object.
        extend: function(targetObj){
            var len = arguments.length - 1,
                property, i;
            for(i = 1; i <= len; i++){
                var src = arguments[i];
                for(property in src){
                        targetObj[property] = src[property];
            return targetObj;
        //For each matching property name, replaces target's value with source's value.
        replace: function(target, source){
            for(var prop in target){
                if(target.hasOwnProperty(prop) && source.hasOwnProperty(prop)){
                    target[prop] = source[prop];
            //0.6.0 Return target.
            return target;


Within the views module, when it needs to call helpers.extend(), it would do so by calling Coccyx.helpers.extend(), which is how it is defined within the helpers module.

I use Grunt to concatenate all the modules that make up the CoccyxJS library into a single file. The last file concatenated at the end, the amd.js file, looks like this:

define('coccyx', ['application', 'helpers', 'router', 'history', 'models', 'collections', 'views', 'eventer', 'ajax'], function () {
    'use strict';
    return window.Coccyx;

The amd.js file is ultimatley responsible for turning CoccyxJS into a compliant AMD module. It states its dependencies on all the sub modules and it returns window.Coccyx, which allows it to be used from the global name space.

Now, in order to use CoccyxJS from the global name space, you just need to add this little JavaScript shim before your script tag that loads CoccyxJS:

//A shim that mocks the RequireJS define() method so that Coccyx.js can be used without RequireJS.
//Calls the RequireJS define callback function, allowing Coccyx.js modules to "define" themselves.
//IMPORTANT - include this script before Coccyx.js.
    'use strict';
    window.define =  function define(){
        (arguments[arguments.length - 1])();

And there you have it. By using this technique when creating your own libraries you will be able to satisfy developers who want to use RequireJS and those that don’t. Your library will gain all the benefits of using RequireJS to build itself from individual AMD modules and ultimately defining itself as a compliant AMD module, while also being able to be used from the global name space.

I really like RequireJS, but I don’t want to alienate potential adopters of my library who might otherwise adopt CoccyxJS for their own development efforts but for its RequireJS dependency. By using this technique, I feel like I am able to have my cake and eat it too, and able to pass that cake on to the users. “Let them eat cake,” that’s what I say 🙂



The Tools Of My Trade – Sublime Text 3 & Tern

toolbox-1In an article I wrote a while back, I expressed what every developer knows (or should know) which is the importance of choosing the right development tools. In that article I also stated my appreciation for WebStorm, which is a light-weight but full featured JavaScript/Web IDE from JetBrains. Now I’d like to touch on another subject that I raised in that article but never expanded upon, which is using a standalone text editor for JavaScript/Web development.

My favorite text editor of all time is Vim. It is dear to my heart and almost as old as I am (not quite lol). I use it for all sorts of editing but I’ve never liked using it for editing code. Call me muscle-memory challenged but I want my code editing tools to provide me with intuitive code completion. WebStorm shines in this area and does so because it actually indexes all the symbols it finds in your project files. Editors, for the most part, don’t do that. But…. enter Sublime Text 3 and Tern.

Sublime Text 3, while still in beta, is stable and even faster than its predecessor. Most importantly, though, it now indexes the symbols in your project’s files and uses the index to support project-wide symbol searching. This is a vast improvement over Sublime Text 2. But wait, that’s not all. Then there’s Tern. For those of you who might not have heard about Tern, all I can say is go to the link above and read up on it. It is an incredible asset when coding JavaScript and now there are 2 Tern plugins for Sublime, this one and this one. Sublime Text 3 along with Tern makes for a near perfect stand-alone text editor for JavaScript development.

I say near perfect because Sublime Text 3 still cannot format HTML and code to save its life and its attempt at Vim support via Vintage mode leaves me wanting more – a lot more – and while Vintage mode is better than nothing at all, I desperately wish that Sublime’s developer would set about matching the Vim emulation found in WebStorm. No, I am begging him – please make Vintage mode equal to or better than that in WebStorm. I can’t promise him fame or fortune but I can promise him that he would have earned a special place in every Vim lover’s heart. Oh, and if he could also make Sublime format HTML and JavaScript in a sanely manner then that would be greatly appreciated as well :).

But even with its short comings and challenges, there is in my opinion no other stand-alone editor that can even come close to Sublime Text 3, especially when teamed up with Tern. I love it and to prove my love I purchased a license a few months back to show my support and appreciation and I encourage everyone to do the same, especially if you have been using Sublime regularly.

As a side note to all this love and admiration for Sublime Text 3 and Tern, I am a little concerned about the number of Sublime Text plugins that are still not yet compatible with Sublime Text 3 or are not yet discoverable through the package manager. I hope that the pace will pick up and that Sublime’s thriving eco system will continue to enrich what is already an outstanding editor.

The Tools Of My Trade – WebStorm

I think it is a good idea to take stock of my tools every so often, to make sure they are in line with what I am trying to accomplish and aren’t themselves limiting me. Of all the tools in my tool box the most important to me are my IDE and code editor. Today, I’d like to focus on my IDE of choice.

WebStorm, the dedicated JavaScript Web development IDE from the good folks over at JetBrains, is a phenomenal JavaScript Web development environment and I’ve been champing at the bit wanting to write a raving review for a while now. Unfortunately I haven’t had the time to do an in depth review, so instead I will take a different approach and focus on only those features that in my opinion set WebStorm apart from its competition. I will also touch upon a few of its weaknesses that I would like to see addressed as well.

Where WebStorm Rocks:

1) Speed – My primary development tool has to be fast and anything less just wont cut it. WebStorm is the fastest IDE I’ve every worked with. It is quick to boot up and once booted it remains snappy. Project indexing which is often responsible for bringing an IDE to its knees is fast and I have never incurred any latency during the process.

2) Configurability – The folks over at JetBrains obviously recognize that we developers are a very picky and demanding bunch and that we will quickly reject any tool that doesn’t allow us to configure it to our specific likes, needs and work flow requirements. So not only did they provide us with a huge number of configuration options but they also made it very easy and accessible. From within configuration you can enter search criteria and WebStorm will return a list of configuration items that match your search criteria. Now that’s what I call a really smart approach to simplifying configuration.

3) The Editor Is My Canvas – The editor is where I often find myself in 8, 10, 12 or more hours a day. The quality or lack of it will either make or break a product for me. After all, I write code — that’s what I do. Writing code is my passion and the way I earn a living — and as such I demand more from my editor than from any other tool that I work with. My editor has to allow me to get as much work done without exiting out to some other application or tool which would just break my work flow and my concentration and that’s not a good thing. The way I see it, an artist never has to leave their canvas to paint and so a developer should never have to leave their editor to develop. WebStorm’s editor is my canvas.

4) Key Bindings and Keyboard Shortcuts – I’m a huge fan of VIM. I like VIM’s modal approach to editing. VIM allows me to be more productive because I rarely have to take my hands off of the keyboard and reach for my mouse or trackpad, which are actions that when repeated often can be distracting and physically challenging over the course of a long day.

WebStorm’s VIM key bindings duplicate many of VIM’s keyboard commands and though not a “hard core VIM” experience, it does provide enough of one and it works extremely well. Honestly, if it hadn’t I’d have rejected WebStorm outright which just goes to show you how serious I am about this.

In conjunction with good VIM support, WebStorm provides access to almost all of its features through handy keyboard shortcuts, which when used together with the VIM key bindings makes the physical act of typing in WebStorm quite productive and pleasant.

5) GIT Support – In a word, fantastic! Branching and shelving are well supported as is cloning from and pushing to github. I especially appreciate that WebStorm supports github Gists which I use as a repo for my code snippets.

6) Pretty and Nearly Distraction Free – Yeah, I said pretty. It shouldn’t seem odd that I would expect the environment I’m working in all day long to be visually appealing. Ugly is distracting and ultimately will affect my creativity and productivity. Therefore ugly is out. By using an assortment of WebStorm configurations I’m able to tailor WebStorm to be pretty and distraction free, eliminating most of its user interface. That’s how I like it!

7) Plugins – WebStorm is extensible through its plugin system. In fact, many of WebStorms features are provided through plugins. There are also numerous 3rd party plugins available as well. My favorite plugin is AceJump, written by John Lindquist, and the best description I can give it is that it is like search on steroids.

8) Live Templates – Live Templates are to WebStrorm as Snippets are to TextMate. They allow you to easily extend and add features to the editor.

9) Frequent Updates and Bug Fixes – I’ve already received one major update and 2 minor updates. It’s obvious to me that JetBrains stands behind their tools.

10) Server and Client Side Debugging – Easily debug server side and client side JavaScript. Really handy for both server side Node development as well as for front-end development.

Some Improvement Needed: 

This is my short list of those items I would most like to see addressed in future releases of WebStorm. WebStorm is a broad product, it attempts to do many things very well and for the most part it does. In my opinion it doe so better than any other IDE in its category. However, as excellent as WebStorm is there is room for some improvement. So here’s a few of my top wish list items:

1) Plug a few gaps in the VIM key bindings – As good as WebStorm’s VIM key binding are, it is missing a few that I think it should have. Most notably it doesn’t implement the character case switching commands in full. Complete support for this group of VIM keyboard commands is important when writing code in programming languages that are case sensitive as is the case (no pun intended) with JavaScript.

2) Improve Code Completion – Code completion is still too often a hit and miss proposition, even with the inclusion of external libraries, and while I understand this is really hard to do with dynamic languages such as with JavaScript I am hoping that JetBrains can improve on this.

3) Provide Custom Scaffolding Templates – I need a way to describe to WebStorm how to generate projects. I want to define the files, libraries and their versions that I want WebStorm to include as well as the actual structure of the project itself, including the names of the folders. I should be able to include files that reside either on the web or locally. Sounds or feels like something along the lines of a package manager to me but in any case it would allow me to pick and chose the libraries and files I want to use along with their versions. Perhaps just integrating with NPM or one of the other popular package managers would provide what I’m looking for. Maybe not an easy thing to do but it can’t hurt to ask, right?

4) Debug Both The Back and Front Ends At The Same Time – Right now you can debug one or the other but not both at the same time. Well, at least I haven’t been able to get this to work. So when working with Node it would be extremely handy and a real productivity booster if WebStorm were able to debug both at the same time.


While there are numerous free and open source options available, in the end I chose to purchase a license for WebStorm because none of the other options appeared to me to be as feature rich and as refined as WebStorm is. The attention to detail in this product is excellent and the 49 bucks US I paid for WebStorm is in my opinion an incredible value, especially considering how much utility it provides me and how productive I am with it.

As far as JavaScript development is concerned, WebStorm sets the bar to which all other dedicated JavaScript Web development IDEs must be measured against. Kudos to JetBrains for producing the finest dedicated JavaScript Web development IDE I’ve had the pleasure of using.

Links To References:

Vim’s case switching commands
AceJump plugin by John Lindquist – download directly through WebStorm’s plugin system.  Informative video available at