I have a several thoughts. Actually i spent some time and reviewed LabJS codebase and found few conclusions.
LabJs is playing with ready event with XHR technique to load files ( see how many ways we can load js files without blocking .... http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/).
The ready event occurs after the HTML document has been loaded, while the onload event occurs later, when all content (e.g. images etc) also has been loaded.
The onload event is a standard event in the DOM, while the ready event is specific to browser(so
it required various browser checks).
The purpose of the ready event is that it should occur as early as possible after the document has loaded, so that code that adds functionality to the elements in
the page doesn't have to wait for all content to load.
As i said ready event is not standard event so it need different cross browser checks and it's not necessary that its always return correct result.
On time by time people tried to get ready event but it's not full proof.
---------------------------------------------------------------------
Let's check how much reliable is Ready event
---------------------------------------------------------------------
- http://blog.getify.com/why-dom-ready-still-sucks/ [by Author of LabJs Kyle Simpson]
- Mozilla later named it "DOMContentLoaded" as
- https://developer.mozilla.org/en/DOM/DOM_event_reference/DOMContentLoaded [it's mentioned here that it's not safe method]
- http://code.google.com/p/domready/
- http://code.google.com/p/domassistant/source/browse/trunk/modules/DOMAssistantLoad.js
- Jquery's previous versions are also failed in correct
implementation
LAB JS History
------------------------------
We have seen different script loaders but i think LABjs’s goal is a bit different from others.
It enable parallel downloading of JavaScript files while maintaining execution order.
To do so, LABjs needs to know which browsers allow parallel downloads by default and then provide
other solutions for the browsers that don’t.
All loaders are using various browser detection techniques to determine the correct action
to optimize script loading.
BUT Browser detection is still not full proof in JS.
http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/
Unfortunately LABJs was failed in past to maintain execution order. See below links.
https://twitter.com/getify/status/26109887817 [ by Kyle]
Blog post of Kyle ( http://blog.getify.com/ff4-script-loaders-and-order-preservation/comment-page-1/)
and See Guy's comment who wrote Firefox Gecko engine code.
(http://blog.getify.com/ff4-script-loaders-and-order-preservation/comment-page-1/#comment-748)
Finally Kyle have wiki website ( http://wiki.whatwg.org/wiki/Dynamic_Script_Execution_Order) where he maintain list of issues ( due to different behavior of browsers like Mozilla Gecko and Web-kit) so that browser vendors internalize these issues and come up with ways to solve them.
----------------------------
negative side effects
----------------------------
In below links Kyle mentioned that LABjs will not work properly :
- if page is used document.write
- if codebase is used ready event poorly
- Other negative effects which are mentioned, BTW nice
abbreviated by Kyle: "FUBC" (flash of un-behaviored content)
http://blog.getify.com/labjs-new-hotness-for-script-loading/#ux-labjs
-----------------------------
Why we need LoadJs ?
-----------------------------
First, all loader scripts are trying to enable parallel downloading of JavaScript resources. That’s a worthy goal but one that’s already being handled by newer browsers.
see below link where i load 19 HTML resources in normal manner but still JS files are loaded parallel.
http://172.16.3.228/public/test.html
Second, LABjs is very focused on maintaining script execution order.
With this comes an assumption that we want to download multiple JavaScript files that have
dependencies on one another. This is something that don’t recommend but I think that some people feel it’s important.
Third, other loaders are focused on separation of download and execution of JavaScript. It is the
idea that download a JavaScript file and not execute it until a point in time determined by
us(requirejs did same job in very decent manner). The assumption here is that page is progressively
enhanced such that JavaScript isn’t immediately needed. LABjs doesn’t address this problem. Browsers are also not helping with this.
So all these loaders require constant monitoring and updating as new browser versions come
out. Maintenance is important in JS based websites and these libraries add maintenance
overhead that isn’t necessary.
----------------------------------------------------
Then What Lazyload does actually do ?
---------------------------------------------------
In shiksha.com we use loadscript & upLoadJsOnDemand function for parallel downloading.
We can easily GREP codebase with "loadScript" or "upLoadJsOnDemand".
Actually Lazyload was introduced for different purpose. It servers files which are
not required in main page rendering. Some features are listed below.
1. load file only once
2. load file after on load event ( before lazyload API, it was unable to load js files in javascript code )
3. callback Fn execution
4. pass objects to callback Fn in global scope
5. callback Fn execution even files are loaded
ReplyDelete