JavaScript Styles from Worlds Past

Those who fail history are doomed to repeat it

Programmers have used JavaScript as a creative outlet since the dawn of the web. The bare-bones nature of JavaScript allows for expressive code, and with expressive code comes interesting ways to write it. Much like fashion, various styles of have come and gone over the years: some good, some bad, and some unforgettable.

Learning the strengths and weaknesses of each of these styles gives us a closer look into where JavaScript has come from, where it is headed, and how we can be ready for it.

Below I’ve listed a few styles that define key points in JavaScript’s history.

Comma first

Some called it the “wild west.” A ragtag group of hackers set out on changing the world, bringing server-side JavaScript to the masses. An entire ecosystem was to be born, a civilization to be built — from scratch. There were no rules here, only commas. Lots and lots of commas.

So many commas in fact that people would misplace them. Issues like these:

var a = 5,
    b = 6,
    c = 7
    d = 8,
    e = 9;

were commonplace. How do we manage all these commas? We put them in plain sight: at the beginning of the line — making missing ones much easier to spot.

var a = 5
  , b = 6
    c = 7
  , d = 8
  , e = 9;

This style is still prevalent in many codebases, but others have ditched the convention, citing that “YUI compressor will fix it anyway.”

No-indent

Inspired by poorly-formatted PHP questions on WebmasterWorld, the “no-indent” style placed each line of code at the first column of the screen. Every line was just as important as the previous one — no favoritism or gross callback nesting here. Coders could focus on more important things, as worrying about 80-character line limits became a thing of the past.

db.get(‘user-1234-password’, function (err, value) {
if (err) {
throw err;
} else {
md5.secure(value, function (err, safePassword) {
if (err) {
throw err;
} else {
db.put(‘user-1234-password’, safePass, function (err, value) {
res.send(‘looks good’);
});
}
});
}
});

Callback hell was successfully defeated, but many claimed the new style made code look like handguns and it subsequently faded into obscurity.

Spreadsheet

As an attempt to attract more “business types” to JavaScript, a select few put forward a new coding style to reflect the tools those individual were comfortable working with. Playing off of the traditional “ASCII-art indentation” style seen here:

// Assignment operators are aligned for a v8 performance boost
var counterIndex = 0;
var result       = db.get(‘key’).on(‘data’, console.log);
var itemList     = [‘apples’, ‘bananas’, ‘oranges’];
var prefix       = ‘BETA-’;

The “spreadsheet” style involved tabbing code segments to form orderly columns. The result was more user-friendly, cleaner, and more consistent. Errors were no longer defined by the cryptic “line number:column” schema, but instead could be defined as a cell in a spreadsheet (“Syntax error: Line 4 column 27” v.s. the much cleaner “Syntax Error: C6”).

This style was abandoned when Office 2007 came out and no one could find the WordArt menu.

Prose

There’s a saying in JavaScript: “Never look back” and the “prose” style reflects just that. In contrast to the “no-indent” style where we don’t indent any lines, in prose we don’t stop.

if (shoppingCart == []) {
  for (var i = 0; i < displayItems.length; i++) {
    addToCart(displayItems[i]);
  }
  return false;
} else {
  return true;
}

Typical JavaScript code backtracks. We indent a block, then undo our hard work by un-indenting later on. Is that progress? No. Compare this to prose style:

if (shoppingCart == []) {
  for (var i = 0; i < displayItems.length; i++) {
    addToCart(displayItems[i]);
      }
      return false;
        } else {
          return true;
            }

Prose-style code shows effort. A waterfall of bytes cascading into a beautifully-crafted web experience your customers will never forget. In JavaScript we move forward, not backward, and with the prose style we can express that through our code.

This style of code lost its following after one manager didn’t like it and like all of a sudden I’m the bad guy?

Moon coding

As a rogue marketing strategy by NASA during the Apollo Missions, coders began flooding the world of JavaScript with a new style of code unlike anything the world had seen before. Convention was shattered, promises were broken, and the name of the game changed forever.

“Moon coding” involved taking ordinary JavaScript code, and shaping it like small moons.

if (shoppingCart == []) {
  for (var i = 0; i < displayItems.length; i++) {
    addToCart(displayItems[i]);
  }
  return false;
} else {
  return true;
}
var fibonacci = function fib(n) {
  if (n < 2) {
    return n;
  } else {
    return fib(n-1) + fib(n-2);
  }
};

Became:

          if(
      shoppingCart
   == []) { for (var i
  = 0; i < displayItems
 .length;i++){addToCart(
   displayItems[i]); }
   return false;}else{
      return true;}              var
                             fibonacci =
                          function fib(n){
                         if (n < 2) {return 
                         n; } else { return 
                            fib(n—1)+fib(
                               n-2);}

The mystery of these “code balls” remained unsolved for nearly 30 years, until AOL ’s Keyword Search® successfully uncovered several classified NASA documents outlining the approach.

Not much is known about how the moon coding fad ended.

Which of the above styles do you recognize? Many of them have left their mark on JavaScript — in fact, I bet your codebase contains many different styles and conventions. Who knows what the future holds, what sorts of shapes and arrangements we’ll see in the future. Zig-zag? Comma-never? Underscoreza-palooza?

I’ll leave those as an exercise to the reader.