Best practices: Organizing code: Posts

I’ve created a new development repository on Google Code. I wanted to have a separate development environment for people to work on the library without having to work off of the entire CNET Javascript framework repository. I’ll be posting CiUI-only releases there before merging them with Clientside’s repository.
You can also file CiUI specific bugs and feature requests on there. If you’re interested in joining in the development, please come discuss your ideas to our Google group.

CiUI Dev Google Code repository:
http://code.google.com/p/ciui-dev

CiUI Group
http://groups.google.com/group/ciui

On numerous occasions I’ve found myself with some javascript that’s been compressed or just poorly organized and before I could dig my hands into it I had to spend half an hour putting all the line breaks and tabs in place so I could make sense of it.

Less often is it the case that I am looking at someone else’s work and want to understand the source, but it happens. Enter Javascript Beautify. Ajaxian has a post up on it today and I gotta tell you, I love this stuff. Awesome, awesome, awesome. Now, if only there was a CSS Beautify…

We often talk about the latest scheme for compressing and minimizing our JavaScript. The JavaScript Beautify script aims to do the opposite.

Often, you find a site that is doing something interesting and you want to learn how it works. You check out the source and it is cryptic gibberish. This is where the beautifier comes in to make it a touch more readable.

As a test, I took one of our compressed libraries and dumped it in there and what came out was probably better organized than the source we compressed it from…

The d'bug blog has a nice little post on javascript shorthand that's worth looking at if you don't know these tricks. Stuff like declaring variable defaults with the logical OR or using ternary , etc. One thing to be careful of is type coercion. Basically if you say "if (x) ..." you can get a false evaluation if x is an empty string, null, zero, or false. Check out the mootools functions $chk, $pick, and $defined for easy ways to avoid these kinds of things. You can also express conditionals using === and !== to ensure you are evaluating for the right condition.

PLAIN TEXT

JavaScript:

/*

    -----------------------------------------------
    Conditional Shorthand 1
    -----------------------------------------------

    If "a" is not defined, or is not equal to true,
    then "a" is equal to "b".

    Longhand:

        var a, b;
        if ( !a ) {
            a = b;
        }

    Shorthand:

*/

var a, b;
a = a || b;

/*

    -----------------------------------------------
    Conditional Shorthand 2
    -----------------------------------------------

    If some condition is equal to true,
    then "a" is equal to "b", or else
    "a" is equal to "c".

    Longhand:

        var a, b, c;
        if ( true ) {
            a = b;
        } else {
            a = c;
        }

    Shorthand:

*/

var a, b, c;
a = ( true ) ? b : c;

Check out the whole article »

Jonathan Snook has a nice write-up about using private methods in javascript.

With JavaScript, you can create private methods and properties using what Yahoo describes as the module pattern. Here's the basic construct, including a private method:

PLAIN TEXT

JavaScript:

MyObject = function(){

  var privateMethod = function(){ /* do stuff */ };
 
  var obj = {
    publicProperty:5,
    publicMethod:function(){ /* do stuff */ };
  };
 
  return obj;
}(); // run it right away

If you're not familiar with this pattern, it's really quite cool. It takes advantage of closures, allowing the public methods to access the private methods. I've been using this approach in my recent work and it feels nice and works well.

Just today I was asked over in the Mootools forums why we don't create a dependency map like the one in Mootools. My answer there was, basically, that the common code we publish here on clientside is but a small portion of our library. Our javascript spans numerous teams, sites, and applications, and keeping a map like this by hand is probably not practical.

Then today on Ajaxian there's this post about T.J. VanSlyke's alterations to Dean Edward's Base.js to allow him to generate a dependency map of all the classes he writes. This isn't quite the same as mapping out file-by-file dependencies, but it's a start. Considering that Mootools is largely based on Base.js, this shouldn't be too hard to incorporate over there. | Read the rest »

There's a nice article over at Snook's today on writing clean, concise, and reusable javascript.

As a JavaScript developer, you are in many ways an environmentalist. JavaScript is a language unlike most other languages. For when it comes to JavaScript development, we must consider the mantra of the environmentalist: Reduce, reuse, recycle.

It's a short article that's worth reading. All of these concepts are in use in our new framework, and if you're writing javascript for yourself or for CNET or whatever, it's always good to keep these things in mind.

Here's a trick I learned from Valerio (author of Mootools) on how to handle options for classes and functions. After refactoring a couple of legacy scripts I thought I'd share for those of you who might not know it already. This example below uses the Mootools syntax for class creation, but the rest of it can be used even on its own I think. | Read the rest »

Ok, so I've finished as much digging on this subject as I plan on doing (mostly because the pickings seem to be rather slim). Here's jsDoc - a javadoc implementation for javascript.

Comparing this library to NaturalDocs the choice seems to me to come down to two things: syntax and presentation. NaturalDocs gives you a really nice layout and a lot of flexibility in how you write your documentation inline, while jsDoc uses the same syntax as javadoc.

Does it matter if we use the same syntax as javadoc? Do we care if the output looks pretty and has a nicer interface? Which one? Spend a few minutes reading the documentation on each of these packages and sound off here, as the work on the global framework has gotten to the point where documentation is going to start to be the next thing that needs focus.

I've been contemplating a javadoc style javascript documentation tool for a while. Not to write myself but rather to go find one because you just know they're out there. Well, here's one posted recently on Ajaxian. It looks pretty slick, but I'm curious about how well it deals with a broader context. Sure, it'll parse a single js file and dump out some nice looking documentation (awesome), but what about an environment that relies on code from several libraries? Can you link across them? Can you collect them? I need to dig into it some more, but it's a start.

Does anyone have any experience or knowledge of any other javadoc systems for javascript? | Read the rest »

Hi all,

It's been a few days since I posted. I've been heads down on the project to create a global javascript framework for our sites (Redball, at least). I've finished this work (or at least gotten it to a releasable state) and I thought I'd share an update. I plan on documenting it extensively and providing a lot of examples (and teaching it) in the near future, but for those of you who are curious, you can peruse the library now. It's mostly stable (we're still tweaking and adding things) and you can just download them and read them if you want to see what's in them.

They include a lot of functionality, are highly extendable, easily debuggable, and hopefully will be useful. The current framework file is about 30K, but Andy just turned me on to a more efficient javascript compressor that will bring that down to 19K. I can't express how awesome it is to have this thing going out and it managing to pack in so much functionality in such a small package. | Read the rest »