I do like the fact that Javascript will move back into the head with this solution. It's pretty much 'the way of internet'. Everyone knows how to use it and almost all Javascript examples show it that way. Moving the Javascript-includes to the bottom made some things more difficult; you cannot quickly mockup a page using inline onclick-attributes for example, since the libraries you depend on may not have been loaded yet.
I think it was an optimization step that was forced onto the user and impacted the way (s)he worked. I had to put in quite some effort to get pages working in Tapestry again that were sent to me by web-designers. That is, until it was possible to make the location of the Javascript configurable again. I'm not very happy with any popups or loading-messages being forced upon me though. There are still plenty of non-AJAX applications that work great without the entire page needing to be loaded, especially if you setup your pages to work without Javascript. Also, when the javascript-includes are inside the head, so can be the Javascript initialization code. This means you can execute the initialization code directly after the _DOM_ was loaded. When the scripts are at the bottom you have to wait until the _page_ (including all resources) is loaded because you depend on the javascript libraries being available. When using the dom-loaded event instead of the page-loaded event, it becomes much harder for a user to out-race Tapestry. On a slow connection, the hold-up is usually in resources, since only a couple of connections are made at once by the browser. The DOM is usually loaded pretty quickly and the other resources have to fight for a connection. I must admit I currently use hardly any AJAX, mostly because it is very hard to do in Tapestry. This is one area where Wicket is way ahead of Tapestry 5: you get back the full state of the page when a component makes a callback from the client to the server and from the handler you simply return all components that require updating. Wickets handles the stuff for you on the client. If you open a modal dialog for example, you can tell it to send callback when the dialog is opened, or moved, or closed etc. That way you can program pretty much all of the behavior using Java on the server. In Tapestry things are much more complex with Zones and lots of custom Javascript. I think we can learn some things here from Wicket. regards, Onno
