Our business grew from a hobby in our garage, shipping a few top bar hives per month in December 2009, to a full-fledged, alternative beekeeping supplier in March 2010, shipping more than 4 dozen hives monthly, almost entirely due to Search Engine Optimization and Google Ads. Alternative beekeeping — top bar beekeeping in particular — is a niche market, with many options for a simple, cost-effective search marketing campaign. Making use of a technical background, a minimal ability to perform SEO on our Joomla-driven website, and some glaring failures by the competition in our SEO market, we were able to quadruple sales with an investment of less than $150 per month.

We started with a Google Ad budget of $50 per month in conjunction with Google Analytics, monitoring the results and adjusting the ads accordingly. During that time we also began researching SEO and tweaking our website to improve our SERP for our most important search terms. We chose very specific search terms in order to improve our conversion rate and reduce wasted ad clicks. At the same time, we also began making helpful posts on relevant blogs and forums, as well as working with related sites to swap links. The results came quickly, as we saw our Pagerank rise from 1 to 4 in a matter of only a few months. By March we were seeing over 6,000 unique visitors per month.

Today the competition is increasing, but our early and continued foray into SEO continues to give us the edge over competitors. While we’ve been busy the past few months, we cannot stress enough the importance of fresh content through blog posts, and outreach through Facebook, Twitter and other marketing avenues. We monitor daily our most important search terms through Google Alerts, and work diligently to stay current with trends in our industry and the campaigns of our competition. As traffic, sales and our ad budget increase proportionately, we continue to monitor our Google Ads, SERP, and content to ensure there are no issues.

At the same time that we are running an online campaign, we are beginning to focus more on local advertising through numerous avenues, and it is paying off. A combination of word-of-mouth, donations to sustainability-focused non-profits and locally targeted Google Ads have shown an overwhelming increase in local interest. It has been an interesting and amazing jump from a small online store to a viable business that is beginning to ponder the idea of a brick and mortar storefront.

Thanks to a little elbow grease, a monthly-coffee-budget-worth of Google Ads and some Search Engine Optimization, we believe Bee Thinking will grow to be a significant portion of our family’s income, if not our sole income in the next couple years!

Matt Reed
Bee Thinking

Object Literals / Static Objects

Object literals, or static objects, don’t require instantiation with the new operator and also behave like singletons. They are often used for providing utility classes since methods can be called statically, or as parameter packages to provide named arguments or lists to other functions. Consider the following example that illustrates this singleton property of object literals:

Example 1: Static object singleton behavior

var staticObject1 = {
    a: 123,
    b: 456
};

var staticObject2 = staticObject1;
staticObject2.b = "hats";
console.log(staticObject1, staticObject2);

Output:

Object a=123 b=456  Object a=123 b=456
Object a=123 b=hats Object a=123 b=hats

Notice that changing staticObject1.b also affected staticObject2.b. This happens because in JavaScript, when you assign an object to another variable, it simply creates a reference.

The singleton behavior may not always be the desired effect. Many libraries, such as Dojo, offer an object cloning method that can avoid this behavior if just you want to make a copy of a static object. Continuing the previous example, consider the following:

Example 2: Circumventing the singleton behavior

var staticObject3 = dojo.clone(staticObject1); // See the documentation in the link above
staticObject1.a = "pants";
console.log(staticObject1, staticObject2, staticObject3);

Output:

Object a=pants b=hats Object a=pants b=hats Object a=123 b=hats

Notice that the values of the members of staticObject1 and staticObject2 are the same, whereas staticObject3 is not affected by changes to these other objects.

Static objects are also useful for creating project or library namespaces, rather than filling up the global scope, and promote compatibility like no one’s business. This is useful when creating libraries that require portability or interoperability. This can be seen in popular libraries such as Dojo, YUI, ExtJs, and others where all or most methods are called within that library’s specific context (e.g.: dojo.examplMethod(), YUI().exampleMethod(), and Ext.exampleMethod() respectively).

One thing to remember is that in object literals, all members and methods are  necessarily public. Forever and always, so help me Douglas Crockford.  However, this is not the case for constructed objects, as you’ll see shortly.  Access restrictions notwithstanding, static objects can also be considered loosely analogous in purpose and use to C/C++'s struct type.

