Interesting; first I have to figure out how to accurately measure this stuff (any ideas?), then we'll see if it makes a difference where the page initialization logic actually goes.
BTW I just checked in the first pass at these changes; it needs a couple of tweaks but I'm pretty happy about how it's coming out. On Sat, Feb 28, 2009 at 10:30 AM, Onno Scheffers <o...@piraya.nl> wrote: > I must admit that I haven't played around and tested it myself. It's mostly > theory: > > Everything in the head is loaded and/or executed before the page continues > loading. Therefore any Javascript-block in the head is executed immediately. > In the case of prototype that means the event is bound immediately and > theoretically it can be called earlier since the libraries are already > loaded as well. > > When the Javascript is at the bottom, the different <script> tags are > handled in the order they appear (since they may depend on one another). So > reading of the page may stop while waiting for the resources to come in. > Large parts of the page may already be displayed then, allowing the user to > click on links and buttons. > > So even though the event that was being acted upon was dom:loaded, it pretty > much acted as a page-loaded event since the final resources to be loaded are > the javascript-includes at the bottom of the page. Initialization code > cannot be run without those resources being loaded and this happens while > the browser is already showing the content it has. > > > regards, > > Onno > > > On Sat, Feb 28, 2009 at 5:21 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > >> So you think there's a difference between having the handler for the >> document "dom:loaded" event at the bottom of the page vs. the top? >> >> >> On Sat, Feb 28, 2009 at 7:25 AM, Onno Scheffers <o...@piraya.nl> wrote: >> > 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 >> > >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
