My main problem with CSS is that it’s a markup language with added inheritance. “DAMN YOU CASCADE!!”, I’ve screamed this so many times at work. I spend far too much time fighting legacy code, the cost of re-factoring would be significant so I add another !important or add an ID to the selector. Constantly overriding is a bad smell. CSS doesn’t scale without being explicit.

There is a big mental shift when moving from CSS to SASS. Thinking of things as modules helps.

.clickable {
  color: blue;
  &:hover {
    color: red;
    }
  .ie & {
    padding-left: 1px; //some pretend box-model hack for IE
    }
  }

The above example uses the SCSS style. Note the use of the ampersand character to denote ‘this’. SASS allows us to encapsulate state and behaviours within a module in pretty much the same logical way that I would approach a JavaScript module.

Reuse can be achieved with variables, and inheritance patterns using @extend or @include.

$column-width: 256px;

@mixin astract {
  white-space: nowrap;
  overflow: hidden;
  width: $column-width;
  }

.clickable {
  @include abstract;
  color: blue;
  &:hover {
    color: red;
    }
  .ie & {
    padding-left: 1px; //some pretend box-model hack for IE
    }
  }

.special-clickable {
  @extend .clickable;
  border: 1px solid: blue;
  }

I love that we can achieve DRY code in this way. Sure you can extend style modules in CSS, but the relationships are defined explicitly in the HTML not in the stylesheet. This is a massive discoverability problem. SASS allows us to define these relationships in one place.

This is one way of achieving the same thing in CSS. Note that I’m also providing a HTML example.

.clickable {
  white-space: nowrap;
  overflow: hidden;
  width: 256px;
  color: blue;
  }
  .clickable:hover {
    color: red;
    }
  .ie .clickable {
    padding-left: 1px; //some pretend box-model hack for IE
    }

.special-clickable {
  border: 1px solid: blue;
  }

<button class="clickable special-clickable">click me</button>

As I mentioned earlier, there is a downside to using SASS, it compiles to CSS. It produces CSS without the same level of code re-use that you might strive to achieve yourself. SASS is lazy, especially where mixins are used. Generated CSS becomes bloated quickly, load time of the web page increases.

As with so much in our Industry, it’s a trade off. SASS is genuinely a more managable and enjoyable way to style the UI. But as a tool for building CSS? It’s as good as it can be, which isn’t quite good enough. The CSS bloat issue only begins to appear on larger UI’s, is that ok? I guess that depends on how bandwidth sensitive your users are. And selector performance? I haven’t noticed any problems though stylistically I would say that SASS encourages deep nesting of selectors which may be an issue.

In this day and age modern web browsers and network infrastructures can easily absorb the extra weight. CSS file sizes generated from SASS are in no way comparable to the files sizes you might expect from many JS libraries. And CSS selector performance is barely worth monitoring to be honest (Unless your users use IE6).

I’d recommend you have a play with SASS if you haven’t already, but you’re going to have to let go of some of your CSS sensibilities before you begin to enjoy it.

They can be used for defining private variables, and storing variables outside of a functions life-cycle.

JavaScript has function-level scope only, so unlike other C languages a ‘for’ or ‘if’ block won’t hold scope.

for (var homer in ['doh!','ray','mee']) {
// do something with homer
}

console.log(homer); // logs 'mee'

var homer = 'hmmmm donuts';
if(true){
var homer = 'doh!';
// other code
}
console.log(homer); // logs 'doh!'

To create scope within the if block we could do the following:

var homer = 'hmmmm donuts';
if(true){
(function(){
var homer = 'doh!';
// other code
}());
}
console.log(homer); // 'hmmmm donuts'

But generally it’s not good practice to reuse variable names for different purposes.

In the global scope, variables resolve to the global object ‘window’. ‘this’ in a global function will be the global object, but variables defined within that function wont resolve to the global object. Functions have there own activation object.

function(){
var homer = 'woo hoo';

var myobject = {
homer: 'spiderpig, spiderpig...',
say: function(){
console.log(homer);
console.log(this.homer);
}
}
myobject.say();
}

From this example we first log ‘woo hoo’ from current function scope then ‘spiderpig, spiderpig…’ as defined on the object.

The containing function is instantiated with the ‘new’ keyword

var me = this;
function Test(){
	console.log(this === me);
}
var myTest = new Test();  // false

Or.. The function is called on an owner object.

var obj = {
myFunc: function(){
return this;
}
};
console.log( this === obj.myFunc() ); // false

Take this example, what do you think will be logged?

var i = {
myvar: 'something',
invoke: function(callback){
callback();
}
};

var obj1 = {
myvar: 'default',
counter: function(){
if(!this.myvar){
this.myvar = 'foobar';
}
console.log(this.myvar);
}
}

i.invoke(obj1.counter);

Answer: ‘foobar’ gets logged.

