Best practices: 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

So I was asked yesterday the following:

Why does Browser use merge but Element use implement?

And after composing a lengthy reply, I thought it might be useful to post it for others: | Read the rest »

I was helping someone today with their javascript and they asked me about how and when I manage errors in the classes and functions that I write. I wrote him back an email which I think actually could be useful to others, so here it is.

There are three types of error handling that I use:

• Graceful: if possible, just ignore the error and continue with some default state or without a meaningful value
• Debug: throw a warning to the dbug.log method but continue otherwise
• Break: Either explicitly throw an error or (more often) just let the error that is thrown at runtime be thrown

| Read the rest »

As you know, I'm all about the tutorials. Here's one via Ajaxian that seems useful if you're new to the js language:

I have to say that at one point, I truly thought that JavaScript was using some type of “black magic”. Things such as closures really threw me for a loop and I was fortunate to have some good folks to walk me through some of the tougher concepts. Not everyone is as lucky and thankfully, we have developers like Christian Heilmann who continue to put out great postings that cover a broad range of topics and experience levels.

In his latest posting, Christian outlines certain JavaScript shortcut notations which make understanding specific JS techniques a whole lot easier. For example, when dealing with objects, there’s the involved way of defining objects:

var links = new Object();
links[’Cute Overload’] = ‘http://cuteoverload.com’;
links[’I can has cheeseburger’] = ‘http://icanhascheezburger.com’;
links[’Pencils at dawn’] = ‘http://pencilsatdawn.wordpress.com’;
links[’Hobotopia’] = ‘http://apelad.blogspot.com’;

and then there’s the easier way using object literals:

var links = {
‘Cute Overload’ : ‘http://cuteoverload.com’,
‘I can has cheeseburger’ : ‘http://icanhascheezburger.com’,
‘Pencils at dawn’ : ‘http://pencilsatdawn.wordpress.com’,
‘Hobotopia’ : ‘http://apelad.blogspot.com’ // < -- again, no comma!
}

Christian provides plenty of great examples that should substantially help new JavaScript developers.

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...

Precaching isn't anything new; we were cramming 1x1 pixel versions of our graphics into the footer of our home page back in the day so that after the user clicked through from our splash screen the home page would load quickly. Ahhh, the good ole' days.

Anyway, Ajaxian has a post up today on a new twist: anticipating what your user is about to do based on what they are doing on the current page. In this case, it's Yahoo anticipating that if, hey, you're typing something my search boxen, then you're probably gonna end up on my search results page. So why not go ahead and load some of those dependencies now?

Yahoo! Search does an interesting bit of caching. To see it in action, go to the main search page with Firebug enabled and ready (or any tool that lets you see network traffic). Then type any character into the search input box and you will see some traffic kick off to download items such as:

http://us.js2.yimg.com/us.js.yimg.com/lib/s3/ysch_srp_clean_200711061918.css
http://us.js2.yimg.com/us.yimg.com/i/us/sch/el/att_hdspr_1.6t.png
http://us.js2.yimg.com/us.js.yimg.com/lib/s3/ysch_srp_clean_200711051714.js
http://us.js2.yimg.com/us.yimg.com/i/us/sch/gr2/sprt_srp_core_6.gif
http://us.js2.yimg.com/us.yimg.com/i/us/sch/el/ng_bg.png

What are these files? They are artifacts for the results page. So, Yahoo! groks that you obviously are going to do a search once you start to type something in, so why not go ahead and preload the files that are needed as part of the results page? Nicely done.

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 »

This post over on ajaxian today led me over to d'bug, a blog by Brian & Stephanie Reindel. The Ajaxian post points to their recent post "How to Choose a Javascript Framework" which is a brief overview of what to look for in choosing. They don't endorse a particular framework but rather clue you in on what to look for.

But this article led me to "Mastering Javascript - concept and resource guide". Holy guacamole. This article is great. It's very direct and to the point and lists out the main things that you really need to grok to be a javascript bad ass:

• Access Control
• Accessible Javascript
• Closures
• Classical OOP
• Concepts in AJAX
• Memory Leaks
• Namespaces and Self-invoking Functions
• JSON and Object Literal Notation
• Security

Each item has a quick one or two sentence description followed by 3-5 links to deeper resources on each topic. Then, after all this, there's sections of links to JS articles, tutorials, and publications, Javascript tools, and finally frameworks.
This is going on my list of links for developers getting start with javascript and even if you think you have these bases covered its worth bookmarking it. Terrific stuff!

About a year or so I went to see Bill Scott give this talk down at a gathering hosted by Google (he worked for Yahoo at the time though). The talk was great but I felt I was the wrong audience for it (though I found it very informative). Really, the people who needed to see it, were designers, product managers, and engineers. The talk is awesome as it goes through all the challenges to designing and building user interaction with tons of examples and patterns. On top of that, Bill was a fun speaker.

So I emailed him and asked if he'd be interested in bringing the talk to CNET and, to my astonishment, he did. Maybe 75 of our staff crowded into our largest conference room and watched his presentation. Afterwards I got a lot of thoughtful comments and questions; he had a real impact.

There were, however a lot of people who didn't get to see this lecture and I'm glad to see that Yahoo got footage of him giving it and have posted it for anyone who missed it. It's great stuff.

Blog post on the YUI blog>

Video on YUI Theater>

About a year and a half ago I started focusing on javascript again. I'm not really a developer here at CNET (though you'd be hard pressed to tell) but javascript was a means to an end and I didn't really have anyone here that could do the work, so I rolled up my sleeves, unaware that I'd be spending this much time on the subject. It's a good thing I find this stuff fun.

Anyway, over the course of that time I learned a lot of the ins and outs of writing javascript well. I blogged about many of these discoveries along the way here on this blog. But if you're just getting started with javascript, or you suspect that you're writing things without really understanding them, or maybe you're using javascript the "old way" or whatever, where do you start?

All my tutorial work just assumes that you know a lot of these ins and outs and doesn't spend much time talking about the whys of "new" javascript methodology.
Over my lunch break I thumbed my way through Jonathan Snook's Accelerated DOM Scripting with Ajax, APIs, and Libraries and if you feel like you need a primer on how to do "modern" javascript, it's a great starter book. It covers a lot of stuff from the DOM to Ajax, closures and more.

It touches on Libraries (prototype, YUI, jQuery, Mootools, etc.) but it's not going to teach you to use them. Instead it shows you a lot of the conceptual stuff going on in frameworks and helps you understand modern browsers and the javascript concepts that they implement.

If you're just getting started with javascript, I highly recommend it. Even if you're already using a framework, you can pick up some good practices from the examples and illustrations and detailed under-the-hood information.

Despite it being a rather technical book, it's written so that even if you're new to javascript you can learn a lot from it. It will help if you have experience with programming in general, as it assumes you have a general understanding of object oriented practices, but beyond that the book is very approachable.

-A.N.