I like to look upon the web development/design industry and see it for its openness and its community atmosphere. The voluntary sharing of knowledge could not be more evident, but yet there is an elephant in the room when it comes to openness, and that elephant is made up of all these greedy individuals and companies that only want to capitalize off our good intentions and our willingness to share knowledge.

Carsonified, the organisers of such prestigious events as FOWA and FOWD, are a good example of a company that runs highly priced events. As I see it, there are several costly factors when organising such events:

• Speakers – payment for the talk plus accommodation and travel
• Venue hire
• Insurance
• Equipment hire
• Event merchandise
• Staff costs – labour/travel/accommodation
• Minor extraneous costs (website, flyers, hosting, wireless etc.)

Let’s look at the numbers.

Tickets to the upcoming FOWA conference in Dublin cost €296.45 (~£244 excl VAT). You can also sponsor the event — it’ll set you back anywhere between £1500 and £15,000. Let’s be generous and say there are only going to be 400 attendees, — assuming fifty of those are early-birds, that amounts to £86,500, and let’s say that all sponsor spots are taken (~£65,000) — that brings it to a rough total of £150,000.

I’ve tried my best to gather some numbers for the costs:

• Speaker – £1000 (there are six speakers = £6000)
• Speaker accommodation – one night – standard 4 star hotel – £150 (x6 = £900)
• Speaker travel – probably from US – ~£600 (x6 = ~£3600)
• Venue hire – University College Dublin – ~£4300 (src)
• Event insurance – ~£5000
• Equipment hire
  • A/V – speakers/microphones/projector hire – ~£2000
  • Stands / boards – ~£1000
• Event merchandise
  • 300+ badges – ~£1000
  • 300+ paper/pens to give away – ~£3000
  • Other random stuff – ~£1000
• Staff costs – labour/travel/accommodation – no idea – probably around ~£3000
• Minor extraneous costs (website, flyers, hosting, wireless etc.) – ~£3000
• Food for speakers – ~£75 per head – £450
• Coffee/biscuits for attendees – ~£15 per head – ~£6000

That all comes to just over £40,000. Let’s be kind and say the entire event cost £50,000. So, £150,000 minus £50,000 and corporate-tax (~22%) amounts to a probable £78,000 take-home profit for the event organisers. I don’t claim to know (with absolute certainty) how much profit they’re making, but given the costs outlined above I would be surprised if it’s considerably less.

So, we’ve established that this particular event probably makes a rather beefy profit from our good intentions. Let’s have a look at another upcoming conference, this time an “online” conference, i.e. you simply buy a ticket and watch it online. It costs $150 to “attend” this conference — “The CSS3 Online Conference” (showing on 22nd March). Since it’s online, the costs for the event organisers are minimal:

• Speakers – five of them – ~£5000
• Speakers – travel/accommodation/food – ~£3000
• A/V equipment – ~£400

The amount of tickets that they can sell is unlimited since they’re not limited by seat space. Let’s assume 300 this time – that’s $45,000 (~£30,000). Again, a sizable profit is probably being made here.

Making so much profit is, at best, ethically questionable. I’m not going to make solid claims about certain event organisiers, but I will say that if they truly care about the qualities of the web industry that they promote through their events, then they should seriously consider lowering the attendence fee. Again, conferences like these are about sharing knowledge and ideas — why should anyone be looking for additional compensation?

Ideally, conferences like these should cost around £15 for attendees, just to ensure that they’re sufficiently committed, and then the rest of the conference’s costs could be covered by sponsors.

Profiting from good intentions is immoral.

As with any good book, the first chapter outlines what the subject matter is. The authors talk about jQuery itself and touch briefly on the DOM. You have to remember that this book is aimed at developers or designers that don’t really know that much about JavaScript, the DOM, or jQuery, so the book is accordingly written in such a way that it won’t confuse the pants off your typical photshop-wizz turned HTML/CSS guy.