‘this’ gets defined when the activation object is created for the current execution. The function reference is executed without an owner object so this will resolve to the global object;

What’s worse about this is that window now has a new property called myvar.

To complicate matters further you can explicitly define ‘this’. Either by (re)assigning the method to the desired owner method or by using the call and apply methods.

i.counter = obj.counter;
i.counter() // 'something'

obj1.counter.call(i); // 'something'
obj1.counter.apply(i, []); // 'something'

They are basically the same method except that apply() will let you pass in the arguments object (or an array of arguments).

• Lexical Environment
• Variable Environment
• This binding

The scope chain represents an array of parent ‘Variable environments’ up to and including the global variable environment.

Each Variable environment is in fact an object called an activation (or variable) object. Though not a real object in the normal sense, it does have properties which can be accessed.

{
__parent__ :[Object reference],
arguments: [Lots of fun that I wont go into now]
this: [Object reference]
mylocalVar: [undefined]
}

The above example represents the activation object after the initialisation of the current context, the myLocalVar property is a local variable.  At this point the activation object is sometimes referred to as the Variable object, as far as I understand they are essentially the same thing (if for the moment we pretend the with() method doesn’t exist).

The ‘this’ property  refers to the owner object (by default this is the global object .i.e. window).

The __parent__ property is a reference to the parent activation object. This object is not explicitly accessible, though access to properties on this object are implied from the scope chain.

The global context is some what confused, ‘this’ resolves to the activation object itself thus…

var foo = 'bar'
console.log(window.foo); // bar
console.log(this.foo); // bar

Awesome, I got one by going to their site, creating an account, and then running the curl command they gave me to request a coupon.  I think they make you do the last step to make sure you are actually a geek…  A week later I got an email explaining how to use their API to get the coupon.  I logged in, and provisioned the machine.

Deployment is easy with git, and they provide a good Get started guide.  I had some problems because the version of Node I had locally was older than the one installed by default on the Joyent sever.  You can define which version you want to use with a config file, though best stick to the latest version to avoid versioning issues with other node modules like Express.js.  They have npm installed as well so it is really easy to install he modules you want.

#WIN

The big hurdle for integration at my company was that we are already tied to another JS test framework, JsTestDriver or JSTD for short.

JSTD is awesome.  It’s a ‘remote javascript console’ which allows the execution of JS tests via the command line.  Unlike similar products such as Blue Ridge JSTD does not provide headless testing.  Tests get pushed using the command line to a server, the server can run either locally or somewhere on the accessible network. Slave browsers have to be set up to listen to the server.  When the server gets invoked the test are executed simultaneously on each browser, the results are fed back to the command line.

The nice thing about JSTD is that it fits well with continuous integration systems.  There are a few ways you could set this up.  My preference is to have a server permanently running with Internet Explorer, Firefox and Chrome as slaves (best keep them on a unused PC or VM).  Tell Team City to watch for code changes and trigger test execution via the command line.  JSTD will create JUnit reports, Team city can watch this directory and show failed tests in its UI.

There is a Jasmine adapter for JSTD, by including Jasmine and the adapter in the JSTD config we can write Jasmine style tests while keeping the benefits of JSTD (like Team city integration, JUnit reporting, remote hosting).  Moving to Jasmine does not create conflicts with existing tests, they carry on working as before.

So what do the tests look like, and why might it be better than your current setup?

Jasmine provides a much more language-centric approach to writing tests, for me it’s far more readable.  It’s designed to support BDD, its syntax encourages clear separation of context and specification.

describe("myJsComponent", function(){

  describe("when the sky is blue", function(){

    beforeEach(function(){
      // set up context
      // initialise JS component
    });

    afterEach(function(){
      // clear up context, unbind events, destroy DOM
    });

    it('should shout something to make you go outside ', function(){
      expect(  myJsComponent.shout()  ).toBe( "why are you inside?" );
    });

    it('should not say something to make you stay inside ', function(){
      expect(  myJsComponent.say()  ).not.toBe( "stay here, grab a coffee" );
    });

  });
});

The best thing to do is literally walk away from it, if you have the luxury of time then use that time to talk to others, research.  Or even better, pick up a guitar, draw a pretty picture; do something else.

I read recently that the sub conscious is more active than you might think.  It is almost completely responsibly for problem solving.  Sounds strange but how many times have you got stuck with something then after an hour perhaps a day figured it out, even if you’ve spent the time doing something completely different.

Here is a good talk on Hammock Driven Development which reiterates that giving time to solving a problem works.

Once you understand a problem then it is best to strongly define that solution, try to imagine it, write it down or draw it if possible, talk to others about it. The solution should be terse and simple. It should not define a product or feature, it should explain how Given X is true, When Y is doing that Then Z should do this.

I use the Given, When, Then terminology at work to define the goal of the solution in development. Our QA team also use it to define test plans to affirm that the solution does indeed enable the intended goal.

