I read a post on Ajaxian about Fusebox, a JavaScript library which is described as:

[...] The problem is that frameworks / libraries / third-party scripts may overwrite native methods or each other’s custom methods resulting in unpredictable outcomes. Fusebox, a limited version of the sandboxing component found in FuseJS, avoids these issues by creating sandboxed natives which can be extended without affecting the document natives.

I think Fusebox is a good project. The code in this blog post shows a different approach which in some situations may be more useful and in others, it may not.

With Fusebox script developers avoid polluting the globals by writing their scripts using FuseBox and its wrappers. E.g, you write code with a “Fusebox prefix” like this:

  var fb = Fusebox();
  fb.Array.prototype.hai = function() {
    return fb.String("Oh hai, we have " + this.length + " items.");
  };
  fb.Array(1,2,3).hai(); // "Oh hai, we have 3 items."
  typeof window.Array.prototype.hai; // undefined

// like the native Array constructor the sandboxed constructor will return [ , , ]
  var a = fb.Array(3);
  // equiv to square-bracket notation [3]
  var b = fb.Array.create(3);
  // converting a native array to a sandboxed array
  var c = fb.Array.fromArray([1, 2, 3]);

That immediately reminded be of some work I’ve have been doing with colleague Jimmy Junker at Trifork (jju at trifork com) motivated by the following problem:

In portal environments where multiple portlets want to use different JavaScript libraries or different versions of the same JavaScript libraries, you are very likely to run in to problems since almost all libraries (except later YUI versions) are designed to live in the global namespace.

After a brainstorming session we developed a simple prototype (no pun intended), uninspiringly named “VersionManager”, with which we succeeded in loading two different versions of the PrototypeJS library. With VersionManager you can write code like this:

with (VersionManager.version("1.6.1")) {
//"1.6.1" refers to prototype which must have been loaded
  console.log("abcdaba".gsub("a","42"));// console.logs '42bcd42b42'
  console.log(typeof Object.extend);// console.logs 'function'
  $A([1,2,3])._each(function(x){
    console.log(x);
  });// console.logs '1','2','3'
}
VersionManager.clear();//otherwise previous version is lingering...
try {
  console.log(typeof "".gsub);
//console.logs 'function' <= this is generic delegating proxy function
  console.log("abcdaba".gsub("a","42"));//throws error
} catch (e) {
  console.log(e);
  //TypeError: "attempt call to delegate with no version defined (see documentation)"
}
console.log(typeof Object.extend);// console.logs 'undefined'
console.log(typeof $A);// console.logs 'undefined'

So version manager lets you load several libraries on the page, and sandboxes changes made to globals. By telling VersionManager which version you want to use for a particular block you code, you can use each of those libraries, even if they define the same global variables or properties on the prototypes of objects, e.g., Array.prototype.

VersionManager also creates sandboxes, but as opposed to Fusebox, what is sandboxed is "changes made to" the built-ins, and global variables defined. Also, the goal is not to avoid extending the prototypes, but almost the opposite: to allow several scripts/libraries that would otherwise conflict to live in the same page without seeing each other, even if they define the same global names or want to extend built-in prototypes in different ways.

With VersionManager you simply write regular user code, but wrap it in a with statement. This means that existing code can easily be rewritten.

The loaded "sandboxed" libraries must adhere to a few syntactic and semantic constraints.
For an example, see a sandboxed version of prototypejs here

Transformed prototypejs

The transformation applied to prototypejs is very simple and can be done automatically (i.e., it is easy to write a program that performs this script-transformation for you). It is a bit technical, but it results in is adding a declaration with-statement "header" at the beginning and a "footer" and the end. In fact, we are writing a program that transforms any JavaScript program/library into an equivalent one that adheres to these constraints.

An alpha version is on github. It is a proof-of-concept that shows that the fundamental approach seems to work.

jdalton pointed out a couple of things :

• You may run into problems with minifiers given that your code is wrapped in 'with'. However, you can minify the code first, and then wrap it.
• It doesn't track changes to event or elements.

So far, we've tested it only in latest Firefox and Safari, but I see no reason why it couldn't work in other recent browsers. We have sucessfully loaded prototypejs in a sandbox, and managed to run all prototypejs unit tests successfully inside the sandbox.

Github project: http://github.com/krukow/versionmanager

/Karl

