bassistance.de

This was the first actual day of the AJAX experience, with welcome refreshments, keynotes, quite some interesting sessions, lunch and cocktail, and, dinner with about 14 people from the jQuery community.

I met Karl Swedberg and Jonathan Chaffer, authors of the Learning jQuery book. I met and talked quite a lot with Richard Worth and Paul Bakaus, both heavily involved in the jQuery UI project. Marc and I drafted some plans for a new site for accessing jQuery and plugins documentation and we hope to get Glen Lipka involved into that. I met Rey Bango and talked with him a bit during lunch.
While I’m often stumbling about pronounciation, its great to meet all these great people in person and talk to them, instead of only chatting via IM or mail. I’m looking forward to the jQueryCamp on saturday.

The first two keynotes weren’t really very interesting, though it still was interesting to see and hear those people, namely Ben Galbraith and Dion Almaer, founders of Ajaxian, and Kevin Survance, CTO of MapQuest. According to Kevin, everyone listening to his keynote should have used MapQuest at least once in his life, which made me feel like an outsider.

The first break-out session in the morning on my schedule was John Resig’s The Future of JavaScript. He started with an overview of the development of JavaScript and how that is related to ActionScript, which is also built on ECMAScript. The really interesting part was the crashcourse on new features in JavaScript 2. While John mainly ran through stuff he got out of an whitepaper the night before, there is one important goal to mention: JavaScript 2 is completely backwards compatible with JavaScript 1.5. So assuming that you have Firefox 4 or 5 and it implements JavaScript 2, it still is able to run your current JavaScript 1.5 code.
Among the new features, the most important could be classes and an optional type system. Classes bring the classical class-based object oriented programming to JavaScript, with all its advantages and downfalls, of course with some fancy stuff like an override-keyword that you need to add when overriding a method from a superclass.
Using static typing is great to make your library code more robust, maybe perform better (the interpreter has to do less duck typing) and could help writing better tools for writing JavaScript.

Next on my schedule was Beyond XHR: Taking Ajax Offline with Google Gears by Chris Schalk. Why the topic was interesting, the presentation was not. I’m not sure what was missing in the talk to make it more interesting, but Chris didn’t manage to convince me to take a closer look at Gears anytime soon. It may have helped if he’d show how to actually work with Gears, and not only code snippets embedded into his slides, even if the slides itself were loaded from a Gears application.

After lunch, Advanced Prototype by Stuart Halloway was up. While it was interesting to get to know at least one of the people behind Prototype, the talk itself was not really helpful. Stuart managed to not mention jQuery even a single time, even when talking about the new CSS selectors support, which were implemented “by someone else”. I’m not sure what the reason was for that and I didn’t really want to ask in the Amphitheater. Maybe I get the chance to ask him about that in the next days. And about his JavaScript 2 rant (“its designed by commite and I hope it dies”). And why most Prototype code that interacts with the DOM now looks mostly like jQuery code. *see comments
What he actually talked about were funny things you can do with JavaScript, like implementing AOP on the fly, or currying: Call a function with a number of arguments that then returns another function with less arguments, which wraps another call that uses the supplied arguments. I guess his explanation was a little better then this one here, but he didn’t really show a good example of where you’d use that. I have one:

alert( String.format("Please enter at least {0} characters", 5) ); // alerts "Please enter at least 5 characters"
var template = String.format("Please enter at least {0} characters");
alert( template(2) ); // alerts "Please enter at least 2 characters"
alert( template(12) ); // alerts "Please enter at least 12 characters"

In this example, the String.format method, as currently provided by my validation plugin, either replaces the placeholders directly with the given arguments, or returns a template method that you then call with the actual arguments. Here, the actual currying is hidden inside the String.format method. The implementation doesn’t even need a “curry” extension like the one Prototype 1.6 provides, because its pretty straight forward to implement that on the fly. For anyone interested:

String.format = function(source, params) {
	if ( arguments.length == 1 ) 
		return function() {
			var args = jQuery.makeArray(arguments);
			args.unshift(source);
			return String.format.apply( this, args );
		};
	if ( arguments.length > 2 && params.constructor != Array  ) {
		params = jQuery.makeArray(arguments).slice(1);
	}
	if ( params.constructor != Array ) {
		params = [ params ];
	}
	jQuery.each(params, function(i, n) {
		source = source.replace(new RegExp("\\{" + i + "\\}", "g"), n);
	});
	return source;
};

It relies on jQuery’s makeArray helper, as the validation plugin is dependant on jQuery anyway.

Actually next on my schedule was Strategies for Testing Ajax with Selenium, but luckily someone told me that it got moved to Friday. So I went to the Comet for Highly Scalable Applications session by Michael Carter. Michael is the developer of Orbited, and definitely knows his way around that stuff. His talk concentrated on getting the basic concepts about Comet. The slides he provided were great at that, but failed a bit to actually give an idea how to leverage Comet in reality. He showed a chatting demo application, but similar to the Gears talk, there were some missing pieces at least I would have needed for the “click” to occur. After a quick glance at the Orbited page it isn’t exactly simple to get it running on your own machine. Anyway, learning more about Comet definitely should have a high priority for every web developer, as that can be a viable option for necessary archtitecture changes when dealing with massively more users then your architecture so far can handle, say, 10.000 instead of 500.

In a similar direction, though on a lower level in terms of architecture, went Ryan Breen‘s talk about Ajax Performance Analysis: Emplyoing the Latest Tools to Get the Job Done.
Ryan started with an overview of available testing tools. Among those, IBM Page Detailer was the most interesting one. While that crashed on Ryan during his talks at least two times, it was the only one to display accurate network visualization, because it analyzes the network traffic. In contrast to that, Firebug shows only when the parser found something to request (a script, an image), and not when the actual request is made. That is an important difference because the browser opens only to connections to a single host, instead of one connection for each resource to request.
When coming to optimizing applications, his advice is to reduce the number of requests made as much as possible. His slides give a nice overview over the different techniques. What I’ve learned, for example when dealing with a lot of JavaScript code, you should:

• Concatenate all your files into a single one
• Minify it (removing comments and whitespace)
• GZIP it
• Add the resuling file’s checksum to the filename
• Cache that file forever

Once the content of the file changes, the checksum, and therefore the filename changes, and the browser will rerequest that file. That way you can avoid the overhead of requests just checking if the file is still valid.