In the UX domain there is this concept of Goal Driven Design.

“Given user A is a new user When user A first hits the web app Then user A should be encouraged to invite other people.”

The above goal defines a business objective to increase virality, and represents a small chunk of a user story.  There could be many solutions to this, a bright pink invite button which leads to an invite form, perhaps the first screen they hit asks them to connect with facebook and/or gmail. Whatever the solution is, it should achieve the set goal as simply as possible, if this is the main goal then this should become the primary part of the design, everything else should become secondary or better, non-existent.

Break problems into smaller chunks and define end goals to develop better, simpler solutions.

I very quickly built a hello world app, it was really easy.  Great I thought, what next … A real time chat app?

A few hours later I’d built just that, albeit mostly using the Socket.IO chat example. Socket.IO is ridiculously powerful, it enables push messaging from the server to the client and apparently scales really well.

So then I wanted to build multiple pages, multiple chatrooms. Enter Express.js. Express.js makes URI routing, session handling and view rendering so much easier. It’s easy to use as well.

Next.. Chat rooms are boring, lets add some HTML5 in the form of Canvas.  Taking a simple jQuery canvas plugin called Scratch Pad and hooking it up to Socket.IO I was able to push custom events like ‘startDraw’ down to the server whereupon the server broadcasts that event to all the listening clients, the client then updates the canvas.

By the following weekend I had built a real time chat application (and I mean real time) which also enables collaborative drawing.

I’m am really loving Node.js at the moment.

A JavaScript toolkit like jQuery will go a long way in helping you with this, normalising all of the events and hiding the hacks. Let an existing toolkit do the hard work.

With regard to CSS layouts, you could trying using an existing grid framework like 960 or Blueprint (tbh I don’t think they are that reliable). Alternatively, use a HTML 4 doctype to avoid quirks mode and remember hasLayout.

IE6 is terrible at DOM traversal and manipulation; minimise the size of the DOM and always use IDs to get what you want, or at least use an ID to add context to your traversal. Unfortunately jQuery methods like live and delegate use DOM traversal to work out if a callback should be fired or not, there are some good notes on this by Paul Irish and on the jQuery discussion board.  DIY event delegation wins here and is quite easy to do. More often than not you can limit DOM walks and still provide the same functionality, with regard to event callbacks bound to form inputs you don’t need to do any DOM walking at all because you can’t have a child element of an INPUT or TEXTAREA.

If that’s not enough then you can investigate any problems with the IE Developer Toolbar or dynaTrace Ajax, the latter being the best thing since the invention of firebug.

Below is a simple example of some HTML which has a link (with a child SPAN) and an INPUT – imagine they are deep in the DOM, perhaps in a nested table.  If I use live or delegate to bind events to these elements, then I invoke that event within the context area, jQuery will walk the DOM from the element the event bubbled from to the context element; this could be a traversal of ten or more elements.  Now imagine you have twenty or more event bindings.  The cost of using live or delegate quickly becomes apparent, especially in IE6.

<a href="#" class="specific-link"><span>My link</span></a>
<form action="//myResponsePage">
    <input type="text" />
    <input type="submit" />
</form>

Below is an example of how you can use regular event binding to create your own optimised delegation method. This example is defined as a jQuery plugin. For elements that can not have child elements there is no DOM traversal, for other elements we only ever take three steps up the DOM. The number of steps will depend on your application but I can’t imagine you’d ever want more than five steps.

(function QuickDelegateClosure($){

	var hasNoChildrenRegEx = / input| texarea| select| img/;

	$.fn.quickDelegate = function(selector, event, callback){
		return this.bind(event, _matchSelectorAndInvokeCallback );
		
		function _matchSelectorAndInvokeCallback(event){
			var target, steps = hasNoChildrenRegEx.test(' '+selector)
					  ? 0
					  : 3;
					  
			target = _getClosestWithinNumberOfSteps(event.target,selector,steps);
			if( target ){
				return callback.apply(target,[event]);
			}
		}
	};

	function _getClosestWithinNumberOfSteps(target, selector, steps){
		var count = 0;
		do {
			if ($(target).is(selector)) return target;
		}
		while( (target = target.parentNode) && count++ < steps );
	}
})(jQuery);

And below shows how we might invoke this plugin.

$(function(){
	$('body')
		.quickDelegate('.specific-link', 'click', doSomething )
		.quickDelegate('input[type=text]', 'keypress', doSomething );

	function doSomething(){/*Your code*/}
});

I wrote this pretty quickly, the regular expression it uses to determine if the selector is for an element that has no children is pretty crude. I haven’t formally tested the performance gain of using this compared to using jQuery.delegate though I’ve been impressed with the performance of click and keypress events in IE6 using the same technique. The performance in the application I was working on was notably increased.