A what? A partial evaluator (or program specializer) is a program which takes two inputs: another program and an environment mapping variables to values; it outputs a specialized (i.e., more efficient) version of the input program with respect to the environment. One can think of a partial evaluator as a mix between an interpreter and a compiler: it interprets the static parts of the program and emits code for the dynamic parts.

For a simple example of code specialization, consider the following function for creating a string corresponding to an HTML tag:

var mk_tag = function(tag_name,clazz,contents) {
   return '<'+tag_name+' class="'+clazz+'">'+contents+'</'+tag_name+'>';
};

If we are only interested in making ‘div’ tags with a class of ‘green’ then a more efficient version would be:

var mk_div_green = function(contents) {
   return '<div class="green">'+contents+'</div>';
};

since it would require fewer string concatenations per call. We can think of ‘mk_div_green’ as a version of ‘mk_tag’ which is specialized for writing ‘div’ tags with a class of ‘green’. A partial evaluator for JavaScript could automatically derive the ‘mk_div_green’ function from the ‘mk_tag’ function.

This is exactly what we can do with the evaluator in this posting.

//This code actually works  
Function.prototype.specialize = net.higherorder.jeene.Jeene.make();

var mk_tag = function(tag,clz,cont) {
   return "<"+tag+" class='"+clz+"'>"+cont+"</"+tag+">";
};

var mk_div_green = mk_tag.specialize({tag:'div', clz: 'green'});

mk_div_green("Pratt rocks!");
//result: <div class='green'>Pratt rocks!</div>

mk_div_green.toSource ? mk_div_green.toSource() : mk_div_green.toString();
//result:
//(function (cont) {return ("<div class='green'>" + cont) + "</div>";})

This last line, shows that the output function is much more efficient than what is created by general JavaScript curriers which have been seen before: these functions merely wait evaluating the function until all parameters are supplied; instead, a partial evaluator will create specialized function taking advantage of the information given.

The first goal is for the partial evaluator to process any function written in an extension of “simplified JavaScript” (a subset of full JavaScript corresponding to what Crockford calls the “good parts“). This partial evaluator will have a number of useful features: it

• can easily be extended to full JavaScript;
• is written in simplified JavaScript (think Futamura projections);
• is a fast extension of Douglas Crockford’s Pratt parser;
• because functions implement the toString method, it can be run on dynamically generated functions (e.g., a specialized function can be further specialized);
• can be embedded in any full JavaScript program as long as it is only used to specialize functions which are syntactically in simplified JavaScript;

I have started a new open source project, Jeene, which aims to create an efficient partial evaluator for full JavaScript that works in any ECMAScript 3 compliant implementation (e.g., all major browsers, Rhino, TraceMonkey, V8 etc). Right now the project is at a very early stage; a proof of concept, for example it cannot specialize itself. Let me know if you are interested in contributing: I will use a 1 patch threshold like Rubinius: if you submit one patch which is accepted, you get commit rights.

Stay tuned here for more information about how Jeene is designed and implemented.

function object(p) {
   function F(){}
   F.prototype = p;
   return new F();
}

The object function creates a new object which has the input object (p) as it’s prototype.

On the comp.lang.javascript newsgroup Richard Cornford showed a functionally equivalent version which has better performance in general:

var object = (function(){
    function F(){}
    return function(p){
        F.prototype = p;
        return new F();
    };
})();

In this version, all invocations of object share the same F which has its prototype mutated with each call. Cornford argues:

[The first version of 'object']... is an example of the process that clearly expresses what is being done, but is not particularly efficient as it creates a new - F - function each time it is executed, but all of those - F - functions are essentially identical. If this is to be done often then a more efficient approach would be to only create a single - F - function and put it where it could not be modified by external code.

Now, it is important to notice that in general one has to be careful when applying this technique to recursive functions as a variable mutation in one level of recursion may affect others. Also, if we were to put threads into JavaScript, this code would go from being thread-safe in the original form to non-thread safe in the optimized form. However, for now, this technique can be applied in performance-critical functions.

In fact, there is a general technique here that one might call code specialization via higher-order functions (which can be seen as a poor-mans form of partial evaluation). Here is a simple example of that general technique: The ‘mk_tag’ function creates the string for an html tag with a class attribute and a text-contents.

function mk_tag(tag_name,clazz,contents) {
   return '<'+tag_name+' class="'+clazz+'">'+contents+'</'+tag_name+'>';
}

