Comments on: LABjs gets “Even Faster” with version 1.0 http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0 Cleaning up the web with Ajax Thu, 09 Feb 2012 06:55:33 +0000 hourly 1 http://wordpress.org/?v=3.2 By: getify http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0/comment-page-1#comment-276906 getify Tue, 01 Dec 2009 07:59:44 +0000 http://ajaxian.com/?p=8053#comment-276906 I have bagged on <a href="http://blog.getify.com/2009/11/why-dom-ready-still-sucks/" rel="nofollow">how dynamic script loading makes DOM-ready detection harder</a> (more "suck"), but here's a different perspective on <a href="http://blog.getify.com/2009/12/how-labjs-speeds-up-dom-ready/" rel="nofollow">how LABjs improves DOM-ready</a>. The blessing from the curse, if you will. Just something to keep in mind when thinking about using LABjs. I have bagged on how dynamic script loading makes DOM-ready detection harder (more “suck”), but here’s a different perspective on how LABjs improves DOM-ready. The blessing from the curse, if you will. Just something to keep in mind when thinking about using LABjs.

]]> By: Punsons http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0/comment-page-1#comment-276904 Punsons Tue, 01 Dec 2009 03:11:27 +0000 http://ajaxian.com/?p=8053#comment-276904 the callback will be fired by jQuery's document.ready() function (unless the page finishes before jQuery initialises, in which case it fires when all scripts are loaded From: http://www.getbestflowers.com the callback will be fired by jQuery’s document.ready() function (unless the page finishes before jQuery initialises, in which case it fires when all scripts are loaded

From: http://www.getbestflowers.com

]]> By: csuwldcat http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0/comment-page-1#comment-276901 csuwldcat Mon, 30 Nov 2009 21:02:33 +0000 http://ajaxian.com/?p=8053#comment-276901 Here is a similar implementation of an asynchronous sequenced loading script for Mootools. Use it standalone, on functions, and on your Mootools classes: http://blog.citycrawler.com/?p=47 Here is a similar implementation of an asynchronous sequenced loading script for Mootools. Use it standalone, on functions, and on your Mootools classes: http://blog.citycrawler.com/?p=47

]]> By: getify http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0/comment-page-1#comment-276900 getify Mon, 30 Nov 2009 18:48:23 +0000 http://ajaxian.com/?p=8053#comment-276900 @jcoglan -- i completely agree, for complex apps, LABjs represents only the nuts & bolts of a complete solution. I wanted to provide the basic components of a loader that was capable of handling execution-order with parallel downloading, and then what I hope is that people will take LABjs and integrate (or wrap) it with more complex and complete dependency management solutions. . For instance, in a comment thread on the <a href="http://blog.getify.com/2009/11/labjs-new-hotness-for-script-loading/#comments" rel="nofollow">LABjs launch blog post</a>, I suggested some code to how a simple "fallback" mechanism could be wrapped around LABjs to allow you to attempt a load of a file from multiple locations, falling back to subsequent ones if the previous failed (like a CDN and a local fallback, for instance). . I believe and hope that LABjs functionality and API is expressive and powerful enough to suit a variety of needs in dependency management, and hopefully people will start innovating in that respect. . But, for the general website that simply loads 3 or 4 script files (some local, some remote), and then executes some simple initialization logic for the code that was loaded, I believe the API of LABjs will be quite easy to switch from the "<script> tag soup" seen on most sites to a simple and flexible set of calls to LABjs to load the files dynamically. . My main goal is to almost completely make the <script> tag irrelevant and outdated -- call it "<script> tags 2.0" if you will. :) @jcoglan — i completely agree, for complex apps, LABjs represents only the nuts & bolts of a complete solution. I wanted to provide the basic components of a loader that was capable of handling execution-order with parallel downloading, and then what I hope is that people will take LABjs and integrate (or wrap) it with more complex and complete dependency management solutions.
.
For instance, in a comment thread on the LABjs launch blog post, I suggested some code to how a simple “fallback” mechanism could be wrapped around LABjs to allow you to attempt a load of a file from multiple locations, falling back to subsequent ones if the previous failed (like a CDN and a local fallback, for instance).
.
I believe and hope that LABjs functionality and API is expressive and powerful enough to suit a variety of needs in dependency management, and hopefully people will start innovating in that respect.
.
But, for the general website that simply loads 3 or 4 script files (some local, some remote), and then executes some simple initialization logic for the code that was loaded, I believe the API of LABjs will be quite easy to switch from the “<script> tag soup” seen on most sites to a simple and flexible set of calls to LABjs to load the files dynamically.
.
My main goal is to almost completely make the <script> tag irrelevant and outdated — call it “<script> tags 2.0″ if you will. :)

]]> By: jcoglan http://ajaxian.com/archives/labjs-gets-even-faster-with-version-1-0/comment-page-1#comment-276899 jcoglan Mon, 30 Nov 2009 16:50:36 +0000 http://ajaxian.com/?p=8053#comment-276899 It's great to see folks hacking on a general-purpose solution to this, I for one am tired of every framework coming with its own package loader system. Still, I think this is working at too low a level in that you still need to remember each script's dependencies and the library cannot tell if a script has already been loaded as it has no metadata about what the script contains. I developed the JS.Class package loader[1] and Helium[2] to hide all these details and let the developer load objects by name rather than by URL -- the package loader knows your dependencies so it can figure out cases where downloads can be parallelized, and whether a script has already been loaded. I think Closure also uses this object detection approach to figure out whether to load scripts, and I find it much more powerful than loading libraries by their URL. [1] http://jsclass.jcoglan.com/packages.html [2] http://he.jcoglan.com It’s great to see folks hacking on a general-purpose solution to this, I for one am tired of every framework coming with its own package loader system. Still, I think this is working at too low a level in that you still need to remember each script’s dependencies and the library cannot tell if a script has already been loaded as it has no metadata about what the script contains.

I developed the JS.Class package loader[1] and Helium[2] to hide all these details and let the developer load objects by name rather than by URL — the package loader knows your dependencies so it can figure out cases where downloads can be parallelized, and whether a script has already been loaded.

I think Closure also uses this object detection approach to figure out whether to load scripts, and I find it much more powerful than loading libraries by their URL.

[1] http://jsclass.jcoglan.com/packages.html
[2] http://he.jcoglan.com

]]>