At the past Dynamic Languages 08 conference, Neil Ford of ThoughtWorks Inc. gave a keynote presentation entitled "Ceremony & Essence", which took the case of programming languages to reflect on two fundamental approaches to any given problem: The "ceremonious" approach that builds libraries over libraries, creates patterns and protocols to eventually solve the initial problem with a huge flagship of infrastructure; and the other that creates infrastructure that remains light and compact and tries to get out of the way, allowing you to focus on the issue at hand.

Excessive ceremony is a dangerous trap, and not only for software itself but also for all the collateral efforts like documentation, configuration and release management. Here is a story of a personal encounter I had recently.

When I came across a broken link on the Python documentation web site, I would have ignored it since I knew how to get at the information anyway. But since Python is besides Javascript the other intrinsic language for qooxdoo, I thought "be a good citizen, save the world and report this broken link". After some looking around I was directed to a feedback page that offered a couple of choices. One of them was that if I had spotted a concrete problem with the web site I should be so kind and open a bug for it in Python's issue tracking system.

Now filing bugs is not the most pleasurable activity, especially if you need an account in the first place. But eventually I had filed my first Python documentation bug in two lines of text, which was really a no-brainer saying this is the page, this is the broken link on it, and here is it where it should actually point to. I felt like a good boy.

You might be surprise to hear about the feedback I got a few days later. The link had been fixed in the development system. Hmm. The (offline) development system was fixed but the (online) production system not?! I asked back and learned that the documentation was treated like released software. The current presence has been released (2 years ago) and will not be fixed but superseded by its successor which is expected to come out in a couple of months. So you accept your users running into a dead end for more than 2 years?! And the policies and procedures do not allow this trivial issue to be fixed?! - Thank you, ceremony!

Ok, so this is a rather personal rant about my frustration with current Firefox. Firefox is my bread-and-butter tool every day. I don't know how you feel, but my impression is that Firefox falls behind in a central issue for browsers, speed and responsiveness. As a real-time, GUI-based, highly user-interactive, networked tool, a browser has to be top notch in handling concurrency. This is not exceptionally good in Firefox 2, and I can only hope it will improve significantly in the upcoming Firefox 3, with a new rendering engine and - more importantly - a threadmanager (see here). It seems the new theme gets all the attention but I don't care about themes when the reponsiveness is poor. Maybe Webkit is the new hot shot, and I would be interested if they'd released it on Linux.

The issue is, I have easily three browser windows open at any one time, with a total of 20 to 30 open tabs in them. I switch between windows and tabs, starting page loads in one and continue reading in another. And I regularly are blocked by the browser itself. I accept network latency, but why is one window not repainted while the other is loading? Why can't I switch tabs when a script starts in the other? Or why can't I open my preferences window while the browser is loading? Why is Firefox always getting in my way?

My concerns with current Firefox are:

• Page loading. It's not understandable the browser is not able to load pages in the background. Or more practical, why can't I switch to another tab reading what's already there while the browser is loading and rendering a new page in the tab I'm about to leave?!

• Multi-threaded Javascript host engine. I don't see why you couldn't have a multi-threaded Spidermonkey whith a thread for every web page that uses Javascript. This way you could isolate the pages against each other, while handling concurrency so that every page has optimal responsiveness.

• Power to the chrome, which means power to the user. In a multi-tasking browser, the UI has to have top priority. User interaction is always more important than everything else. If I open a menu or invoke a dialog or operate some other control of the chrome, the browser has to respond immediately no matter what it is doing at that time. Loading, rendering, cache management, execution of scripts - you name it, they have to wait.

So, it boils down for me to this: I want a multi-tasking browser with decent (pre-emptive) task scheduling and priorities. Just like a decent operating system. But task management is not only for OS's, the technology is since long available for every application to implement.

I have made some photos of our visitation of San Francisco during the AJAX Experience.

Our booth attracted many visitors:

qooxdoo talk by Andreas & Derrell:

qooxdoo user meeting with Jim, myself, Bill, Andreas, Mike and Derrell:

We had also a lot of fun in San Francisco:

The guys at ajaxian.com have reported about a current survey regarding the popularity of common AJAX frameworks. It is quite clear why prototype is the winner. It's well-known, small and easily embedable into existing pages. However I think it is interesting that Mochikit is less widely used, because the targets of these libraries are comparable in my opinion. And Mochikit does not depends on extensions of native objects (especially Object.prototype) which makes it the better choice.

I should mention that in my opinion the whole survey is quite problematic because of their comparison of different levels of so named "AJAX frameworks". For a next survey I would suggest to divide the list into these groups:

AJAX wrappers & DOM utilities:

• Prototype & Scriptaclous & Rico
• Moo.fx
• jQuery
• Yahoo UI
• Mochikit
• XAJAX
• DWR (includes backend code, too)

Framework & Toolkits:

• Dojo
• Atlas
• GWT
• qooxdoo (seems to be missing ;)) 

I've grouped together Scriptaclous and Rico because they both depend on Prototype which means they are more or less an extension of this library and not a real separate solution.

What do you think? 

There is some progress at Microsoft's development of Internet Explorer. Reading the recently published IE chat transcript contains some interesting points:

• We support embedding/hosting WPF applications within IE but we don't natively support XAML
• We are making improvements to a lot of performance issues across IE, including memory leaks. Stay tuned for updates of the browser.
• In IE7 we do not support XHTML [content-type application/xhtml+xml]. We will treat it like HTML content.
• We will consider it [DOM method .addEventListener()] for a release after IE7.
• We have no plans in IE7 to support allowing customization of the RSS reader. This is good feedback for us to consider for future releases, thanks.
• Requesting foo.innerHTML on elements returns incorrect data [even in IE7, will be maybe fixed with further releases of IE] (mostly a formatting nightmare) (tags are not in the case specified, or specifically lowercase many of the attributes are not quoted properly, and self-closing tags are not self closed.)

So far so good. Microsoft, we are waiting for IE8. Especially regarding JavaScript support.