Constructed Objects / Instantiated Objects

Classes in JavaScript are based on prototypal inheritance, which can be a lengthy subject in itself and can be read about here, here, and here. For now, we will just compare the differences between instantiated and static objects and leave inheritance for another day.

As opposed to static objects, this method of object creation gives the unique opportunity for private scope object members and methods thanks to JavaScript’s closure property. Consider the following example of private class members:

Example 3: Private class members

var SomeObject = function() {
    var privateMember = "I am a private member";
    this.publicMember = "I am a public member";

    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
};

var o = new SomeObject();
console.log(typeof o.privateMember, typeof o.publicMember);
o.publicMethod();

Output:

undefined string
I am a private member I am a public member

Notice that typeof o.privateMember is “undefined” and not accessible outside of the object, but is from within.

Private methods can also be defined. They are not as straight forward but are still simple to implement. The issue lies in that the value of this within a private method will refer to window if you try to execute it as if it were just any method. There are at least three techniques that can be applied to ensure that this refers to the object that we are working within, in this case, the instance of SomeObject. Consider the following example:

Example 4: Private class methods with call

var SomeObject = function() {
    var privateMember = "I am a private member";
    var privateMethod = function() {
        console.log(privateMember, this.publicMember);
    };

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod.call(this);
    }
};

var o = new SomeObject();
console.log(typeof o.privateMethod, typeof o.publicMethod, typeof o.privateMethodWrapper);
o.privateMethodWrapper();

Output:

undefined function function
I am a private member I am a public member

Notice that within privateMethodWrapper(), privatemethod was executed using call and passing in this for the function’s context. This is all fine and allows us to use this within the private method as we normally would; however, the following technique is slightly more preferable as it simplifies the calling context. The previous example can be rearranged to the following:

Example 5: Private class methods with closure reference to this

var SomeObject = function() {
    var self          = this;
    var privateMember = "I am a private member";
    var privateMethod = function() {
        console.log(self.publicMember);
    };

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod();
    }
};

var o = new SomeObject();
console.log(typeof o.privateMethod, typeof o.publicMethod, typeof o.privateMethodWrapper);
o.privateMethodWrapper();

Output:

undefined function function
I am a private member I am a public member

Notice that a new private member, self, was introduced and provides a reference to this within privateMethod via the closure property. This method is agreeable for most situations; however, my syntax highlighter doesn’t highlight self the same as it does this, so I prefer the following method.

The third method effectively “locks in” the value of this within the private method. It is the most preferable in that it allows you to have a normal definition using this with the private method as in example #4, and a clean calling context as in example #5. Both the Dojo and Prototype libraries offer utility methods to do this for us: dojo.hitch and function.prototype.bind respectively. I will show how to use these methods, as well as how write your own utility method for achieving the same results for those of you not using those libraries.

Example 6: Private class methods with context locking using dojo.hitch

var SomeObject = function() {
    var privateMember = "I am a private member";
    var privateMethod = dojo.hitch(this, function() {
        console.log(privateMember, this.publicMember);
    });

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod();
    }
};

var o = new SomeObject();
o.privateMethodWrapper();

Output:

I am a private member I am a public member

Example 7: Private class methods with context locking using Prototype’s bind

var SomeObject = function() {
    var privateMember = "I am a private member";
    var privateMethod = function() {
        console.log(privateMember, this.publicMember);
    }.bind(this);

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod();
    }
};

var o = new SomeObject();
o.privateMethodWrapper();

Output:

I am a private member I am a public member

Example 8: Private class methods with context locking using custom utility method

var lockContext = function(context, callback) {
    return function() {
        callback.apply(context, arguments);
    }
};

var SomeObject = function() {
    var privateMember = "I am a private member";
    var privateMethod = lockContext(this, function() {
        console.log(privateMember, this.publicMember);
    });

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod();
    }
};

var o = new SomeObject();
o.privateMethodWrapper();

Output:

I am a private member I am a public member

Example 9: Private class methods with context locking using custom utility method (prototypal variation)

