Over the past 6 weeks, I’ve had the privledge of reading some very well defined thoughts by Jeremy Keithabout the notoriously misunderstood language called JavaScript. And for what it’s worth, Jeremy would like to appropriately rename this scripting language to DOM Scriptingwhich I feel dresses up JavaScript into a nice suit and tie to behave and act a bit more professional (like we should be).

This entry is mainly for Jeremy’s benefit, but hopefully other readers will benefit as well. It may even convince some to buy the bookafter glancing over just a few of my comments.

First things first, I took notes while reading the book on separate pieces of paper according to page number and paragraph (if noted). With that said, I’ve done my best to piece together what I felt is appropriate and constructive without detering too much on how nerdy I think Jeremy is. The fact of the matter is, anyone who comes up with a make-believe band called JaySkript and the DOMstersis just asking for it. However, secretly inside I was thinking Oh sweet, how cool is that.

Overall impression

I decided to begin with this first mainly for purposes of those who like to skim and not read far ahead. That’s ok, I can dig that. I’ve done that too…

After finishing the book and laying it down, I learned these three things:

• Jeremy’s love for Simon’s addLoadEvent()which was printed nearly six times over in its entirety throughout the book
• The insertAfter()function. It’s really a shame I haven’t thought of this kind of function before. Similar to the insertBefore()function provided by the JavaScript language, insertAfter does just what you think it does.
• How much Jeremy and I really do think alike. On more than several occassions I challenged myself to come up with a function (or group of functions) based on Jeremy’s description on what he wanted to do, and nearly most of them he had a near exact idea of my own concepts. Weird.

The fine details

The rest of these ramblings are taken directly from the pieces of paper noted in order by page number.

page 96 ^{4th paragraph}: Jeremy said:

Is the JavaScript Unobtrusive? - Ideally, I should attach the onclick eventin the external JavaScript file

An event and eventHandler are two different things. The simplest way to tell the difference is by the mere prefix of ‘on’. Thus, ‘onclick’ is an eventHandler, not an event. Events are attached, eventHandlers are set and are more inline-esk. Yet, they both can be set unobtrusively (as you were referring to).

page 97Another occurrence of event vs eventHandlers.

page 98Jeremy illustrated a few ways to write JavaScript and it felt kind of like a “best practices” dealio on what is considered readable. Not that I disagree with his methods since I practice them myself, I just think it’s mostly opinion.

page 99Jeremy lists 3 sample keywords to avoid in the JavaScript language. I felt this was sort of inadequate. Albeit this being geared more toward developers wanting to get their feet wet with language, I think it would be appropriate to at least put a link to a reference where one can view all reserved keywords. It would be a short and simple addition.

page 110Jeremy said this: Beware of onkeypress. Now, I don’t remember why, but I wrote this down: You didn’t even mention keycodes. Do what you will with that. I’m sure I was on to something…

Chapters 4, 5, & 6: The reader goes through three long chapters before Jeremy lets them know how to create markup on the fly. I read all this without looking ahead and thought to myself We still have this random placeholder (referring to the demo gallery script), when are we going to ditch that!And it wasn’t until chapter seven where you mention creating markup. Possibly something to consider telling the reader: let them know that “we’ll be tackling that issue at a latter point in the book”

It seems in several cases where Jeremy teaches the reader some practices, but then have them unlearn those practices in later chapters. However, I’d refrain from saying “teach”, but more like “demonstrate”. Note to Jeremy: I’m not sure how valid my last comment was, especially coming from someone who is yelling outloud going “What about graceful degradation - we should be creating markup on the fly??!!”

One thing I always thought a good educator does is forwarns. It’s almost like an “I told you so”. If someone picks up your book and after the first six chapters puts down the book for good, they will have walked away thinking it’s ok to keep their <div id="placeholder"></div>. Catch my drift?

page 137: Is it really necessary to itterate through a line four times because it’s more readable?

For instance, Jeremy has this:

4x the iteration

if ( !object ) return false;
if ( !object ) return false;
if ( !object ) return false;
if ( !object ) return false;

Can easily and simply be rewritten like this:

