Jul 27
Over at the the YUI blog the team just announced the preview release of YUI 3.2.0. YUI3 now has some interesting new features that the team wants you to try and tell them if they work out for you. The changes to the already very powerful library are quite ambitious:
So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:
The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.
There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.
Continue reading »
Tagged with: 3.2.0 • browserspecific • events • loading • Preview • release • support • Touch • transitions
Mar 18
A certain someone was talking to me about how they find it interesting that node.js, the JavaScript server framework du jour which loves all things async, starts life with a bunch of synchronous require() calls. Now, this is actually quite fine since the startup of the server is not the issue at hand.
However, if you are running require()-esque loader code in the browser you want to avoid blocking calls else Steve Souders will come over and beat you up.
I have seen a couple of interesting items in this area:
RequireJS
James Burke of Mozilla Messaging has spent a lot of time in the depths of dojo.require(). He has taken another look at the problem and RequireJS a solution that offers:
- some sort of #include/import/require
- ability to load nested dependencies
- ease of use for developer but then backed by an optimization tool that helps deployment
He walks through the problem and why other solutions like LABjs, CommonJS require, and Dojo itself don’t cover all of his bases.
The end result is:
JAVASCRIPT:
-
-
// code that runs asynchronously when the library is loaded
-
require([“some/script.js”], function() {
-
//This function is called after some/script.js has loaded.
-
});
-
-
// defining the module and dependencies
-
require.def(
-
// The name of this module
-
“types/Manager”,
-
-
// The array of dependencies
-
[“types/Employee”],
-
-
// The function to execute when all dependencies have loaded. The arguments
-
// to this function are the array of dependencies mentioned above.
-
function (Employee) {
-
function Manager () {
-
this.reports = [];
-
}
-
-
// This will now work
-
Manager.prototype = new Employee();
-
-
// return the Manager constructor function so it can be used by other modules.
-
return Manager;
-
}
-
);
-
Google Analytics “async add to []” Pattern
When talking to Davis Frank of Pivotal about some Google Analytics code, he pointed me to details about the new GA asynchronous loader that we very excitedly blogged about since GA was such a blocking offender on the Web.
Part of the asynchronous API is that you, the developer create an array, and use the push() method to put commands on a queue. This means that you can start pushing commands immediately.
Then, when the GA code loads asynchronously, it takes over that array and wraps those standard methods. Now it can take the commands and fire them back to GA and push() can do more. Freaking brilliant.
Continue reading »
Tagged with: Asynchronous • JavaScript • loading • RequireJS