So if you know JavaScript well, you might not enjoy this book — it will probably annoy you, simply because it doesn’t go into a huge amount of detail on what’s happening behind the scenes. But, for those that it’s aimed at, I think it does a pretty good job.

One thing that we have a problem with, in the jQuery community bubble, is the overzealous generation of redundant nomenclature. This book doesn’t fall short on this front. jQuery’s methods are referred to as “actions”.

The second chapter covers the most basic usages of jQuery, selecting stuff and doing stuff. It’s all innocent and simple — I like it. To keep the reader focused the authors have slipped in “A few tricks”. Among them is the popular add-a-class-on-mouseover, remove-it-on-mouseout.

Nearing the end of chapter two, the book has the following to say about the hover method:

“It requires two functions as parameters: one to handle the mouseover event, and one to handle the mouseout event.”

The book does claim to be 1.4-ready, so I think it’s only right to mention this. In jQuery 1.4 the hover method accepts either one or two parameters, and they don’t correspond to the mouse(over|out) events; they correspond to the mouse(enter|leave) events, although I guess they’re not totally incorrect on this because jQuery simulates these events using mouse(over|out) in non-supporting browsers, but it is nevertheless an oversight.

Not soon after that did I find what I consider to be a grievous anti-pattern:

$('.spoiler').hide();
$('<span class="revealer">Tell me!</span>')
    .insertBefore('.spoiler');
$('.revealer').click(function() {
    $(this).hide();
    $(this).next().fadeIn();
});

It seems that in their desperation to keep it simple, the authors have chosen to spare the readers of what would be some very good advice. When you add something to the DOM, and it doesn’t need to be referenced within a CSS StyleSheet, then giving it a class or ID, and then getting a reference to that element via that hook, is normally an almost-entirely redundant process. This would be a far better approach:

var spoilers = $('.spoiler').hide(),
    buttons = $('<span>Tell me!</span>').insertBefore(spoilers);
 
buttons.click(function() {
    $(this).hide().next().fadeIn();
});

Or, even:

$('.spoiler').hide().before(
    $('<span/>', {
        text: 'Tell me!',
        click: function(){
            $(this).hide().next().fadeIn();
        }
    })
);

If I was the author, I don’t know what I would have done in this situation… since it’s a teaching exercise, do you show the readers how it should be done, or do you show them in the simplest way possible, so as to not bulldoze them with complexities?

Moving on, the book is very cookbook’y and focuses heavily on an imagined client that has lots of strange requirements (quite typical of your average client). From the introduction to chapter three:

“The client is extremely happy [...] he believes flashy animations will help boost sales.

‘I think it needs some of that Web 2.0 that I’ve been hearing about,’ he says confidently. ‘Can you make it look more like a Web 2.0?’

‘Errrm, indeed we can,’ you assure him, as he passes you his next wish list chock-full of exciting changes—a list that will allow us to move beyond simply hiding and showing, and closer to our goal of being a jQuery ninja.”

I have a soft spot for these kind of tongue-in-cheek introductions, they’re quite popular in other programming books too, and I think it does well to mentally elevate the reader — and to develop that all-important reader-author relationship.

Before you know it, you’re into the third chapter. Chapter three exhaustively covers animation. The detail is great and the authors even take the time touch on jQuery UI’s animation capabilities in addition to covering all of the core methods. I liked this chapter, — it seemed to cover pretty much everything, although I found myself disappointed with some of the code again:

$('<div id="navigation_blob"></div>').css({
    width: $('#navigation li:first a').width() + 10,
    height: $('#navigation li:first a').height() + 10
}).appendTo('#navigation');

Let’s introduce some basic optimisations:

var nav = $('#navigation'),
    firstAnchor = nav.find('li:first a');
 
$('<div id="navigation_blob"></div>').css({
    width: firstAnchor.width() + 10,
    height: firstAnchor.height() + 10
}).appendTo(nav);

