My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
The second talk I attended at NFJS was Stuart Halloway's JavaScript for Ajax Programmers. I had planned to attend a different session, but all the seats were full, and Stuart's presentation was in the large room, so I figured I could sneak in a bit late without anyone taking much notice.

After attending the session, I wasn't upset that the other one had been full - Stuart had quite a few tidbits of solid advice to give us. The funny thing is, I read his blog and didn't realize he was at the conference until I entered the room and saw the first slide. If I had known, I would have likely attended his presentation anyway, so the fact that the other one was full was a stroke of luck in that regard (although, I know it would have been good as well because I've been in courses from the speaker).

The presentation was heavy on code (not a bad thing!), so it will be hard for me to translate that into a blog post. Instead, I'll focus on some of the ideas he presented that translate well outside of JavaScript, and leave it to you to see him present the code some time. I'd recommend it. As with my write-up on Scott Davis's Groovy: Greasing the Wheels of Java, Stu gets "all the credit for the good stuff here. I'm just reporting from my notes, his slides, and my memory, so any mistakes you find are probably mine. If they aren't, they probably should have been."

Use Firefox, where the Diagnostic Tools Live
We all write stupid code, Stuart told us. There are five mistakes for every good idea. This is amplified in JavaScript, since it is functionally more dense a language than most we are used to. Therefore, we need to test much more often in JavaScript than we might in Java - waiting to test every 30 lines is too long, and it will make you miserable.

He started off immediately getting the audience involved in "conference programming" (I think is what he called it), as opposed to pair programming. For this, he presented some code and showed it in the browser, and we needed to find all the bugs (and most of them weren't very obvious). The lesson behind this was that we should develop in Firefox, "where the Diagnostic Tools Live." There were others as well, but they wouldn't be helpful without exploring the code.

$, and teensy-weensy method names
Stu then led us into the $(object_id or object) method. $ was created in Prototype (which has a new domain name since I last visited), and is "now idiomatic in many libraries." For those of you who are unaware, $ wraps document.getElementById() so you don't have to type that monster of a method call so often. You can pass it any number of arguments, of a string or an object, and it will return them as an array of the objects you requested.

That's not the interesting part, however. The conclusions (or lessons learned) are what excites me. First, we should "handle variable argument lists" and "handle different argument types", both "where reasonable" (of course). Obviously this only applies in languages which allow such things - but the point is to examine your situation and see if doing these things would make life easier, and do them if so.

The best part was something I hadn't thought about before, which explains the name of the method ($), and why it's a good name. You're always told to choose descriptive names for methods and variables, and that is certainly sound advice. On the other hand, $ isn't descriptive at all. So why is it a good name here?

It's a good name because you use it all the time, you aren't likely to forget it, and you only need to tell someone else once when they ask what it is. Therefore, methods should be named in proportion to how often they are used, with the lower frequency generally having longer names. You don't want to go off in the deep end with this, but $ is in my estimation one of the best things to ever happen to client-side browser scripting.

Three models for handling an Ajax Response
Stuart went on to defined three approaches to processing Ajax responses: the view-centric, code-centric, and model-centric Ajax models. The mechanism for view-centric is using $('objectID').innerHTML='response text' to redraw parts of a page.

On the other side, the code-centric approach uses eval on the response text, while the model-centric version parses response text, with using JSON as an example. Stuart showed live examples of each approach, but I'm not going to get into those here. I've used them all, but I never took the time to see them as different paradigms, so that's what interested me the most. However, if you'd like to know more about the approaches, don't hesitate to ask!

He also covered the object model prototype provides for JavaScript, but since that is better explained in code that I was trying to avoid in this post, I'll point you to the Prototype docs.

JavaScript is harder than Java
The final thing that struck me as quite interesting was Stu's discussion of why JavaScript is harder than Java. In fact, it wasn't so much that it's harder that was interesting, but that he went through the proper response when someone says "We'd use that, but our development team isn't good enough to handle it."

Get a new development team then! His analogy was simple: if your dentist is telling you that procedure X is better for you in this situation, but that he doesn't do it because it's too hard, would you get another dentist, or have him do a suboptimal procedure?

I'd probably get a new dentist (at least for that instance).

... ... ...

Up next is 10 Ways to Improve Your Code with Neal Ford. Look for it in the coming days.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

I'm primarily a Rails guy, so I don't really "write" my AJAX calls, but my current work uses the $

It's a nice argument though about why the name isn't descriptive. When I first saw it, I was pretty stumped, till I looked it up.

Posted by Siddharth Dawara on Jul 19, 2007 at 05:33 AM UTC - 5 hrs

I do like that Rails has a lot of stuff abstracted for you with scriptaculous and prototype as well.

I can't think of one off the top of my head, but I remember in my last Rails project there was still occasion we needed to drop out of the framework and "hand code" some JavaScript. Obviously not a call to the server, but rearranging something on the page I think.

Posted by Sam on Jul 19, 2007 at 07:51 AM UTC - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner