The nice thing about the build pragma setup for RunJS, you can upgrade run without having to change your code if you find you want more features, like plugin support, or i18n/text dependency support via plugins. I view run.ready/DOMContentLoaded support more of a necessity for a loader, so unless you already had an implementation for that, I suggest the version that has run.ready() support, which comes in (with license) at 5,867 minifed, 2,522 gzipped. I believe that is the lower limit a functional loader that does nested dependencies via run() module calls. That size could probably be brought down a tiny bit (probably reaching the 2,000 gzip size) if I were to really be aggressive and remove all context references, but that would be a mess to maintain and there would be no easy upgrade path to multiversion support. I need to work on the size of that license block! The one you should use, the one with the license, is 5,245 minified and 2,317 bytes gzipped. That bare bones loader comes in at 5,086 minified and 2,204 gzipped. js files that do not define run.js modules (scripts that do not call run(), for example jQuery, or plugins for jQuery). This version of run has just the following features: The interesting number for me is the version of run.js without plugin support, no run.modify, no multiversion support and no page load (run.ready/DOMContentLoaded callbacks). Including both the i18n and text plugins with run.js bumps it up to 11,759 minified, 4,655 gzipped. The normal config, with no plugins included (but with plugin support) is 7,970 bytes minified, 3,167 gzipped. Google's Closure Compiler did the minification for this evaluation. Let's look at the non-license sizes, since they give a better indication of code density. Here is the breakdown (warning, Google Doc iframe inclusion, but interesting numbers inlined in this post after the iframe): I am trying to get a handle on where the bulk of implementation lies, and what features add to its file size. The build pragma support was used to build RunJS in a couple of different configurations. The build system that comes with RunJS now supports build pragmas.See the Circular Dependencies section in the README. The cost was an extra call, run.get() that needs to be used in circular dependency cases. Now, that special call out is removed and any return type is allowed. Before only objects and functions were allowed and functions had to be called out in a special way. Any function return type is allowed from the module definition function.The RunJS build system will then *inline* those text files with the module, so that the XHR calls be removed in deployed code, and allow cross-domain use of those text files. The plugin will use async XMLHttpRequest (XHR) to fetch those files and will pass the text of those files as an argument to a module's module definition function. i18n bundles have been pulled out as a plugin, and a new text plugin allows you to set text files (think HTML/XML/SVG files) as dependencies for a module. A few updates on RunJS, a JavaScript file/module loader (see the README for more documentation):
0 Comments
Leave a Reply. |