Chapter four is all about images, and takes the reader through the process of creating a simple lightbox effect. It also shows you how to download and “install” your typical jQuery lightbox plugin (in this case, ColorBox). It continues to show you how to create a simple slideshow.

The bulk of this book was obviously written before 1.4 was released. I get the impression that, upon 1.4’s release, the authors quickly went through adding in some “actions” only made possible with 1.4. They covered the new way of creating elements in jQuery 1.4, which involves passing an object as the second argument to jQuery():

$('<div/>', {
    text: 'foo',
    click: function(){},
    id: 'muah'
});

The book had the following to say:

“If you use a jQuery method name like text, html, or val, it will use the jQuery methods to set the property. Everything else will be treated as an attribute, as done with the src property.”

This isn’t entirely accurate. jQuery only uses certain methods — not all of them. Methods available for usage in this way are specified under jQuery.attrFn.

Continuing…

Chapter five brings with it a lot of UI icing… tooltips, menus, tabs and accordions. The book takes the reader through the processes involved in creating these interface elements. Just like all the other chapters, chapter five is littered with little titbits of useful information. For example, it covers event propagation and default event actions in pretty decent detail.

The next chapter is probably my favourite — it covers code construction and best practices, including namespacing, encapsulation, commenting, DRY, templating and feature detection! I was pleasantly surprised to see these topics covered in a book like this. Their templating techniques were a little lacking — I would’ve liked to see some custom-typed <script> elements (like in Resig’s solution), or perhaps some templates stuffed into HTML comments.

Chapter six continues by explaining Ajax and showing the reader what jQuery offers in the way of Ajax/XHR utilities. You’re also taken through the process of creating an Ajax-driven image gallery among some other gems.

I’m going to stop outlining the chapters now… I’m bored, and you’re probably not getting much from that (heck, you could probably just look through the TOC). The rest of book covers forms, controls, dialogs, validation, lists, trees, tables, plugins, themes and some “advanced topics”. There’s also a hefty appendices that has bunch of useful information, including a brief JavaScript tutorial for those new to the language.

Just so we’re clear, this is a good book, and if you fit the bill of a front-end wizz that wants to pick up jQuery, then this book will easily deliver. There are a couple of oversights, but in a book over 400 pages long I’d say that’s pretty amazing! Earl Castledine and Craig Sharkie have done a pretty awesome job!

For me, it’s all about the language — if it’s well defined within the language spec (or the API docs, if you’re using a library) then use it! When I write something in JavaScript I’m doing so under the presumption that the next developer that reads my code will be moderately proficient in the language and any dependencies that I’m utilising (i.e. libraries/frameworks/toolkits). Why should I presume anything less?

If the language or library is mainstream, it would make sense (in a perfect world) to assume that those tasked with coding in it are well versed in its syntax and rules.

// How to be annoyningly verbose
function showTheUserAMessage( theMessageForTheUser ) {
    alert( theMessageForTheUser );
}

Gosh! That’s unreadable, isn’t it? Seriously, I don’t think Joe Bloggs Office Clerk could read that, do you?

If you’re going to say that some JavaScript code is unreadable, first consider whether you’re really the person it was written for. If you don’t know what null || [] returns, then you certainly shouldn’t be claiming to know what is or isn’t unreadable.

Think of Perl! It’s like a mess of characters to most people, but to the lucky few that understand that Unicode soup, it’s as readable as the English language!

Readability is in the eye of the beholder…

~~something;

The bitwise NOT operator (~) will take its operand, convert it to a 32-bit integer, and will invert each bit so that each 0 becomes a 1 and vice versa.

00000000000000000000000000001001
...becomes
11111111111111111111111111110110

The effect of this, given the expression ~foo is -(foo + 1). A double bitwise NOT operation (~~foo) will therefore result in -(-(foo + 1) + 1). This only remains true for integers though; given all the potential operands, the real equivalent expression to ~~ is probably something like:

