I’ve just been over the @mediaAjax drinks, worked through around 670 emails that accumulated in my inbox since last Wednesday and now there is some time to talk about my experience there.

First of all, here are the slides of my talk:

| View | Upload your own

I didn’t cover many technical issues but instead tried to convince some people to recognize that the way you use JavaScript in your team is the most important part of development. It is not important that you write amazing code, but instead it is much more important to work smoothly together to ensure that you can deliver fast and on budget. This is the only thing that keeps us from being able to train and grow developers – we are too busy playing catch-up with estimates and deliveries. Instead we should concentrate on bringing the fun back into developing by working together rather than competing or being the “JavaScript hero” for the rest of the team.

I got some good feedback and I am happy to get more, so if you’ve been there, tell me about it. Even more importantly, if you are considering on taking on some of the ideas, I’d be interested in hearing how that went in your environment.

Generally I have to say that I enjoyed the conference a lot. I was at first disappointed by the lack of wireless but I guess that in the end it made people listen more intently to what the speakers had to say.

My faves:

• Dion and Ben of Ajaxian covered the State of Ajax, and compared the current happenings to a wishlist they’d drafted 2 years ago. It was a fun enough keynote, but I am not too sure about some of the CSS bashing that was going on. It is very interesting to see that while CSS people want to do everything with their technology, a lot of hardcore coders just don’t grok CSS. Hey, the future is hybrids, play technologies to their strengths and allow people who care to do them.
• Derek Featherstone’s “Real World Accessibility for Ajax-enhanced Web Apps” talked about the problems we have in creating rich client application modules like tree menus and how we fail doing them in an accessible manner. It was very entertaining and he had some good real-world photos to drive his points home. My personal favourite was the irony that the stage had a wheelchair ramp that lead nowhere because of the backdrop
• Stuart Langridges “How to destroy the web” was as unique as he is as it was an anti-presentation as to what to do. He ran the devil’s advocate idea of us building web products in the most obtrusive and bloated manner possible as otherwise people would use all the bandwidth for looking at horse porn (his words, not mine). He had a lot of very good points (don’t do this, as it leaves too much bandwidth) and it reminded me of the Vincent Flander’s approach to teaching web development
• John Resig’s introduction to Prototyping with jQuery showed how you can easily take a saved copy of a web site (in this case an Apple page) and enhance it with jQuery after analyzing the HTML structure. This is pretty cool for just showing a product person how a change could feel like and I’ve done it in the past with Greasemonkey scripts.
• Alex Russell of Dojo gave us some food for thought about how libraries should become one voice and talk about the same ideas and overlap in terms of implementation to ensure we all help developers the same way instead of competing. Something I can wholeheartedly agree with.
• Brendan Eich showed the ideas of a “new JavaScript” while Douglas Crockford explained why the “now” JavaScript is actually a cool language as it is.
• Dann Webb showed ways how you can use JavaScript’s trickier parts like prototype and clever uses of the arguments array to enhance the language and do meta programming with it.

All in all I was happy to be part of this and I thought it one of the best conferences if you wanted to learn about JS. I did hear people complain that there wasn’t that much about Ajax, though. To me, Ajax is a methodology, not necessarily a fixed set of technologies, and to cover the whole aspect you’d need to explain both the client and the server architecture. True, this could have been done more, and I also lacked the coverage of Flash Developers as programmers that already use a lot of things that JavaScript2 is promising us.

All in all there were several great finds for me:

• Never sit next to Bruce Lawson, Chris Willison and Stuart Langridge. It is evil but also terribly funny.
• It is great to see that people involved in the development of competing libraries all want the same stuff and really don’t mind the success of the other competitors. Take this down, fanboys and mailing list flamers: we all want to help you and think you should use whatever suits you best, which is not necessarily our stuff.
• The best way to recognize in your server side component if a call came from Ajax and not from a normal page submit is to check the HTTP header. Most libraries send a bespoke identifier!
• Make sure you check if a queen has a jubilee before you go out of the train in the Westminster area.

I hope the people who went also had fun and the others will consider coming to the next conference in the London area. It is great fun and value for money.

I’ve written a lot about unobtrusive JavaScript before, but I never really held a workshop about it. Well, now as part of the Paris Web Conference later this week in Paris, France I am giving one which is already sold out and I am very much looking forward to it.

As part of the workshop I prepared my materials and wanted to have a nice outline to follow. I took this as an opportunity to build up on the older materials and the outcome of this exercise is that I managed to define the rules of unobtrusive JavaScript, which are:

• Do not make any assumptions
• Find your hooks and relationships
• Leave traversing to the experts
• Understand browsers and users
• Understand Events
• Play well with others
• Work for the next developer

I’ve explained them all in some detail here: The seven rules of unobtrusive JavaScript

After the workshop I will also add the code demos with some more detail, but that’ll be most probably after @media Ajax.

I hope this is helpful to you, it is creative commons, so use it for good.

One of the differences I keep seeing in functions and methods lately is that people seem to go away from the strict pattern of expecting parameters in a certain form. If you look back some years you might remember functions like the following:

function doLayerFloat(id,start,end,direction,speed,fade,whatelse,Iforgot){

...

}

	