Function.prototype.lockContext = function(context) {
    var self = this;
    return function() {
        self.apply(context, arguments);
    }
};

var SomeObject = function() {
    var privateMember = "I am a private member";
    var privateMethod = function() {
        console.log(privateMember, this.publicMember);
    }.lockContext(this);

    this.publicMember = "I am a public member";
    this.publicMethod = function() {
        console.log(privateMember, this.publicMember);
    };
    this.privateMethodWrapper = function() {
        privateMethod();
    }
};

var o = new SomeObject();
o.privateMethodWrapper();

Output:

I am a private member I am a public member

As you can see, all four of these context locking methods (examples #6 – #9) allow you to keep the executing scope of your private method clean,  freeing you to write the body of your private method as you would any other, and removes the superfluous <tt>self</tt> reference. I’ll let you decide which method works best for you, but I think the prototypal approach is the cleanest. For more information on how context locking works, see the MDC references for apply and call.

Wrapping it Up

There are definite roles that static and instantiated objects fill. For me, part of the joy of writing in JavaScript is knowing when to use which, and how to get the most milage out of their differences. What about you? Let me know if you have any preferences or guidelines when it comes to creating and using objects in JavaScript.

Lets get started, piece by piece.   First off, we need a means of storing instances internally.  To do that, we need a static variable within our function.

var getInstance = function(objectName) {
  if ( !getInstance.instances ) {
    getInstance.instances = {};
  }
}

It doesn’t do much, but there you have it.  Now that we have somewhere to store our instances, lets finish out the function by instantiating new objects (only once of course) and returning those singleton instances.

var getInstance = function(objectName) {
  if ( !getInstance.instances ) {
    getInstance.instances = {};
  }

  if ( !getInstance.instances[objectName] ) {
    getInstance.instances[objectName] = new window[objectName]();
  }

  return getInstance.instances[objectName];
}

And that’s it.  Notice the new window[objectName]();.  In JavaScript, all objects are contained within/are relative to the window object.

Consider the following two example classes:

// Normal, globally accessible object
var object = function() {
 this.property = "zebras!"
};

// Static object acting as a namespace
var com = {
  project: {
    widgetAbc: function() {
      this.xyz = 1010101;
    }
  }
};

Basic usage of our new generic singleton factory is as follows:

var instance = getInstance("object");

So far, getInstance works in most instances, but if you’re in an environment where you’re using static, nested objects to create your own brand of namespacing (as in getInstance("com.project.widgetAbc")), then this method falls a little short as is; however, there is solution.

var getInstance = function(objectName) {
  // Static instances container
  if ( !getInstance.instances ) {
    getInstance.instances = {};
  }

  // If an instance hasn't been created yet...
  if ( !getInstance.instances[objectName] ) {
    // All instances are relative to the window object
    var object = window;
    // Handle static object nesting/chaining by splitting on the
    // object separator "."
    var parts  = objectName.split(".");

    // Traverse through the nested static objects until we reach
    // the last one in the chain.
    for ( var i in parts ) {
      object = object[ parts[i] ];
    }

    // Create and store the object's instance
    getInstance.instances[objectName] = new object;
  }

  // Return the stored object's instance
  return getInstance.instances[objectName];
}

I think the comments spell out the changes fairly well, but lets give it a once-over just to be sure.  The major change is that objectName is split on the member operator (.), yielding any array like ["com", "project", "widgetAbc"].  We then iterate through that array, nesting each member within itself starting from the window object until we reach the end of the chain.  This gives us an instantiable reference to the requested class.

Lastly, you’ll notice that on the line, getInstance.instances[objectName] = new object;, I omitted the ().  It works with or without the parenthesis, but I prefer to omit them to distinguish the fact that we are not instantiating an object called “object”, but instead, are instantiating the object referenced by the variable “object.”

Now that we have all that settled, we can use our factory as follows:

var someObject = getInstance("object");
var someWidget = getInstance("com.project.widgetAbc");

I hope that shed some light on the subject.  Feel free to ask a question or two, and don’t hesitate to tell me if I made any mistakes that need correcting.