typeof foo === 'number' && !isNaN(foo) && foo !== Infinity
    ? foo > 0 ? Math.floor(foo) : Math.ceil(foo) : 0;
// This is ONLY _effectively_ the same... this is
// NOT what happens internally!

This is obviously a fair bit slower than ~~.

If the operand is a number and it’s not NaN or Infinity then ~~ will have the effect of rounding it towards zero (Math.ceil for negative, Math.floor for positive). If it’s not a number, then I believe the internal ToInt32 function converts it to zero.

Here are some examples of the double-bitwise NOT operation in all its glory:

~~null;      // => 0
~~undefined; // => 0
~~0;         // => 0
~~{};        // => 0
~~[];        // => 0
~~(1/0);     // => 0
~~false;     // => 0
~~true;      // => 1
~~1.2543;    // => 1
~~4.9;       // => 4
~~(-2.999);  // => 2

~~’s flooring capabilities make it a better alternative to Math.floor if you know you’re dealing with positives — it’s faster and takes up less characters. It’s not quite as readable though, but I’m hoping that ~~ will slowly become a very well-known technique in the JS arena, so we can all use it without fearing accusations.

It’s quite useful for normalizing arguments that you expect to be integers too. Take this example from what the MDC recommends for providing Array.prototype.indexOf to non-supporting browsers:

/*Array.prototype.indexOf = function...*/
var from = Number(arguments[1]) || 0;  
from = (from < 0)  
     ? Math.ceil(from)  
     : Math.floor(from);

In goes ~~:

/*Array.prototype.indexOf = function...*/
var from = ~~arguments[1];

Go forth and double-NOT!

Anything that perpetuates this quality is something I can get behind. Communication is key!

Forgive the self-indulgent introspection but I think it’s important for me to encapsulate how I feel about this into prose, just so I “have it on file”.

I know for a fact, that if not for the comments left on various posts of mine, I would be less technically proficient than I am right now. Note that I’m not insinuating that my current level of proficiency is notably high; I’m merely stating that it would be notably lower if not for the feedback I’ve gained over the years.

In March of last year I posted a brief outline of how to use regular expressions in JavaScript. This was at a time when I was pretty confident of my knowledge in the JavaScript arena, and I think that my confidence was shown in that post. I sold the information as if it were fact — there was no visible doubt in how I wrote it. I think this ill-founded confidence is inherent in this industry, partly due to its low barrier to entry. Within a month, you feel as if you’ve conquered HTML, and then three weeks later you’re a CSS guru etc.

I don’t see anything wrong with this confidence though — for one, it’s good practice to outline a subject in a professional manner, even if you’re not entirely correct about certain things. And, most importantly, the feedback that can be gained from those more experienced is infinitely helpful. Just to be clear though, I don’t think that putting people on pedestals is conducive to a good information-sharing atmosphere — if anything, it acts as a hindrance, because you presume their utterances to be entirely correct all the time, when nobody is truly omniscient!

This was what I had to say about the RegExp.prototype.exec method in that post:

this method is exactly the same as the String.match() method, the only difference being that you pass the string as the argument and the method is run as a member of the regular expression that you’re using to search the string.

Lucas Smith chose to leave a comment telling me of my oversight. If not for him, who knows how long I would carry and “sell” this piece of incorrect information? I’m grateful to Luke and everyone else that has set me right when I have been incorrect.

If I didn’t enable comments on my blog then a casual reader would presume that my information is irrefutable, and here in lies a very dangerous prospect — not only would I not be set right by those more technically proficient, but my perception of correct information would be bound at best, by how I choose to interpret information from other sources, and at worst, by mere guesswork (as was the case in the exec oversight).