This, at least to me is rather annoying as I am terrible at remembering the order the parameters need to be sent in (conditioning in PHP confusion probably). The other issue I kept seeing with this was that if you didn’t want to provide some of the parameters but one of the last ones you had to send empty strings or even null values:

doLayerFloat(‘myDIV’,0,30,null,null,true,null,null){

...

}

	
// or

doLayerFloat(‘myDIV’,0,30,’‘,’‘,’‘,’‘,’‘){

...

}
	

This is both confusing and convoluted. Other scripts I have seen work around the issue by using the arguments array, which at least allows a flexible amount of arguments to be sent.

function doLayerFloat(id){

var args = arguments;

for(var i = 1; i < args.length; i++) {

...

}

	
}

However, my favourite these days is functions that actually take a few defined parameters (or a single one), allow for it to be several things and allow you to send an object as the properties:

function doLayerFloat(id, props){

var elm = typeof id !== ‘string’ ? id : document.getElementById(id);

for (var i in props){

...

}

	
}

This allows the id to be either an element reference or a string and takes an object as the second parameter in which I can define the order and amount any which way I like (provided the method then tests for each of them and their correct values):

doLayerFloat(‘x’,{start:20,end:30,fade:true});

// or

doLayerFloat(myElm,{fade:true,direction:’right’});

This also allows you to define default values should the properties not be set, something you can do in PHP but not in JavaScript. In PHP, this works:

function foo($bar=2,$baz=’foo’){

}

	

In JavaScript that can’t be done, but if you use an object you can predefine if the properties are not set:

function doLayerFloat(id, props){

var elm = typeof id !== ‘string’ ? id : document.getElementById(id);

props = props || {};

props.start = props.start || 100;

props.fade = props.fade || false;

}

	

Do you agree? Or is the object literal syntax still too tricky?

° main contain hyperbole to take the mickey out of other blog posts

I am a very lazy person when it comes to typing. As I am doing so much of it I’d rather not type something I really don’t need. This is why I had an issue with “for” loops as you need to type them so often.

The classic way of looping through an array for example is a for loop with an iterator:

var arr = [1,2,3,4,5];
for( var i=0; i<arr.length; i++ ){
  alert( arr[i] );
}

This is however not a good plan for large arrays (like DOM trees) as the length attribute is read out every time the loop executes. You can avoid this in two ways. If it is for example irrelevant in which order you loop through the array you can use a reverse loop:

var arr = [1,2,3,4,5];
for( var i=arr.length - 1; i>-1; i-- ) {
  alert( arr[i] );
}

Or using while:

var arr = [1,2,3,4,5];
var i = arr.length;
while( i-- ) {
  alert( arr[i] );
}

If you really need to go through the array in the normal order then you need to use another variable to store the length and compare with that one.

var arr = [1,2,3,4,5];
for( var i=0,j=arr.length; i<j ; i++ ){
  alert( arr[i] );
}

The for loop also allows you to use the in keyword to make it easier:

for(i in arr ){
  alert(arr[i]);
}

However, there is also another trick if you don’t want to do this (for example if you don’t want to iterate through all but use a step of 2). The comparison inside the loop does not need to be the iterator but could be any comparison. As long as it is true, the loop gets executed, when it becomes false the loop ends. This allows you to simply check for the array element inside the loop itself which means you don’t need to read the length attribute at all:

var arr = [1,2,3,4,5];
for(var i=0; arr[i]; i++ ){
  alert( arr[i] );
}

There is however the issue of the truthy and falsy and type casting in JavaScript which means that if your array has null or 0 elements the loop would end, too:

var arr = [1,2,0,4,5];
for(var i=0; arr[i]; i++ ){
  alert( arr[i] );
}

You can avoid this by testing properly:

var arr = [1,2,0,4,5];
for(var i=0; arr[i]!==undefined; i++ ){
  alert( arr[i] );
}

There is also another problem this kind of loop avoids: if you manipulate the array during execution of the loop (for example by removing or moving DOM nodes) you need to change the iterator, too. This example will be an endless loop and lock your browser:

var u = document.getElementsByTagName('ul')[0];
var lis = u.getElementsByTagName('li');
for( var i=0; i<lis.length; i++ ){
  u.removeChild(lis[i]);
}

With the other kind of loop that is not a problem. You can for example remove all list items from a UL with:

var u = document.getElementsByTagName('ul')[0];
var lis = u.getElementsByTagName('li');
for( var i=0; lis[0]; i++ ){
  u.removeChild( lis[0] );
}

Did I miss something obviously bad about this idea? If so, please tell me, but also consider the other benefits of this for loop to end all for loops:

• a lot smaller than the YUI, Dojo or Prototype
• unobtrusive and accessible (if the array is not there nothing happens)
• may have rounded corners (but they are invisible)
• cross-browser
• easy to read
• heals sick animals when you don’t look

If you wonder about the speed implications of the different styles, check out the speed comparison of for loops test page.

If you ever wondered how flexible web applications with hundreds of objects that need event handling are built, the trick behind it is called “Event Delegation”.

I didn’t come up with it, and it is nothing new either, but as some people seem to get confused when the term crops up, I’ve written a quick example why event delegation helps keeping web apps light and fast.