> 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.
Maybe slow down the stream for the Javascript-library response. Are they returned by the asset-service? maybe the response can be slowed down to a couple of seconds per library. Add a simple piece of javascript that shows an alert-box. First put everything in the head. You should see the alert-box before anything renders. Then put eveything at the bottom of the page. If I'm not mistaken, you should see part of the page before the alert-box is shown. it is not an accurate measurement, but you can see clearly how different browsers handle things. regards, Onno > > > 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 > >