I believe that publically viewable feedback is essential to uphold accuracy. In other words, you should enable comments, so that people can tell you when you’re wrong. Obviously though, I’m talking about objective information, facts that cannot be disputed. I’m not talking about opinions or beliefs; you cannot correct someone for having the wrong opinion; it’s their opinion, and it’s likely to be founded on other pieces of scattered information and other opinions that they’ve accumulated — you can correct their understanding of the information, but not the opinion itself.

Also, speaking of opinions, it is my opinion that in order to promote healthy commenting, the barrier to feedback must be low, otherwise you’re merely doing yourself a disservice — you will never get that valuable piece of information from Mrs. More Experienced because she can’t be arsed to fill out that damn “captcha”, and she certainly can’t be bothered to look up your email and send you one!

The comments have to be publically viewable because Mrs. More Experienced doesn’t really care about your understanding of the information; she cares about the danger of incorrect interpretation of the information you’ve provided, i.e. she cares about the people that will believe what you’ve written to be fact. By her commenting, she not only corrects you, but adds value to your content by making it more accurate, and thus halting the cascade of misinformation that affects subsequent readers.

I haven’t even touched on the benefits that can be derived from subjective debate. I can’t write a post that says, “multiple exits in functions are 100% okay”, and then disable commenting! It’s a subjective view in a technical arena — people mistake these for facts. It might be okay if I prefixed it with “It is my opinion that…”.

What I’ve realised over the previous year is that by having a blog or a similar medium, you can inadvertently create the illusion of authority in a particular area, and to ironically quote one highly authoritative figure, “Unthinking respect for authority is the greatest enemy of truth.” ~ Albert Einstein.

Libraries like jQuery aren’t very small when uncompressed. Traversing a long source file trying to look for a specific method’s implementation is far from ideal. I have frequently found myself in this situation with jQuery, so today I decided to do something about it, and the result is viewable at http://james.padolsey.com/jquery.

It allows you to study specific parts of jQuery’s source. You can type in a method name and you’ll see its implementation straight away, in all its syntax-highlighted glory! It will also link’ify all function names within the presented source:

You can link directly to a method using the following URL pattern:

http://james.padolsey.com/jquery/[version/]methodName
 
E.g.
http://james.padolsey.com/jquery/css
http://james.padolsey.com/jquery/1.3.2/attr
http://james.padolsey.com/jquery/jQuery.proxy
 
-OR-
http://james.padolsey.com/jquery/#v=version&fn=methodName

If you don’t specify a version then 1.4 is assumed.

The source that’s shown won’t be identical to the actual source, since this source viewer only works by toString()‘ing the functions. I might eventually implement something a little more robust, but it’s going to take time — finding a specific function’s declaration in a source file is tricky, especially when they’re not all defined with the straightforward method: function(){...} or function foo(){...}.

I didn’t really intend it to be an accurate depiction of the real source anyway — just something I (and others) could use to see how certain things are implemented within jQuery.

I hope you find it useful… I know I will!

If you have a read through that thread you’ll notice none other than the infamous David Mark. This is the same person that slammed jQuery (oh, and MooTools) for not being able to “do *anything* right” and then, not too long ago, threatened the jQuery project with legal action over some DOM attributes tests.

David had the following to say about jQuery Lint:

Well, sort of. It’s not so much the Johnny-come-lastly advisor plug- in, but the fact that it is just another horrible plug-in for an equally bad pile of JS [he means jQuery]. Anyone who would use jQuery enough to want to write a plug-in is not going to be the best candidate to wtite a browser scripting “lint.” I can’t see it.

He continues:

The idea (which is sound) is to warn developers when they are doing something incorrect (or ill-advised). I haven’t looked at the code for it (and I’m sure I never will). I find I don’t have to do that anymore as the basic rules always apply.

David doesn’t stop! He still continues:

[Scott Sauyet]
> It seems to be a tool to help new users learn things like that although this code is legal:

$("selector").css("color", "red").css("margin", 0);

> This would be more efficient:

$("selector").css({color: "red", margin: 0});

[David Mark]
You dump it and replace it with something better (and faster). In this case, something like:

