July 26th, 2006

Why Chef Boyardee Doesn't Write Javascript

5 comments on 1138 words

When your hacking away on your code, are you asking yourself questions such as: “Will people be able to read and understand this?”, “Will I be able to come back to this in the future and know why I wrote that line like that?”, “Can others learn by reading this?”

If you never ask yourself these questions and have been indulging in alphabet soup (optimizing for file size) maybe I can liberate you from the sweet flavor of a 4kb Javascript library and convince you that your hurting the very culture in which you cater to.

Why you should say f@*% file size

Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime.

I’m positive you’ve run across the quote above in your lifetime. It’s a simple, but powerful statement on the importance of educating others. The first man in this story once had the same problem as the last guy. He was growing hungry because he didn’t have the skills needed to catch a fish. He eventually learned those skills, solving his problem. Now he’s faced with the choice of passing on this knowledge. Will he merely solve other peoples problems by giving them a fish, or will he teach others the way to solve their own problems? What would you do?

Just like the man who knew how to fish, those of us who are solving our problems are the educators. We release code to the public because we feel it will be beneficial to others who have the same problems. We are in fact, giving a man a fish. So, how can we teach a man to fish?

Take a look at the two functions below.


function add(a) {
  var b = [];
  b.push(a);
}

function add(element) {
  var elements = [];
  elements.push(element);
}

The first function above is the kind you write when your trying to be file-size conservative. Single letter variable names, no context, a nightmare for someone wanting to learn how you solved a problem. Can you imagine if this were a larger script that you wanted to pick apart? Possible, but painful.

I had the opportunity at RailsConf to share more than a few beers with Dan Webb. I wasn’t aware those London blokes liked to drink as much as us southern boys, but we we’re both eventually run out of the bar. ;-) We talked a lot about Javascript. Both of us talked about Prototype, Mochikit–and I think by the end of the conversation I had convinced Dan that file size shouldn’t be a big concern when writing Javascript. On a side note, Dan was an awesome guy; if you ever get the chance to share a drink with him, get prepared to share more than one!

I’m no expert on Javascript, I have only been doing serious Javascript development for about a year now (although I had always dabbled in programming). I never once knew Javascript was capable of the things it was capable of until I found Prototype. One of the reasons I was able to learn so fast was the fact that Prototype was very easy to understand. It made it easy for me to learn the language, not just use the script. So those of you with fears that you’ll never learn the language (see bullet point 4)–this simply isn’t true. If you have the desire to learn something, you will learn it. There is nobody keeping you from expanding to learn the language, the solution to a lot of problems and great examples of how they can be solved are right in front of you. It’s like having the answers to the test.

We can teach by example, but those examples need to be easily understood by someone with the desire to learn.

Javascript developers are the only ones who care

Could you imagine if CSS developers started naming elements a, b, c, etc? That would be hell to maintain by anyone. Stylesheets can get fairly hefty, especially when you start adding print styles, IE specific stylesheets, etc. Let’s not forget the fact that designers will sometimes throw in a 116kb image file in the name of aesthetics. But in the end, Javascript developers will be the first one to tell you how their script isn’t but 5kb in size.

Back this ship up a bit

I’m not advocating that file size is completely irrelevant. I’m suggesting that file size shouldn’t be an issue when writing your scripts. You should release a learnable version, and to cater to those who have real file size concerns, you should release a compacted version.

Some relevant links

Discussion

  1. Aaron Bassett Aaron Bassett said on July 26th

    I am currently working on quite a big overall off my own site and have implemented a system I think should help others learn (the same way i did by viewing source) while keeping my filesize down.

    I’ll be running all javascript files through a compressor but adding a comment at the top letting anyone who chooses to view it know that the uncompressed versions of the file are available in the ‘./source/’ directory.

  2. Amr Malik Amr Malik said on July 26th

    Great Idea! and it needs more traction and more buy-in by opinion shapers such as yourself. “Why” (The Lucky Stiff) has done an excellent job by releasing two versions - one lean and mean, and one nicely documented version - of his Camping framework.

  3. kogent kogent said on July 26th

    Mr becker has released a rails plugin that allows you to use rake to compress your javascript and css files into one of each kind. Also, makes for easier expiration of cached versions and less http requests.

    Check it here: http://synthesis.sbecker.net/pages/asset_packager

  4. Andrew Dupont Andrew Dupont said on July 26th

    I agree nearly wholeheartedly. I think that running your script through the Dojo Compressor or a similar tool can be valuable, but only as a final step — that is, right before you ship/launch/whatever, with the understanding that it’s your “compiled” version and that you should should never edit that file directly.

    Otherwise, I couldn’t agree more. The bytes you save by giving your variables cryptic names will be orders of magnitude less than the bytes you’ll save by running your code through a compressor and/or using mod_gzip.

  5. Tobie Tobie said on August 10th

    Thanks for a great new article.

    Choosing good variable and function / method names is in my opinion the most important step to writing understandable and maintainable code.

    Paradoxically, using good variable and function names often reduces the need to comment the code, and can thus lead to shorter code…

    However, and this is something I stress in an article I just posted on my blog, disregarding file size issues should not mean allowing verbose code to creep in.

    Perhaps the key is to shift our attention to writing DRY code rather than short code.

    This should lead to expressive, short and maintainable code which is all we hope for.

Sorry, comments are closed for this article.