Unfortunately it is this inherent flexibility of JavaScript that actually promotes the unmanageable and unscaleable approaches to client side coding we see in many of the web applications on the net today. The majority of JavaScript I have come across personally has been written in such a way as to get something working as quickly as possible, without any consideration for good code design practices. This isn’t necessarily because the developer writing the code was in any way lazy or under pressure to get something working, but because the language allows things to be done this way (and maybe because the developer didn’t know that there were alternatives).

With the emergence of frameworks such as jQuery, MooTools, Prototype, ExtJS, Dojo, ASP.Net AJAX etc and with a lot more focus being placed on UX, JavaScript is steadily being perceived in a different light. Developers, specifically, are realising that JavaScript can be used and structured effectively, that it doesn’t have to be a mess of cross-browser compatible syntax, that OOP principles can be applied, and scalable solutions can be created without cramming everything into in-line global functions.

Some pretty awful things can still be done in JavaScript without trying too hard. I won’t attempt to tell you what you shouldn’t be doing though, instead I’m going to give some examples of the good things that can be done in JavaScript, specifically how to declare and use objects in JavaScript and how to employ good OOP techniques to create maintainable, reusable and easy to understand code.

Object Literal

var monkey = {
  name: "Bubbles",
  favouriteFood: "Bananas",
  makeSound: function() {
    alert("OohOohAahAah!");
  }
}

monkey.makeSound();

Pros

• Simple: Easy to read, write and understand.
• JSON (a subset of the Object Literal) is commonly used to represent structured data (as an alternative to XML) in AJAX applications.

Cons

• Exists as a single instance, further instances cannot be created.
• Does not support encapsulation.
• Does not support inheritance.

Object Instantiation

function monkey(a) {
  this.name = a;
  this.makeSound = function() {
    alert("OohOohAahAah!");
  }
}

var bubbles = new monkey("Bubbles");
bubbles.makeSound();

When a function is called with the “new” operator it serves as a constructor to instantiate a new JavaScript Object type. The “this” keyword refers to the Object instance that the constructor created. By prefixing a property or function name with “this.” makes it a public member and callable by the object’s consumer.

Encapsulation

function monkey(a) {
  var favouriteSound = "OohOohAahAah!";
  this.name = a;
  this.makeSound = function() {
    alert(favouriteSound);
  }
}

var bubbles= new monkey("Bubbles");
bubbles.makeSound();

Taking advantage of JavaScript closures; the variable favouriteSound has been “hidden” within the object and can be considered a private attribute of the monkey object that has not been publicly exposed using the “this” keyword. Calling myMonkey.favouriteSound returns null/undefined.

function monkey(a) {
  var favouriteSound = "OohOohAahAah!";

  this.getFavouriteSound = function() {
    return favouriteSound;
  }

  this.setFavouriteSound = function(sound) {
    favouriteSound = sound;
  }

  this.name = a;

  this.makeSound = function() {
    alert(favouriteSound);
  }
}

var bubbles= new monkey("Bubbles");
bubbles.setFavouriteSound = "Good evening.";
bubbles.makeSound();

Public getters and setters for local variables can also be simulated.

Inheritance

function monkey(a) {
  this.name = a;
  this.makeSound = function() {
    alert("OohOohAahAah!");
  }
}

function human(a) {
  var base = new monkey(a);
  base.makeSound = function() {
    alert("Get back to work!");
  }

  return base;
}

var karl = new human("Karl");
karl.makeSound();

When a new human object is instantiated a monkey object is returned, with makeSound redefined to suit the human specialisation.

function human(a) {
  var base = new monkey(a);
  var makeSound2 = base.makeSound;
  base.makeSound = function() {
    alert("Get back to work!");
    makeSound2();
  }

  return base;
}

A call to the overridden makeSound function can still be made if needed by creating a reference to it in the human constructor.

Pros

• As “natural” as it gets for traditional OOP programmers.
• Supports encapsulation.
• Supports inheritance.

Cons

• Consumes relatively large amounts of memory when multiple instances of an object are created.

Prototyping

function monkey(a) {
  this.name = a;
}

monkey.prototype.makeSound = function() {
  alert("OohOohAahAah!");
} 

var bubbles = new monkey("Bubbles");
bubbles.makeSound();

The prototype property essentially allows an object’s functionality to be extended.

function monkey(a) {
  this.name = a;
}

var bubbles = new monkey("Bubbles");
var clyde = new monkey("Clyde");

monkey.prototype.makeSound = function() {
  alert("OohOohAahAah!");
}

bubbles.makeSound();
clyde.makeSound();

An object can be extended even after it has been instantiated.

Encapsulation

function monkey(a) {
  this._favouriteSound = "OohOohAahAah!";
  this.name = a;
}