el.style.color = "red"; 
el.style.margin = '0';

That’s smaller, faster, more readable, makes no function calls, creates no new objects and is impervious to upgrades to jQuery (typically poison). And, as we all know, jQuery doesn’t work worth a shit anyway as the “logic” in the script is mostly a diary of confused browser watchers. Get the picture?
> That doesn’t indicate anything wrong with the library any more than > any lint program indicates problems with its target environment.
Of course, you don’t need a lint to see what is wrong with the library. It’s as obviously unsuitable as a dissertation written in crayon.

According to David we should be sparing ourselves the obvious folly of abstraction and spend more time writing “smaller, faster, more readable” JavaScript:

// We say:
$('#elem').css({
    fontWeight: 700,
    width: 200,
    height: 100,
    color: '#000'
});
 
// He says:
var elem = document.getElementById('elem');
elem.style.fontWeight = '700';
elem.style.width = '200px';
elem.style.height = '100px';
elem.style.color = '#000';

David, if you’re reading this, maybe you could offer us a response, detailing why you think jQuery “doesn’t work worth a shit” and also perhaps you could enlighten us why verbose and old-fashioned DOM scripting is miles better than progressive abstractions like the one jQuery offers? And if not too much trouble, I would appreciate if you could spare us your slander and ad hominem.

And when I say “detailing why you think jQuery doesn’t work worth a shit” I don’t mean having a go at petty code inconsistencies and syntax peculiarities.

Unlike JSLint, jQuery Lint is a runtime reporter. To use it, you need to include it, after jQuery, in your document:

<script src="jquery.js"></script>
<script src="jquery.lint.js"></script>

jQuery lint’s main objective is to notify you of incorrect usages of jQuery’s API. So, if you pass incorrect arguments to any method then jQuery Lint will let you know. It compares your arguments to the argument signatures in jQuery’s API. It reports via Firebug, although you can quite easily plug-in your own console mechanism.

It has four different error-reporting levels (accessible via jQuery.LINT.level), zero reports nothing, three will report everything, including small things like using css().css().css() instead of css({...}). It’s quite configurable too. You can add your own checks. E.g.

jQuery.LINT.special[1].jQuery = jQuery.LINT.special[1].jQuery || [];
 
// Add check on error-reporting level one.
// Check jQuery method.
jQuery.LINT.special[1].jQuery.push(function(selector, context) {
 
    if (selector === '*') {
        return "Don't use the universal selector!";
    }
 
});

jQuery Lint tries to help you in determining where the problem occurred in your code. It’s not much help to you if it just says, “Err, you called css() incorrectly!”. If it occurred as a result of an event then Lint will say so, and if you’re using a browser that provides a stack-trace as part of its Error object (like Firefox) then Lint will also provide you with the file-name and line number. E.g.

You can read more about jQuery Lint and download it at Github:

jQuery Lint @ Github

The idea of a lint-like script for jQuery has been floating around for some time. I want to thank Dave Methvin in particular, for it was his idea that sparked my interest originally.

This is quite a young project, so there will be bugs. Please report them!

Instead of asking for JSON format, ask for XML, but also add a callback parameter to your query. Voila!

So, in short, YQL allows us to make cross-domain GET requests!

Chris also posted a demo!

With a bit of hacking, we can make jQuery work with YQL for all cross-domain GET requests. UPDATE: I’ve decided to put this in my “jQuery Plugins” repo at Github:

Cross-Domain Ajax mod @ Github

With this mod, any GET request made via jQuery.ajax to another domain will work!

$('#container').load('http://google.com'); // SERIOUSLY!
 
$.ajax({
    url: 'http://news.bbc.co.uk',
    type: 'GET',
    success: function(res) {
        var headline = $(res.responseText).find('a.tsh').text();
        alert(headline);
    }
});
 
// Works with $.get too!

Have fun!

