I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there.
Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately swamped at the moment (OK, forever). But this is what I would suggest as the best way to do things. Chas. Xavi Ramirez wrote: > If I understand everything correctly, the proposal is to dynamically > create a js file for each page request to add event handlers? > > If this is true, then I'm against the proposal for the following two reasons: > > 1. Every page will load slower > > Since the js file is dynamically create on each request, the js file > will be un-cacheable. This means the browser be will forced to make > an addition HTTP request to the server to render each page. This adds > roughly 150ms to the page load time (50ms to 200ms for network lag, > 50ms for download, 10ms for js execution). > > 2. Each page will be more fragile > > Requiring the synthetic js file will add another point of failure. > Even now-a-days with the ubiquity of broadband, connects still get > lost and files still get corrupted. > > It's true that most modern web pages already depend a number of > external JS and CSS files, but typically these files are static and > easily cached. > > Just adding my 2 cents. > > -Xavi > > On Sun, Sep 13, 2009 at 5:41 PM, marius d. <marius.dan...@gmail.com> wrote: >> I think so too. Does anyone have an opinion against this? I'll >> probably have some time this week or next weekend to work on it. >> >> Br's, >> Marius >> >> On Sep 13, 2:59 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: >>> A synthetic file sounds good to me and would probably be preferable. >>> >>> Cheers, Tim >>> >>> On 13 Sep 2009, at 20:31, marius d. wrote: >>> >>>> That looks a little cleaner but we'll have to look more into it if >>>> we'd want to go on this path. Perhaps accumulate those function into >>>> synthetic js file .. we'll see > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