monkey.prototype.makeSound = function() {
  alert(this._favouriteSound);
} 

var bubbles = new monkey("Bubbles");
myMonkey.makeSound();

Although not true encapsulation, the common convention is that members starting with an underscore should be considered private.

Inheritance

function monkey(a) {
  this.name = a;
}

monkey.prototype.makeSound = function() {
  alert("OohOohAahAah!");
}

human.prototype = new monkey;
human.prototype.constructor = human; 

function human(a) {
  monkey.call(this, a);
}

human.prototype.makeSound = function() {
  alert("Get back to work!");
} 

var karl = new human("Karl");
karl.makeSound();

Using the prototype property human is extended with all of monkey’s behaviour, with makeSound redefined to suit the human specialisation.

human.prototype.makeSound = function() {
  alert("Get back to work!");
  monkey.prototype.makeSound.call(this);
}

A call to the overridden makeSound function can still be made if needed.

Pros

• Supports encapsulation.
• The official way to implement inheritance.
• Allows multiple objects’ functionality to be altered after they have been instantiated. Useful for extending closed libraries.
• Memory efficient when multiple instances of an object are created.

Cons

• Syntax looks crazy to traditional OOP programmers.

Is Object Oriented JavaScript really worth it?

It depends. Personally if all I need to do is apply a jQuery slide animation to a widget then I’ll just wrap a simple function inside a $() so it runs when the DOM is ready. If the widget is slightly more complex however, and is reliant upon user interaction with another element on the page, or perhaps displays some dynamic content based upon where on the page it is positioned, then I’ll consider modelling the behaviour using objects.

If an application evolves to a state where widgets need to interface with each other, a drag and drop shopping cart for example, and business rules also need to be enforced such as voucher discounts, purchase limits etc then the solution should be structured in such a way that it is robust, maintainable and easy to understand – OOP without a doubt facilitates a large share of this.

An em is a unit of measurement in the field of typography, equal to the point size of the current font. This unit is not defined in terms of any specific typeface, and thus is the same for all fonts at a given point size. So, 1 em in a 16 point typeface is 16 points.

The web standards and accessibility perfectionists among you will no doubt be avid em advocates, whereas the CSS newcomers among you may not have known the em existed or how to use it. There are valid arguments for and against using the em, here’s a list of its pros and cons:

Pros

• Text-resize accessibility support in IE6 & IE7.
• Can create elastic layouts (although this may now be considered redundant due to modern browsers’ zoom feature).
• Promotes DBG (Design by Grid) and typographic excellence.
• The overall font-size of a website can be changed by altering a stylesheet in a single place e.g. Changing the font size of an element will in turn relatively re-size any text that appears in the element’s children. This could also be considered a con!

Cons

• Calculation needed.
• CSS maintenance can be more difficult on larger scale projects with multiple developers of varying CSS expertise.
• The overall font-size of a website can be changed by altering a stylesheet in a single place e.g. Changing the font size of an element will in turn relatively re-size any text that appears in the element’s children. This could also be considered a pro!

I’m not going to try and convince you to use ems, but it definitely helps to be aware of them and know how they work. All too often have I seen a developer copy and paste CSS from one stylesheet to another in the hope that they can mimmick the look and feel of a particular widget, only to find that their website’s fonts have been blown all out of proportion! This is a tell tale sign that relative font sizes are being used somewhere, and this usually means ems.

The em is a relative font size

The value of an em will always be relative to a base size. This is why a paragraph of text on one website will not look the same as on another website even if both paragraphs are defined as having a font size of 1em.

Example 1

<html>
<head>
  <style type="text/css">
    body {font-size:10px;}
    .widget-1 {font-size:1em;}
    .widget-2 {font-size:2em;}
  </style>
</head>
<body>
  <div class="widget-1">Widget 1</div>
  <div class="widget-2">Widget 2</div>
</body>
</html>

• Widget 1 would have a screen font size of 10px (10 x 1).
• Widget 2 would have a screen font size of 20px (10 x 2).

Example 2

<html>
<head>
  <style type="text/css">
    body {font-size:10px; line-height:1.5em;}
    .parent {font-size:2em;}
    .child {font-size:1.5em;}
  </style>
</head>
<body>
  <div class="parent">
    <div class="child">Child</div>
  </div>
</body>
</html>

• The parent’s screen font size would be 20px (10 x 2) with a line height of 30px (20 x 1.5).
• The child’s screen font size would be 30px (10 x 2 x 1.5) also with a line height of 30px.

The calculation

In the following example we want to write some additional CSS to ensure that the child element has a font size of 10px:

<html>
<head>
  <style type="text/css">
    body {font-size:16px;}
    .parent {font-size:0.75em;}
  </style>
</head>
<body>
  <div class="parent">
    <div class="child">Child</div>
  </div>