• Being able to screen (validate) new properties, via setter methods.
• Being able to process properties before their “release”, via getter methods.
• Making your abstraction less prone to abuse by other developers — specifically, to protect private variables and states that could compromise the effectiveness of the abstraction.

Grady Booch (author of “Object Oriented Analysis and Design”) describes encapsulation as:

“The process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.”

JavaScript is often considered a toy that doesn’t know of complex design patterns or have the capacity to support techniques such as encapsulation, but, contrary to misinformed belief, JavaScript does have capacity for encapsulation. It’s just quite tricky, that’s all!

Hiding your variables in closures

It’s possible to hide variables in JavaScript. To make this happen we take advantage of the closure:

function Person(name, age) {
 
    this.toString = function() {
        return 'Name: ' + name + ', Age: ' + age;
    };
 
}

If you’re not sure what a closure is just think of it as a function defined within another function. The “child” function has access to the “parent” function’s scope.

You can see that we’re defining the toString method within the constructor.

The only reason to define a constructor’s methods anywhere other than its prototype, is in the situation where that method needs access to variables defined in the constructor’s scope. Above, the toString method needs access to the variables, name and age.

Setters (and getters)

Once we instantiate this constructor (new Person('Jim', 88);), there’s no way to change the name or age — they’re “hard-coded” in the inaccessible “parent” scope.

We can make it possible to change these values by adding a couple of setter (AKA, mutator) methods:

function Person(name, age) {
 
    this.toString = function() {
        return 'Name: ' + name + ', Age: ' + age;
    };
 
    this.setName = function(newName) {
        name = newName;
    };
 
    this.setAge = function(newAge) {
        age = newAge;
    };
 
}
 
var jimmy = new Person('Jim', 88);
 
jimmy.toString(); // => "Name: Jim, Age: 88"
 
jimmy.setName('Jimmy');
 
jimmy.toString(); // => "Name: Jimmy, Age: 88"

This works perfectly, although there are a couple of points to discuss.

First, defining a bunch of methods in the constructor takes quite a bit of room and with a few more setter methods (and getters) the constructor can easily transform into a hard-to-read and hard-to-maintain piece of code. Semantically, this solution fails — a constructor should only contain what’s needed to create an instance — ideally, this shouldn’t include a bunch of method definitions.

Secondly, it’s slow. Redefining a bunch of functions upon every single instantiation isn’t going to be as fast as keeping all the methods in the prototype.

So, either we reach a compromise or we forget about real encapsulation, and settle for something a little less secure. For example, we could define all the getters and setters in the prototype and store our “privates” as public properties, but prefix them with an underscore or some other symbol to signify their private nature:

function Person(name, age) {
 
    this._name = name;
    this._age = age;
 
}
 
Person.prototype.toString = function() {
    return 'Name: ' + this._name + ', Age: ' + this._age;
};
 
Person.prototype.setName = function(newName) {
    this._name = newName;
};
 
Person.prototype.setAge = function(newAge) {
    this._age = newAge;
};

Our constructor is now a lot simpler and the setters work as required. The only issue with this approach is that there’s no real information-hiding going on. Developers using the abstraction can still access the “implementation” (the private state).

Real encapsulation, the hard way

For real encapsulation, the following criteria need to be met:

• You must be able to define private properties within the constructor and methods.
• You must be able to access and manipulate the private properties within the constructor and methods.
• The private properties must not be directly accessible from outside (i.e. as properties on the instance).

To fulfill these criteria we’re going to need to create a small abstraction that will enable us to define our constructor, its methods, and its properties in a plain object, which will then be processed to produce the required constructor and prototype.

In accordance with convention, this abstraction will be named Class. This is how it will typically work:

var Person = new Class({
 
    _name: 'Blank',
    _age: 0,
 
    init: function(name, age) {
        this.name = name;
        this.age = age;
    },
 
    toString: function() {
        return 'Name: ' + this.name + ', Age: ' + this.age;
    },
 
    setAge: function(age) {
        this.age = age;
    },
 
    setName: function(name) {
        this.name = name;
    }
 
});

