I am right now teaching a four day class of DOM and Ajax in Sunnyvale, California and also do some tech editing for Scriptin with JavaScript and Ajax by Charles Wyke-Smith and I find one thing that is pretty worrying: easy examples of web development practices are dangerous to show these days.

I’m talking about practices that make it easy to get quick results and give readers and attendees “I am getting this – this is easy” fuzzy warm feelings.

One very obvious example is form validation and re-rendering of a form using PHP_SELF and displaying user data using $_GET or $_POST. Unfiltered they are a free invitation for any XSS attack and will turn your server into a spam-hub or bot-net drone. Explaining countermeasures of XSS normally is out of scope for an example that only shows how a form would work that you enhance progressively.

The same applies to simply outdated ideas like onevent handlers. It is easy to show an example that uses a few onclick handlers, but explaining event handling really well takes a bit of time. Again, this is something that really does not fit in the scope of a DOM course.

I do however think that it is important to get it in there, as there is no such thing as knowing one technology in the web development stack and being able to use it. There’s a lot of overlap with other areas and in order to be a good developer and play well with others you need to be aware of your effects and areas of overlap with your colleagues’ skill-sets.

The other extreme I find myself doing is being too over-cautious. I went through the tough times of the first browser wars and got a deep-rooted mistrust towards anything some browser tells me is OK to do and use. However, I get the feeling that it doesn’t really matter any more if Internet Explorer has a problem with name vs. ID or whatever other shenanigans we have to be aware of when we build things from scratch.

I do get the distinct feeling that not building on top of a good client-side library is simply a waste of time these days. Libraries allow us to write code, not to work around bugs and wonder what other safety measure we have to put in.

That’s why I started asking people in my courses to use Firefox with Firebug and use a good text editor to code along. Today I managed to breeze through how to write HTML that is ready for internationalisation and works with assistive technology, over simple DOM access to the document and at the end writing a validation script for a form using generated DOM content. By concentrating on how things are meant to work instead of debugging random issues I managed to get the students to reach far into the matter in a day – even those who never touched JavaScript before.

Maybe it is time to get beginners accustomed to a market that builds on working solutions and benefits from browser abstraction via libraries than teaching developing from total scratch – bad browsers and bad people taking advantage of any technology to gain access or spam us seem to have made this way of working redundant.

Ever since I got the fancy title of “Developer Evangelist”, people look at me cross-eyed and wonder what that is. The reactions reach from “oh so you don’t code any more” to “that’s marketing isn’t it?”. Both are wrong.

I see the job of an evangelist to validate your company and its products in the outside world. This means that you need to keep an eye on what your company is doing, give feedback and stop bad documentation and too complex systems from going live. In order to achieve this you get to know systems before they go out, play with them and write or help write their documentation. You also go out into the world, speak at conferences and go into companies for “brown bags” and find out how people use your employer’s products. The feedback you get from that helps you validate or defeat internal assumptions about “what every developer needs” and “how people use things”.

I am in Bangalore, India at the moment and was asked to train evangelists for the local market. A bit of a weird concept as you find evangelists internally – you do not train them to become one.

In a two hour session I was asked to outline what it means to be an evangelist and what to do and not to do. Here’s the outcome on slideshare:

[slideshare id=674444&doc=developerevangelism-1224563721992430-9&w=425]

On the third day we went deeper into the oddities of the DOM and how to access and create content in the current document. One thing I realized very fast is that teaching DOM before the days of FireBug was much easier – you can lead the group from property to property and method to method. With FireBug they are much faster in finding out what can be done and also get a lot of goodies that FireFox provides but aren’t the standard.

We went through the basics – setAttribute and the differences when using it in comparison to the shorter property notation (MSIE sees expando properties as attributes and in order to remove them you’d have to null both the attribute and the object property).

We then moved on quickly to createElement and createTextNode and detected the need to apply them to the document somehow to make them appear.
This lead to insertBefore and appendChild and we discovered that there is no insertAfter, which is a logical fault in the DOM.
As a remedy I asked the group to write their own insertAfter, which is a good exercise to re-iterate looping through child nodes as well as using the creation methods. There are of course several methods of writing an insertAfter, but I was pretty much stunned to see one of the attendees to come up with one I hadn’t thought of:

function insertAfter(newElm,elm){

var clone = elm.cloneNode(true);

elm.parentNode.insertBefore(clone,elm);

elm.parentNode.replaceChild(newElm,elm);

}

	

I am not too sure about its performance, but I really like the logic of it: this way you can be sure the new node will be after the old one regardless of where the old node is (last node, first or somewhere in the middle). This also means you don’t need to fork and use insertBefore or appendChild respectively.