1x the iteration

if ( !object || !object || !object || !object ) {
  return false;
}

In later chapters, I found out Jeremy does actually end up doing this. (note to self, be patient with Jeremy).

page 138: This has a little to do with Jeremy’s love for addLoadEvent(). Not to criticize the function or its usefulness, but I think we can do a little better on how we’re setting up our ‘load’ events. Although addLoadEvent() is simple to include anywhere, I would think it would be more practical to avoid using it so much… perhaps setting up a general loadGroup. For example, instead of this:

multiple instances of addLoadEvent

addLoadEvent(funcA);
addLoadEvent(funcB);
addLoadEvent(funcC);

Try something like this instead:

one instance of addLoadEvent

function myLoads() {
  funcA();
  funcB();
  funcC();
}
addLoadEvent(myLoads);

So in book’s example, it could be rewritten like this:

photoGallery load event

function photoGal() {
  preparePlaceHolder();
  prepareGallery();
}
addLoadEvent(photoGal);

page 146: Here I’m a bit concerned on Jeremy’s interchanging of the acronym “DOM” and JavaScript. In the What not to dosection on this page, Jeremy says:

If you find yourself using the DOM to add important content…

This may be due to my own lack of understanding of what the DOM really really is. I mean really. I can dig the phrase “DOM Scripting”. Yea, it’s catchy and kind of makes sense. It’s like a new wave of scripting. Or better yet: Scripting on the DOM. But here I think what Jeremy really meant is to use JavaScriptto add important content. I am very unclear how you can use the DOM to actually insert content. My understanding of the DOM is that it’s this large object… of your (web) document. The DOM can be manipulated by JavaScript… and not visa-versa.

On the contrary, I could be wrong, but I definitely think I’m onto something…

page 147: Jeremy says:

CSS are very powerful tools

Technically, that’s a very correct statement. But doesn’t it just sound weird? Say the acronym to yourself within the sentence… “See Ess Ess are very powerful tools”. I don’t know, but I’d reword it to say something simple like “Style Sheets are very powerful tools”. You could completely ignore this if it doesn’t make sense.

page 149: Do you really think html will be deprecated entirely? Last I heard, Hakon Lie(Inventor of C.S.S.) thinks html will be around for at least another fifty years according to his tech talk here at Yahoo!. I guess he made a bet with someone.

page 160: duplicate content. Jeremy, you’ve already explained the addLoadEvent() (and its benefits) earlier in the book. You could just throw out a page number and leave it to readers choice is they want to remember.

page 162: On Two possible Solutionsto developing this script, I’m just wondering if the example is a ‘real-world’ example, or just used for the sake of having an example to show off some graceful degredation. Off the top of my head, I don’t remember what the example was for.

page 183: One thing I’ve noticed in general at this point is the lack of reference. I understand this wasn’t going to be an oreilly bible book to list every function in JavaScript since 1994, however it’s nice to know that there’s more out there. On this page specifically, you mentioned the camelCase style for fontFamily, but then fail to mention anything else or at the least point to a reference online where folks can find a complete list of JavaScript style properties.

page 185: Ok, since we’re talkin’ CSS shorthand here, I think my input is valid. For the fontshorthand property, Jeremy has this example:

font shorthand property example

p {
  font:12px 'Arial', sans-serif;
}

One this is for sure, you don’t need the quotes around ‘Arial’ and nor does it need to be capitalized. The only uses for quotes on fonts is when the name of the font has spaces in it. The other issue is there is no mention of unexplicit values that are set such as font-variant, font-weight, font-style, and line-height. Checkout my CSS Shorthand Guide. That’s be sweet if I made it in Jeremy’s book

page 196: I’ve rewritten the stripeTables()to be a bit quicker. The purpose of this function was to alternate row colors of a table. Basically, instead of looping through each row one at a time and adding a className of ‘alt’ to every other row, I felt that it’s only appropriate to ’skip’ every other one by adding 2 instead of one…for example:

stripeTables function rewritten

function stripeTables() {
  ...
  for ( var j=0; j<rowLen; j=j+2; ) {
    // add className to row
  }
  ...
}