The underscore prefix tells Class that we want those properties to be private. Privacy is achieved by retaining a truly private (in a closure) privates array, each item within the array represents the private properties of each instance. This will be clearer once you’ve seen the source (below).

Class looks for an init method to use as the constructor.

Here’s the source for Class, excluding the merge function:

function Class(o){
 
    var id = 0,
        privates = {},
        instancePrivates = [],
        constructor = function(){
 
            this.__id = id++;
 
            // Copy privates over to new privates obj,
            // just for this instance.
            instancePrivates[this.__id] = {
                privates: merge({}, privates),
                constructor: this
            };
 
            if (this.init) {
                this.init.apply(this, arguments);
            }
 
            return this;
 
        },
        m;
 
    function method(name, fn) {
 
        constructor.prototype[name] = function() {
 
            var i, ret,
                thisPrivates = instancePrivates[this.__id] || {};
 
            // Check constructor
            if (thisPrivates.constructor !== this) {
                // this.__id has been changed, exit.
                return;
            }
 
            thisPrivates = thisPrivates.privates;
 
            for (i in thisPrivates) {
                this[i] = thisPrivates[i];
            }
 
            ret = fn.apply(this, arguments);
 
            for (i in thisPrivates) {
                thisPrivates[i] = this[i];
                delete this[i];
            }
 
            return ret;
 
        };
 
    };
 
    for (m in o) {
 
        // Test for privates
        if ( /^_/.test(m) ) {
 
            privates[m.replace(/^_/, '')] = o[m];
 
        } else {
 
            method(m, o[m]);
 
        }
 
    }
 
    return constructor;
 
}

There are cleaner ways of implementing this, but just for readability’s sake, we’re identifying each instance with a simple __id property. Yes, this can be manipulated from the outside, but doing so would result in the methods not running.

It has some constraints, but it does provide us with encapsulation:

var Person = new Class({
 
    _name: 'Blank',
    _age: 0,
 
    init: function(name, age) {
        this.name = name;
        this.age = age;
    },
 
    toString: function() {
        return 'Name: ' + this.name + ', Age: ' + this.age;
    },
 
    setAge: function(age) {
        this.age = age;
    },
 
    setName: function(name) {
        this.name = name;
    }
 
});
 
// Testing:
 
var jimmy = new Person('Jim', 88);
 
jimmy._name; // undefined
jimmy.name; // undefined
 
jimmy.toString(); // => "Name: Jim, Age: 88"
 
jimmy.setName('Jimmy');
jimmy.toString(); // => "Name: Jimmy, Age: 88"
 
jimmy.setAge(54);
jimmy.toString(); // => "Name: Jimmy, Age: 54"
 
jimmy._age; // undefined
jimmy.age; // undefined

You can also have private methods, e.g.

var Box = new Class({
 
    _width: 0,
    _height: 0,
 
    init: function(width, height) {
        this.width = width;
        this.height = height;
    },
 
    info: function() {
        return 'Width: ' + this.width +
                ',\nHeight: ' + this.height +
                ',\nArea: ' + this.calcArea();
    },
 
    _calcArea: function() {
        return this.width * this.height;
    }
 
});
 
var myBox = new Box(100, 100);
 
myBox.calcArea; // undefined
myBox._calcArea; // undefined
 
myBox.info(); // => "Width: 100,\nHeight: 100,\nArea: 10000"

Conclusion

The method I used to achieve full encapsulation, while quite novel, isn’t going to be appropriate in all situations. The population and clearing of private variables has to happen on every method call, and so will likely cause a significant overhead in some applications.

That said, I don’t think the overhead will be all that significant, unless you’ve got a crazy amount of private properties/methods.

I hope this post has given you some insight into how you can achieve encapsulation and information-hiding in JavaScript.