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