tag:blogger.com,1999:blog-19002723.post1587846047295016805..comments2023-02-21T00:14:00.325-08:00Comments on Tagneto: RunJS: GitHub, build options, features, file sizesJameshttp://www.blogger.com/profile/12067100302830600925noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-19002723.post-69963107001808818362010-01-18T06:57:29.479-08:002010-01-18T06:57:29.479-08:00Correction: after much testing, it appears that th...Correction: after much testing, it appears that the XHR preloading *does* in fact usually cache the script. There were some red herrings that threw me onto the wrong path with the prior conclusion, and those have been disconfirmed.<br /><br />I've updated the documentation accordingly.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19002723.post-33623606305230499232010-01-01T11:29:45.523-08:002010-01-01T11:29:45.523-08:00The XHR preloading option was added because, for s...The XHR preloading option was added because, for same-domains scripts, it's a little more efficient time-wise than the "script/cache" trick. The reason is, it avoids the double-cache hit by simply loading the script once and keeping in memory.<br /><br />Also, there are times when people load dynamically generated scripts which don't have any cache/expiration headers (obviously), and if you were to use the cache trick with those, you'd actually load the whole script twice, which would be bad.<br /><br />Of course, XHR has the down side you mention, which is that caching doesn't happen. For some people, that's a concern, for some, not.<br /><br />So, depending on what types of scripts you are loading, and from where, you can chose whether the cache or xhr tricks are more appropriate. By default, it's configured to use both, xhr for local, cache trick for remote. I think this is the most common configuration that makes sense for general web dev situations. Thus, that's the default.<br /><br />Also, keep in mind, neither of these tricks are necessary in FF/Opera, because those two browsers will automatically preserve execution order of script tag elements added to the DOM, so LABjs just adds the scripts in order and relies on the browser to delay execution if a script arrives too early.<br /><br />------------<br /><br />As for combining scripts, I'm a fan of this, but only to a certain point. For instance, loading 10 scripts on a page is almost never optimal. You should combine.<br /><br />But, loading 1 script is also not optimal, in my opinion. The reason is because it completely eliminates the ability to parallel load bytes. So a single 100k file will load byte-by-byte serially. But even breaking that into 2 50k files will, in general, cut the loading time roughly in half, as each can load in parallel. And LABjs will make sure the two halves execute in order so no dependency issues.<br /><br />Also, if you have 2 (or 3) files that you load, and you make a change in 1 file, all your users don't have to reload all the unnecessary script code that didn't change in the other 2 files.<br /><br />It's a balance game between browser cacheing, build-time processes, parallel downloading, and http-request overhead reduction.<br /><br />Keep pushing to make things as optimal as possible! Good job so far!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19002723.post-38879250110417372492009-12-30T11:04:43.432-08:002009-12-30T11:04:43.432-08:00getify: Thanks for the clarification. Looking more...getify: Thanks for the clarification. Looking more at LABjs, it can load the script but not execute it by loading the script with the type="script/cache", then I suppose later writes out another script tag with type="text/javascript" when wanting to evaluate it.<br /><br />I can see that as useful for existing scripts that do not follow a module pattern. For RunJS, scripts that follow its module pattern can be loaded and evaluated before they are used, but since the evaluation is just for a module (more like a declaration, but code does run) the modules can be preloaded and evaluated, but only on an action execute the module's methods.<br /><br />I can see where just loading but not evaluating the script may be useful in some scenarios, but I find that normally being able to group scripts together into one script so there is only one HTTP or just a small set of network calls to be useful more often, particularly for larger web apps. RunJS (and by extension Dojo) has a module system with a build process that can aggregate dependent modules together.<br /><br />Neat, both of us have different optimization strategies we employ based on the kinds of scripts the developer wants to load.<br /><br />Why do you offer the XHR preloading as an option? The doc for LABjs says it does not really help with caching and limited to same domain. What scenarios do you see this being useful?<br /><br />Neat stuff, thanks for discussion!James Burkehttps://www.blogger.com/profile/00451746837849321739noreply@blogger.comtag:blogger.com,1999:blog-19002723.post-35969038404855305222009-12-30T06:39:30.095-08:002009-12-30T06:39:30.095-08:00Further clarification: the .wait() function is use...Further clarification: the .wait() function is used to delay *execution*, it has no bearing on loading. As I said, all scripts in a LABjs chain will, by default (unless you turn off those options), load in parallel. The .wait() calls are inserted into a chain to make sure that LABjs knows if there are execution order dependencies that need to be maintained.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19002723.post-80064425119968491992009-12-30T06:35:49.689-08:002009-12-30T06:35:49.689-08:00Thanks for the mention of LABjs and the comparison...Thanks for the mention of <a href="http://labjs.com" rel="nofollow">LABjs</a> and the comparison comments.<br /><br />Just FYI, a clarification on how LABjs works with loading multiple scripts compared to how your code snippet works:<br /><br />LABjs by default loads *all* scripts in parallel (at least as much as the browser allows). The way it deals with dependencies (what you mention as modules requiring other modules, etc) is to control execution order. So, if you have 3 scripts (A,B,C), and C requires A and B first, then all 3 will load in parallel, but A and B will execute before C.<br /><br />This "preloading" technique is an important differentiator compared to how most other script loaders handle dependencies. Most others will simply *load* in order, rather than load in parallel and *execute* in order. <br /><br />So, in the above example, A and B would load and execute first, before C loaded. This means that the overall time will be longer since C didn't load in parallel with A and B.<br /><br />I believe as I interpret your code and snippet, this is how you suggest your code would handle things as well... that you'd first load and execute "framework.js", then load "plugin" and "myplugin" and execute them.<br /><br />Whereas LABjs would load all 3 and then execute in order, so I believe LABjs would be faster in that scenario.Anonymousnoreply@blogger.com