Picking up Node.js

Over the last 6 to 9 months I've started playing around with Node.js. Node.js has often been described as "server-side" but really it's about using a javascript engine in all the places you might want to use Javascript, but don't want the browser.

Node is CommonJS implementation. You can run code server-side, you can make command-line tools, I'm sure there is other stuff you can do with it too.

A good place to start learning Node is The Node Beginner Book at least for me it was a great starting point.

Simple command line tool via Node.js

Here is the gist of a little script I wrote recently:

concat.js

It runs on Node, so you'll need that, and npm of course (which installs with Node), you'll also note that you'll need commander, you can ge that by running:

npm instal commander

Once you've got that installed you can use the following to get the usage information:

node concat.js

Which will return

 Usage: concat.js [options]

  Options:

    -h, --help                output usage information
    -V, --version             output the version number
    -f, --filelist [txtfile]  use an input file with a comma separated list of files to concat
    -s, --files [files]       specify the files to concat in the option
    -d, --dest [dest]         the destination file

So, it's a little script that will take a list of javascript files & concatenate them together. You can provide the list either in a text file or on the command line, and in either case it's a comma separated list of filenames.

References:
Inspiration: blog.millermedeiros.com
Node.js: Node.js
Commander.js: on github

JavaScript Coding Style

I've been working with jQuery quite a bit lately, and of course doing anything really unique in jQuery can lead to taking a look at a number of jQuery plug-ins. I came across one, that I find both very useful and extremely frustrating all at the same time.

The plug-in is small and seems both efficient and effective. It does what it was meant to do and seems to do it well. My problem with the plug-in is that I wanted to make it do something new, something very much like it's intended feature, but with a new requirement.

Unfortunately, I found the code difficult to work with, here is a sample:

function memento(t, th) {
 var w,
 m = 0,
 i = 0,
 aux = [];
 if (th) {
  t.cg[removeAttr](width);
  if (t.opt.flush) {
   S[t.id] = "";
   return;
  }
  w = S[t.id].split(";");
  for (; i < t.ln; i++) {
   aux[push](100 * w[i] / w[t.ln] + "%");
   th.eq(i).css(width, aux[i]);
  }
  for (i = 0; i < t.ln; i++)
   t.cg.eq(i).css(width, aux[i]);
 } else {
  S[t.id] = "";
  for (i in t.c) {
   w = t.c[i][width]();
   S[t.id] += w + ";";
   m += w;
  }
  S[t.id] += m;
 }
}

In the interest of full disclosure; there were comments, but I've left them off because I wanted to focus on the coding style not the comments. In fact, leaving them off in some cases made the code easier to read (and clearer where the code seemed to differ from the comments.) In general though, without the comments and the context, I don't think you have a chance of knowing what's happening in this method, and that is what I think is wrong with it.

The 'S' in the code is sessionStorage, the 't' is a table, the 'th' I believe to be a <th> element, so that one really is descriptive, but you cannot tell from the context because the other variables are reduced to single character variables.

I suspect that the original author did this to minimize the code, but in doing so I feel they have created code that is unnecessarily difficult to work with, and I don't get why. Why make all the variables single characters if you're going to leave in all the whitespace? Why hand minify when there's several readily available tools to do it for you? It did more to obfuscate the code than it did compact it, and not knowing the original authors intent, I have no idea why they did it this way.

Anyway, this was from an open-source plug-in that I had been considering using. It's almost perfect for my needs, but the style makes it something I wouldn't ask others to maintain and so, I think I'm going to have to rewrite it from scratch.

Bummer.

So, now I'm curious what others think, have I gone off the deep end? Am I being pedantic? Is this code something you would happily use in a project?

Scope and Variable “Hoisting” in JavaScript

Scope, in JavaScript is Function scope, and variable declarations get moved to the top of their scope.
Because the scope is function scope, the body of a function establishes new context, but if, for, switch, and {}, and anything else that is not a function does not create a new context.
So, to demonstrate that with a little code:

//Global scope
var i;
for(i=0;i<3;i++){
  //Still Global scope
  var myTotal = i;
}
alert(myTotal); // 2

Since the for loop has no affect on the variable scop, all references to myTotal above are in the Global space.
Of course functions do have a local scope, as seen with this snippet:

function newFunction() {
  //newFunction local scope
  var myVar = "Original Var";
  if (true) {
    myVar = "New Var";//newFunction local scope
  }
  alert(myVar); // "New Var"; 
}
newFunction();
alert(myVar) // ReferenceError Thrown

The alert within the function gives "New Var", which is a local variable.
The alert outside of the function throws a ReferenceError because there is no myVar in the Global space, and within the Global space we do not have access to local variables that were declared within a function body.
JavaScript also does something that has been called “hoisting”. JavaScript varable declarations will be moved to the top of their scope. Note, it's just the declarations, not the initialization.
Variable hoisting can lead to some unexpected results, for instance this:

var myVar = "Original Var"
function newFunction() {
  if (!myVar) {
    var myVar = "New Var";
  }
  alert(myVar);  
}
newFunction(); // "New Var"

The value of myVar at the if statement is undefined because the local variable has been declared, but not initialized. The variable declaration is moved to the top of the function, and so is really no different than this:

var myVar = "Original Var"
function newFunction() {
  var myVar;
  if (!myVar) {
    myVar = "New Var";
  }
  alert(myVar);  
}
newFunction(); // "New Var"

That version of the function makes it clear that the myVar is declared at the top of the scope, and that it is at that point uninitialized. It also makes clear that the if statement is extraneous by clearing up what is happening with the local variable.

Moving your variable declarations to the top is a JavaScript “Best Practice” because it turns the code into a more accurate expression of what JavaScript is actually going to do.

JavaScript Book Recommendation

I just read JavaScript: The Good Parts by Douglas Crockford.

Excellent introduction to Javascript, I wish I had read it years ago.

The author tries to stick to just the “good parts” of JavaScript, and does a great job of that, so you'd probably also need a JavaScript reference of some sort as a companion. It is, however, an introductory book I would recommend to anyone coming to JavaScript from a more classical OOP background.