</body>
</html>

First of all you need to know the font size of the parent element:

16 x 0.75 = 12px

Using this we can then calculate the equivalent em value of 1px:

1/12 = 0.083em

Now we know the em value of 1px we can then multiply this by the actual pixel value we want:

0.083 x 10 = 0.83em

So the full calculation looks like:

(1/12) x 10 = 0.83em

Which can be simplied to:

10/12 = 0.83em

So all you really need to know is:

Child font size/Parent font size = em value

And the resulting CSS and HTML is:

<html>
<head>
  <style type="text/css">
    body {font-size:16px;}
    .parent {font-size:0.75em;}
    .child {font-size:0.83em;}
  </style>
</head>
<body>
  <div class="parent">
    <div class="child">Child</div>
  </div>
</body>
</html>

It’s quite simple really. The only time it can get complicated is when you want to add a child element, with a specific font size, to a hierarchy of nested elements. Typically you would have to individually calculate the font size at each level. Utilising a tool such as Firebug will aid you greatly in these situations as it allows you to select any element on the page and check its font size in pixels, regardless of whether or not is was defined using ems in the stylesheet. You could also try this handy em calculator.

In “real life”

Typically if ems are being used to define font sizes on a website you will not find any declarations being made in px, even on root elements like html or body. This allows everything to be relative and scalable and provide accessible content resizing via a browser’s text re-size option.

The good news is that modern browsers provide a consistent baseline font size of 16px. So if you wanted a default font size of 12px for your website you can define the body style as:

body {font-size:0.75em;}

The bad news is that IE6 and IE7 are bugged and do not correctly re-size text when the body’s font size is defined using ems (the resizing is very exaggerated and will shrink and grow text to unreadable proportions). The workaround to this bug is to define the body’s font size using a percentage:

body {font-size:75%;}

This works because 75% of 16px is 12px. If you wanted a default font size of 11px you would use 69%. Percentages are obviously another relative unit, and are used extensively for building liquid layouts. Generally if you want to relatively scale your fonts you should stick to the em though, as it provides the best support for implementing consistent spacing and line heights.

Example websites built using ems

Take a look at the following sites that use ems for examples of how to structure your stylesheets.

• http://www.bbc.co.uk
  
• http://www.uswitch.com
• http://www.alistapart.com
  
• http://www.csszengarden.com/?cssfile=/063/063.css

Regardless of how much I think I know now however, I’m still trying to overcome the initial feeling of unworthiness from starting up my own web development blog. I did get some sound advice though from one of the developers I’m working with right now, who told me to write my posts as if I’m my own audience (essentially as if I’m talking to myself), because ultimately I should be using my blog to consolidate my own thoughts and further my own understanding of the subject matter. If this means I can help a few fellow devs increase their understanding of the job along the way then great. If these fellow devs subsequently find holes in my posts then even better! We learn from our mistakes.

The main methodologies, processes and technologies I’ll aim to cover will include:

• XHTML & CSS
• JavaScript
• C# .Net
• Agile (XP)
• S.O.L.I.D
• DDD
• TDD
• DBC (Design by Contract)

Sensei (??) is a Japanese title used to refer to or address teachers, professors, professionals such as lawyers and doctors, politicians, clergymen, and other figures of authority. The word is also used to show respect to someone who has achieved a certain level of mastery in an art form or some other skill.

Nope, I’m not a sensei.

In actuality I am an apprentice, and you wouldn’t believe how long it took me to realise this. It must have been 1 part ignorance and 2 parts pride that was blinding me from the truth; that I wasn’t as good at my job as I thought I was. It hurt to say it to myself and I’m glad that at the time of my realisation there were enough talented people around me to inspire me to get better.

In hindsight I can see that the majority of my colleagues were also in the same boat. We didn’t know that a level of ability much greater than our own could even exist. We were Web Developers, we knew C#, T-SQL, we’d been hacking HTML since we were at school and we were earning £30k salaries. It was great! We were the elite and at the top of our game. But, for some reason, the business was crumbling around us. It couldn’t have been our fault, we were the only good thing going for it, it must’ve been bad management…

These days I have a greater sense of humility. I also have a much greater appreciation for my craft.

It is inherently difficult for a professional to actually acknowledge that he or she is an apprentice. I’ve met and worked with developers who are much better versed in the profession than I, themselves self-confessed apprentices. Admitting that I am an apprentice is no longer a problem for me because it only inspires me to learn more. And with a decade or more of learning and growing I doubt I will still be satisfied about how “good” I am at what I do. Sometimes the amount of knowledge I feel I need to accumulate can be overwhelming, but I cannot see this line of work ever becoming stale and this is what makes me want to keep doing what I’m doing.

This blog is for the apprentice web developers out there.