page 201: Is there really a problem with appending a ‘ ‘ (space) at the beginning of a className? Seems to work in IE6, Moz, Safari, and Opera. I must be missing something…

page 209: addLoadEvent() strikes again in full effect. lol.

Chapter 11: In general, what happened to DOM Scripting? You’ve snuck in a chapter that doesn’t give Modular CSS justice. Should probably at the least consider putting references to online resources that explain this type of CSS architecture like Bowman’sor Content with Style’s piece on modular css. Just a thought.

page 256: *cough* addLoadEvent()

page 258: Jeremy asks how we could have solved the problem of getting the body to have an id while being in an include file…or something like that. In short, simply take out the body element and keep it on your separate pages. Done.

page 260: Ok, this was freaky, I think I’m using the same exact function on my website without having never seen it before. It’s the one used to append a “You are here” tab. I told you great minds think alike.

page 299: Jeremy says:

Ajax involves the use of JavaScript, CSS, the DOM, & XML

Last I checked, Adaptive Path said it went along the lines of something like “Asynchronous JavaScript and XML”… but I hear where you’re coming from Jeremy.

In Conclusion

Jeremy, if you read this entry (which I hope you have), I would encourage you to take this like any other criticism. I meant it whole heartedly and positively constructive as I possibly could. Not everything I say is correct or needs to be considered. These were just my thoughts from an experienced developers perspective. Overall I think you’ve done very well with the book and I recommend your book to anyone looking to get their hands dirty with the DOM for the first time.

Note to everyone else: Buy this book! It’s everything I would have wanted to say had I been given the privledge to write one.

Oh, and one last thing, Jeremy, looking forward to the beer!

JSJaC is a jabber/XMPP client library written in JavaScript to ease implementation of web based jabber/XMPP clients. For communication with a jabber server it needs to support either HTTP Pollingor XMPP Over BOSH(formerly known as HTTP Binding). JSJaC has an object oriented design which should be quite easy to use. Communication is done by using the XML HTTP Request objectalso refered to as AJAX technology. Your browser must support this.

What is XSTM?

XSTMis made of three projects. The Java implementation is called JSTMand is the base from which the other versions are derived. An adapted version made with Luciano, the author of GWM , is available for GWT . It allowsthis library to be used in a browser. NSTM is a .NET port based on IKVM.

All implementations are compatible with each other so object replication can take place e.g. between a Java server and a .NET Smart Client.

A simple command-line tool to create the folders and helper files for a new JavaScript project/library. As a bonus, you can quickly create a website to promote your project.

When you start a new JavaScript library, how do you layout the source files, the tests, the distribution files? Do you have support scripts to generate distributions from source files? Run your JavaScript unit tests? Generators to create new unit test HTMLfiles?

This JavaScript client library allows you to make Facebook API calls from any web site and makes it easy to create Ajax Facebook applications. Since the library does not require any server-side code on your server, you can now create a Facebook application that can be hosted on any web site that serves static HTML. An application that uses this client library should be registered as an iframe type. This applies to either iframe Facebook apps that users access through the Facebook web site or apps that users access directly on the app’s own web sites. Almost all Facebook APIs are supported.

Using Caja, web apps can safely allow scripts in third party content.
The computer industry has only one significant success enabling documents to carry active content safely: scripts in web pages. Normal users regularly browse untrusted sites with Javascript turned on. Modulo browser bugs and phishing, they mostly remain safe. But even though web apps build on this success, they fail to provide its power. Web apps generally remove scripts from third party content, reducing content to passive data. Examples include webmail, groups, blogs, chat, docs and spreadsheets, wikis, and more.
Were scripts in an object-capability language, web apps could provide active content safely, simply, and flexibly. Surprisingly, this is possible within existing web standards. Caja represents our discovery that a subset of Javascript is an object-capability language

Google Web Toolkit (GWT) is an open source Java software development framework that makes writing AJAX applications like Google Mapsand Gmaileasy for developers who don't speak browser quirks as a second language. Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.

GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Javaprogramming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.