Other examples we went through were removing nodes with a certain class (to show the problem of the changing length when iterating over a nodeList and removing elements) and writing a simple form validation script that changes the labels of mandatory fields when they are empty.

I wrapped up the day using the JSON output of the del.icio.us API to write out a list of bookmarks and tags:

In an extra step I then asked the team that instead of calling the API in an own script tag to progressively enhance a link and create the script tag dynamically:

My Delicious Links

We then ranted a bit about the non-logic of DOM methods and their parameter order (“why is document.insertBefore(oldNode,newNode) not possible but instead we need oldNode.parentNode.insertBefore(newNode,oldNode)??”) and came up with a wishlist of DOM methods that should be native:

• createLink(url,text)
• insertAfter(newNode,oldNode) – consistent with the native DOM inconsistency
• removeNode(node)
• textElement(elementName,text)
• addScript(url)
• normalizeNode(node) – removing whitespace
• getText(node)
• setText(node,text)

This list is also the courses homework, and we’ll take a look at the results on Monday.

On the second day of the current Juku program we covered the “read” sections of DOM scripting: attributes, node properties and how to navigate around the document with a certain node as the starting point (nextSibling,previousSibling,parentNode,childNodes…).

• We also talked in detail about nodeTypes and how to recognize what is an element and what is a text node, which of course brought up the concept of whitespace in HTML as annoying “node-noise”.
• We covered the difference between element.attribute and element.getAttribute(attribute), especially when it comes to reading out the href attribute of links.
• We did a script planning session on a whiteboard analyzing the HTML of a document to find out the shortest way to reach a certain element discussing various approaches.
• We covered manipulation of the style property, its dangers (mixing presentation and structure, hurting maintainability) and its good uses (creating same-height columns using offsetHeight).
• We covered avoiding the style property by dynamically adding CSS classes and the problems with this (testing for existing classes)
• We covered cutting down your DOM scripting to the lowest form, avoiding large looping and conditional testing by using getElementsByTagName instead of traversing the node tree.
• We covered changing of text node content by manipulating the nodeValue property

Today we’ll start creating new content using the DOM.

I am currently in Sunnyvale, California to teach a bunch of bright young people the ways of the DOM and YUI. I am one of the trainers in the Juku project of Yahoo! (alongside Ross Harmes and Douglas Crockford) and give a 12 day intensive course. Naturally, this keeps me busy and I don’t get to blog as much – or so I thought. Actually I don’t see much harm in doing a day-by-day report on what we covered here, as a reminder for myself and maybe an inspiration for your own training courses.

Day one is traditionally for me the day to test the waters and see how my style of training suits the group. I hate sitting in lecture-style training with a massive binder and interspersed with coding exercises that are more hello world than anything useful. Instead I do more of a hands-on style where I try to get the attendees to form and run most of the course with me aiding by steering and helping out. There is an overall master plan for the course (you have to cover x amount of content in y amount of time, after all) but the individual days might differ a lot according to the subject matter. I normally tend not to use the computer as much as possible (as it leads people to surf around and get distracted with work mail) but in this case this’d be tough to do.

I got to know the attendees and asked them who they are, what they do, why they are here and what they want to get out of the course. I was very happy to hear that whilst the subject knowledge level of the group differs greatly from member to member, they all wanted to “learn how to apply things in the real world” and “get in-depth knowledge of how browsers deal with the DOM and DOM scripting”.

I started by explaining that DOM scripting is more than just manipulating the DOM but that we coined the term (in the now defunct WaSP working group) as a quality mark of DHTML development. I re-iterated the need for separation of development layers and the ideas behind progressive enhancement.

• We set up a valid HTML document, explaining what is needed for any document to become one – doctype, a title, encoding, language, reading direction and all the necessary elements.
• We talked about where to put styles and scripts and the impact of their location on performance
• We then went to learn about the DOM, setting up and using Firebug to play with it and took a look at getElementById() and getElementsByTagName().
• We talked about optimizing for loops and iterating over resulting HTMLCollections with as few code as possible whilst not sacrificing maintainability or performance.
• We went into reading HTML attributes and discovered the pains of reserved words like class and for
• Last but not least we created our own getElementsByClassName function.

The last aspect was especially interesting, as I deliberately kept the specifications of the function loose and asked the group to plan it on a whiteboard before plunging into it. The discussion around the planning showed that there are millions of ways to approach this problem and that if you mix developers that come from a UI-centric background with hard-core C++ developers you get interesting approaches to the same problem

You can see the results of the different teams in this document. The different examples are commented out with the quick commenting trick so to try them out, just add another slash in front of the /* preceeding the functions.

Day two is about to start…