Hi Markus, Thanks for taking the time to reply - good to get some feedback. I agree with most of your comments, and once would have felt the same as you did. The reality is that once I started using Ext which added a lot of weight to my JS and CSS, that I found the loading of iframes had a noticable lag. I tried most of the techniques mentioned in the article, including trying to force the browser caching. The injection technique has offered a noticable speed increase when actually using the app and it works across all browsers I have tried so far.
With regard to working with dynamically generated iframes - yes I have had issues in the past as well, but from memory it was related to the way I was referencing them. From example I think I was getting issues when trying to call functions in an iframe using the iframe ID - which Internet Explorer did not like for iframes added to the DOM after page load. I now reference by NAME instead and have had no problems. There have been other challenges, but none of them major and all of them solved so far. But that is a slightly different topic :) Thanks once again for the feedback. I am still in "testing" mode so will keep your comments in mind... Matthew Markus Peter wrote: > On 17.04.2007, at 19:21, mdelmarter wrote: > > > > > Hi all, > > > > I have been using Ext and jQuery for a few weeks now. One issue with > > this combination is the sheer volume of JavaScript and CSS that needs > > to be used. Because I am working with a large application I have been > > experiementing with different techniques to improve performance, > > minimizing the download of JS and CSS. To read about my experiences > > and a new technique I am using you can view explanations and examples > > on my blog: > > http://matthew.delmarters.com/weblog/injecting-javascript-and-css- > > into-iframes/ > > Hi > > Not meant as an offense, but you asked for feedback :-) > > I've read the blog entry but I'm entirely unsure about the real > benefit of it. My experiences so far with using scripts across > frames, especially dynamically written iframes, is really bad. It > will usually work for 95% of your users but I experienced bad timing > issues with 5% of the rest. It's really a pain to debug those, if you > care to have serve your page to those 5%. > > It might be that your solution does not have those problems - I have > not tested it (and actually, my computer is not as broken as those of > those 5% of our customers, so I could not even test it), but I'm > always wary of all kinds of iframe hacks and use them only if I > absolutely must. > > Also, the main benefit you're advertising seems to be decreased > download times, but a proper webserver setup (especially the use of > the Expires HTTP header) and combining all stylesheets and scripts at > the server side will already give you most of the speed boost anyway > - maybe an even higher speed boost if proxies are involed and your > main HTML page is not properly cacheable - and there's no caching > issue either with "versioned URLs" (e.g. putting a timestamp in the > script and CSS URLs) > > If I've not overlooked something, you basically eliminated the TCP > overhead for the two additional connections (if Keep-Alive is not > used on the server....) but I'm not sure the price is not too high > for that. > > It's a nice hack, but I'm unsure whether I would want to use such a > hack. > > -- > Markus Peter - [EMAIL PROTECTED] http://www.spin-ag.de/ > SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295 > Regensburg > Aufsichtsratsvors.: Dr. Christian Kirnberger > Vorstände: Fabian Rott, Paul Schmid