Using code specialization via higher-order functions (by currying), we can make specialized functions for writing e.g. ‘div’ tags, and specialized (faster) functions for making ‘div’ tags with certain classes. The trick is to compute as much as is possible with the given inputs before returning the specialized function:

//a curried version which specializes to it's input
function curried_mk_tag(tag_name) {
  var tag_hd = '<'+tag_name+' class="',
      tag_tail = '</'+tag_name+'>';
  return function(clazz) {
     var head = tag_hd+clazz+'">';
     return function(contents) {
         return head+contents+tag_tail;
     };
  };
}

var mk_div = curried_mk_tag("div");
var mk_div_green = mk_div("green");
var mk_div_blue = mk_div("blue");
mk_div_green("karl")//<-- "<div class="green">karl</div>"
mk_div_blue("karl")//<-- "<div class="blue">karl</div>"

This is elegant as functions can be reused, e.g., ‘mk_div_green(“karl”);mk_div_green(“krukow”)’. But notice that it is more efficient than simply using a general currier (e.g., Diaz); essentially it is a form of manual partial evaluation.

I’ll post some performance measurements in a later posting, but initial results show that we can reduce execution time by roughly 40% by using the sharing form of the object function.

More Examples

I’m not sure how many JavaScript programmers are familiar with this type of optimization. Here are a bunch of real-world examples where it can be applied:

Prototype – Ajax.request function

var Ajax = {//original
  getTransport: function() {
    return Try.these(
      function() {return new XMLHttpRequest()},
      function() {return new ActiveXObject('Msxml2.XMLHTTP')},
      function() {return new ActiveXObject('Microsoft.XMLHTTP')}
    ) || false;  },

  activeRequestCount: 0
};

The thing to notice here is that every time getTransport is called prototype will recompute which XMLHttp transport to use. However, the result of Try.these will always be the same in a particular run of Prototype, i.e., the showing of a page in one browser. So we might as well precompute which object is the correct one:

var Ajax = {//modified form
  getTransport: Try.these(
         function() { new XMLHttpRequest(); //test if it exists
            return function() {return new XMLHttpRequest();}
         },
         function() { new ActiveXObject('Msxml2.XMLHTTP'); //test
            return function() {return new ActiveXObject('Msxml2.XMLHTTP'); }
         },
         function() { new ActiveXObject('Microsoft.XMLHTTP');
            return function() {return new ActiveXObject('Microsoft.XMLHTTP'); }
         }),

  activeRequestCount: 0
};

jQuery - attr function

attr: function( name, value, type ) {
 var options = name;

 // Look for the case where we're accessing a style value
 if ( name.constructor == String )
  if ( value === undefined )
   return this[0] && jQuery[ type || "attr" ]( this[0], name );

  else {
   options = {};
   options[ name ] = value;
  }

  // Check to see if we're setting style values
 return this.each(function(i){
  // Set all the styles
  for ( name in options )
   jQuery.attr(    type ?  this.style :     this,
    name, jQuery.prop( this, options[ name ], type, i, name )   );
 });
}

With jQuery we can’t write a curried form as that would break compatability. However, we can still perform optimizations like what we had with the ‘object’ function. Notice that the function supplied to ‘each’ is created with each invocation of ‘attr’, you can also see a for-loop where a check to ‘type’ is made with each iteration. In our optimized version, attr chooses which inner function to give to ‘each’ by checking type first.

jQuery.fn.attr = (function(){
    var type,
        options,
        inner_type = function(i){
          // Set all the styles
          var t  = type,
              s  = this.style;
          for (var name in options ) {
              jQuery.attr(s,
                          name,
                           jQuery.prop( this, options[ name ], t, i, name )
              );
          }
        },
        inner_no_type = function(i) {
          for (var name in options ) {
              jQuery.attr(this,
                          name,
                           jQuery.prop( this, options[ name ], null, i, name )
              );
          }
        };

    return function( name, value, t ) {
                type = t;
                options = name;
  // Look for the case where we're accessing a style value
  if ( name.constructor == String )
   if ( value === undefined )
    return this[0] && jQuery[ type || "attr" ]( this[0], name );

   else {
    options = {};
    options[ name ] = value;
   }

  // Check to see if we're setting style values
  return this.each(t ? inner_type : inner_no_type);
 };
})();