It Takes a Whole Life to be Arrix

For people just looking for code: node-readability on github

Readability by Arc90 is a fantastic javascript tool that makes web pages easier and more enjoyable to read. It removes the clutter around the article content and applies legible and beautiful styles. Apple has incorporated it into Safari Reader. Many other apps have integrated readability, too.

While it's fast and pleasant on a modern desktop browser, the performance on resource limited devices is still unsatisfactory. It often takes several seconds to process a page on my iPad. On Nexus One, the time is much longer.

Several efforts have been made to port the readability algorithm to server side. Including:

• Ruby ruby-readability
• Python python-readability hn.py
• C# nreadability
• PHP php-readability

All these ports have deviated from the original implementation to adapt to the target technology, which means they may produce different result and extra work must be done to keep them up to date if a newer version of readability comes out.

It would be nice if we could run readability.js in a server side javascript host environment so that

• The result is as close to that in browsers as possible
• Minimal changes are required

So I took a stab to adapt readability.js to server side using node.js and jsdom. The code is available on github and there is a live demo (coming soon). The result is quite good in my testing except it's a bit slow.

Here is an example usage

var fs = require('fs'),
readability = require('./lib/readability.js');
var html = fs.readFileSync('test/nytime.html', 'utf-8');
// This is an very early example. The API is subject to change.
readability.parse(html, 'http://www.example.com/somepage.html', function(result) {
 console.log(result.title, result.content);
});

Porting readability.js to node.js

There isn't a full browser environment available for node.js.
Features that can not easily made to work are disabled for now. e.g. Fetching next pages, iframe support.

Another reason for disabling the two features is to keep the code synchronized. node.js is a single threaded event driven execution environment. There is nothing like locking. But readability is written as a singleton one shot object. So I have to reset states before before every run. If the code stops halfway to wait for IO, it might be re-entered before the current run finishes, which surely must be avoided.

Some code paths are disabled because they don't make sense in a non-browser environment but may cause problems.

Some NodeList iteration loops are slightly modified to work around a jsdom limitation where a live NodeList isn't updated automatically after DOM changes when accessed via indexing.

Readability looks for comma(, ) when calculating scores. I've extracted hard coded literals to a variable so that it can be configured to match punctuations in multiple languages. var reComma = /[\uff0c,]/; //chinese comma, too

Readability UI elements, header and footer aren't included in the result. This is merely done to allow more flexible usage. I'd like to include acknowledgement to Arc90 in any final product and suggest all of you do the same.

Most time is spent for performance optimization. See below.

Performance

The first working version was incredibly slow. It was common to take 5-10 seconds to process a moderately sized page. Certain pages can take minutes as if the process is freezing. While node.js uses the very fast V8 javascript engine, the DOM implemented in jsdom uses pure javascript and isn't optimized for performance yet.

I added simple profiling code so that I can see how much time is taken by each step and find code paths worth optimizing most. Below is a sample output for http://en.wikipedia.org/wiki/Ruby

19 Nov 20:57:32 - ---DOM created
19 Nov 20:57:32 - 0 seconds [Remove all stylesheets] 
19 Nov 20:57:32 - 0 seconds [Turn all double br's into p's] 
19 Nov 20:57:32 - 0.05 seconds [prepDocument] 
19 Nov 20:57:33 - 0.455 seconds [grabArticle nodePrepping] 
19 Nov 20:57:33 - 0.015 seconds [grabArticle calculate scores] 
19 Nov 20:57:33 - 0.227 seconds [grabArticle find top candidate] 
19 Nov 20:57:33 - 0.033 seconds [grabArticle look through its siblings] 
19 Nov 20:57:34 - 0.043 seconds [cleanConditionally] 
19 Nov 20:57:34 - 0.2 seconds [cleanConditionally] 
19 Nov 20:57:34 - 0.032 seconds [cleanConditionally] 
19 Nov 20:57:34 - 0.054 seconds [cleanConditionally] 
19 Nov 20:57:34 - 0.026 seconds [prepArticle Remove extra paragraphs] 
19 Nov 20:57:34 - 0.206 seconds [prepArticle innerHTML replacement] 
19 Nov 20:57:34 - 1.372 seconds [prepArticle] 
19 Nov 20:57:34 - 2.407 seconds [grabArticle] 
19 Nov 20:57:34 - 2.53 seconds [================= TOTAL] 
Profiling summary ==========================
 1 2.530 ================= TOTAL
 1 0.050 prepDocument
 1 0.000 Remove all stylesheets
 1 0.000 Turn all double br's into p's
 1 2.407 grabArticle
 1 0.455 grabArticle nodePrepping
 1 0.015 grabArticle calculate scores
 2338 0.071 getInnerText
 1 0.227 grabArticle find top candidate
 105 0.259 getLinkDensity
 1 0.033 grabArticle look through its siblings
 1 1.372 prepArticle
 4 0.329 cleanConditionally
 1 0.026 prepArticle Remove extra paragraphs
 1 0.206 prepArticle innerHTML replacement

As shown in the summary, getInnerText is called many times, that's actually one function that I made hundredfold faster, cutting the running time by seconds.
element.textContent is rather slow in jsdom, so I replaced it with a tree walker.

function TextWalker(node, func) {
 function walk(cur) {
 var children, len, i;
 if (cur.nodeType == 3) {
 func(cur);
 return;
 } else if (cur.nodeType != 1) {
 return;
 }
 
 children = cur.childNodes;
 for (i = 0, len = children.length; i < len; i++) {
 walk(children[i]);
 }
 }
 walk(node);
}
var textContent = '';
TextWalker(e, function(cur) {
 textContent += cur.nodeValue;
});

Tree walkers like above are also used in other places to speed up NodeList iteration. As we know, the getElementsByTagName() function family return a live NodeList which is updated automatically when the DOM changes. Live NoteLists are very fast in most browsers because of highly efficient caching. That's why getElementsByTagName() is much faster than querySelectorAll().

But in jsdom, things are quite opposite. Keeping live NodeLists up to date is very expensive in jsdom (削除) because there is no caching at all. In a tight loop that modifies DOM, live NodeLists are just unaffordable. (削除ここまで)(追記) Update: There is simple version number based caching now but a tree walker is still much faster. (追記ここまで)

So a carefully crafted tree walker is used to replace live NodeList in the "node prepping" part in grabArticle(). This optimization is significant, reducing running time for certain pages from several minutes to seconds.

So far so fast - 1.1 seconds per page

These optimizations turned out to be very effective. In my testing of 140 pages with an average size of 58KB collected from digg, delicious and hacker news, the average time taken for each page is about 1.1 seconds on a Mac Mini (2.4G Intel Core 2 Duo).

The task is CPU bound. The running time is often not linear to DOM size. DOM content and structure can greatly impact performance. The slowest case is when readability fails to extract enough content so it reruns the algorithm with more aggressive configurations. I believe that with more specific tuning for jsdom, the running time can be further reduced.

Limitations

While the port gives good result for most pages, Node.js + jsdom isn't a full browser environment so the missing features impose limitations.

Server side DOM environment doesn't understand CSS. It is reasonable for readability to make use of CSS information. For example, it could discard invisible or too small elements. Although currently readability hardly uses any CSS information, this would be an important limitation in future.

The next step

Coming from the world of servers and back end systems, I care about performance most. I'm going study jsdom more closely to understand its performance characters better. For now, some options in my mind include

• Replace live NodeList iteration with DOM tree transversal when applicable.
• Combine DOM transversals. Do several things in one go.
• Avoid large innerHTML assignment when possible. HTML parsing and DOM creation are expensive.

Regarding readability.js itself. I'd like to suggest a few improvements. I'd be happy if I can contribute.

1. Separate the library part from the bookmarklet part. The core algorithms can be extracted as a library. This allows the core function to be used with different front ends. e.g. A browser extension, a widget.
   
2. Organize the core into several modules and break big functions into smaller ones.
3. Add some hooks and more configurations so that it's possible to do page specific optimization in a plug-in manner.
4. Currently, readability is a singleton one shot object. It'll be nice to make it classy so that state management will be easier in an event driven architecture.
5. Be unobtrusive. It would be nice if the original DOM can be left intact.

At the end of this post, I'd like to thank Arc90 for building such a wonderful tool and Elijah Insua (@tmpvar), whose jsdom has opened many seriously cool possibilities for server side javascipt.

Posted by Arrix at 1:11 AM 5 comments

Labels: javascript, nodejs

The non-standard marquee tag, first introduced in early versions of IE, can be useful to create scrolling effects. Though deprecated, all major browsers today seem to support it.

sample scrolling text in marquee

One thing you should be aware of is that in Webkit (used by Appla Safari and Google Chrome), marquee generates a steady stream of scroll events. If you have listeners to the scroll event on the document, watch out for these events which bubble up to the document! You may want to filter out them by checking event.target. For example:

$(document).bind('scroll', function(event) {
 //filter out scroll events of marquees in Webkit
 if (event.target != document) return;
 //documrent scroll...
});

Posted by Arrix at 2:48 AM 1 comments

Labels: browser, bsb, javascript, webkit

A test case in my work requires a complete list of HTML elements and a list of self-closing elements (e.g. <br/>).

The W3C Index of HTML 4 Elements lists all defined elements in a table. For each row with an "E" in the Empty column, the corresponding element doesn't need a closing tag (and thus is self-closing).

With two lines of jQuery code in the Firebug console, I got the lists I wanted. Here is how:

To get all elements

$.map($('table tr:gt(0) a'), function(e) {return $.trim($(e).text());})

To get all self-closing elements (formatted for readability)

$.map(
 $('table tr:gt(0)').filter(function() {
 return $(this).find('td:nth-child(4)').text() == 'E';
 }), 
 function(e){return $.trim($(e).find('td:first-child').text());});

$.trim() is needed because the HTML source contains \n in the Name column.

This demonstrates a handy usage of jQuery as a hacking tool. Another excellent demonstration can be found here.

You can add jQuery to the current page using the bookmarklet.

Happy jQuerifying!

Posted by Arrix at 11:10 PM 0 comments

Labels: clog, javascript, jQuery

eval('function(){}') evaluates to undefined in IE, the same for eval('(function(){})').

How to get the Function?

eval('[function(){}][0]')

IE, you always let me down!

Posted by Arrix at 4:55 PM 1 comments

Labels: hack, javascript

JavaScript is Loosely typed

JavaScript is dynamically typed, making things extremely flexible. Suppose you have a text field for inputting birth year and want to greet to people born after 1984, simply write

var birthYear = document.getElementById('txtBirthYear').value;
if (birthYear > 1984) {
	alert('Greetings!');	
}

When JavaScript sees you compare a String with a Number, it automatically converts the String to Number and the perform comparison.

But sometimes the ambiguity of type causes problems. 1 + '1' evaluates to '11' instead of 2. This may cause hard to find bugs. Douglas Crockford categorizes "the overloading of + to mean both addition and concatenation with type coercion" as a design error of JavaScript in his famous article on The World's Most Misunderstood Programming Language.

Still we often need to convert data type between String and Number. To convert variable i to String, simply call i.toString(). To convert s to a Number, we use Number(s). This is nice and clear.

The empty string ('') concatenation trick, the plus sign (+) trick and the minus zero (- 0) trick

But for guys who want to squeeze every byte. There are tricky alternatives.

• To convert x to String: x + ''
  
• To convert x to Number: +x
  
• To convert x to Number: x - 0

For examples,

1 + 2 + 3 //produces 6
//while
'1' + 2 + 3 //produces '123'

'1' - 0 + 2 + 3 //produces 6
'1' + '2' //produces '12'
//while
+'1' + +'2' //produces 3

Notice that +x and x-0 doesn't mean parseInt(x) or parseFloat(x), it doesn't do any further parsing.

parseInt('2007 is promising') //produces 2007
//while
+'2007 is promising' //produces NaN

Let's call them the empty string concatenation conversion trick, the plus sign and the minus zero trick. Both of the tricks sacrifice clarity and make code harder to understand.

Posted by Arrix at 11:19 PM 3 comments

Labels: javascript

eval() evaluates a string of JavaScript code. The Function constructor can be used to create a function from string. Someone says that the Function constructor is another form of eval(). However, one significant difference between eval() and the Function constructor is that while eval() keeps the lexical scope, the Function constructor always creates top-level functions.

function f1() {
	var bbb = 2; 
	eval('alert(bbb);');
}
f1(); //alerts 2

function f2() {
	var bbb = 2; 
	new Function('alert(bbb)')();
} 
f2(); //bbb undefined error

function f3() {
	var bbb = 2; 
	eval('function() {alert(bbb);}')();
}
f3(); //alerts 2

eval() inside a function body creates a closure while new Function() doesn't. This difference may not bother you for the whole lifetime. However, it happens to bother me once. It's about jQuery - a new type of JavaScript library. I'm using jQuery in my bookmarklet application. In order to make the code as unobtrusive as possible, I decided to put all my code including the jQuery code inside an anonymous function. It looks like this:

(function() {
	//jQuery code
	//my code
})();

In this way, even the jQuery object is just a local variable. The outside environment is completely unaffected. But $().parents(), $().children, $().prev(), $().next() and $().siblings() always fail in my code. These functions are created by the Function constructor in $.grep() and $.map().

// If a string is passed in for the function, make a function
// for it (a handy shortcut)
if ( typeof fn == "string" )
	fn = new Function("a","i","return " + fn);

So they are all top-level and the identifier "jQuery" inside is resolved as window.jQuery which is undefined and the code fails.

We can implement an alternative to the Function constructor and use it within the lexical scope:

var createFunc = (function () {
	var args = [].slice.call(arguments);
	var body = args.pop();
	return eval('function(' + args.join(',') + ') {' + body + '}');
}).toString();

function f4() {
	var bbb = 2;
	eval(createFunc)('alert(bbb);')();	
}
f4(); //alerts 2

You can use eval(createFunc) just like new Function(), but you get the bonus lexical scope binding.

function f6() {
	var add = function(a, b) {return a + b;};
	return eval(createFunc)('x', 'y', 'return add(x, y);');
}
f6()(3, 5); //8

At last, I quote Douglas Crockford's words on eval() and the Function constructor

"eval is Evil

The eval function is the most misused feature of JavaScript. Avoid it.

eval has aliases. Do not use the Function constructor. Do not pass strings to setTimeout or setInterval. "

Posted by Arrix at 5:06 PM 4 comments

Labels: hack, javascript

I'm previewing the the ultimate JavaScript book for the modern web developer. It's a great book. I strongly recommend you read it and I'm sure that you'll thank me. To make it even better, I'd like to point out and discuss several controversial points.

A side effect of the anonymous function scope induction trick

At the end of Chapter 2 >> Privileged Methods

Listing 2-25. Example of Dynamically Generated Methods That Are Created When a New Object Is Instantiated

// Create a new user object that accepts an object of properties
function User( properties ) {
	// Iterate through the properties of the object, and make sure
	// that it's properly scoped (as discussed previously)
	for ( var i in properties ) { (function(){
		// Create a new getter for the property
		this[ "get" + i ] = function() {
			return properties[i];
		};
		// Create a new setter for the property
		this[ "set" + i ] = function(val) {
			properties[i] = val;
		};
	})(); }
}
// Create a new user object instance and pass in an object of
// properties to seed it with
var user = new User({
	name: "Bob",
	age: 44
});
// Just note that the name property does not exist, as it's private
// within the properties object
alert( user.name == null );
// However, we're able to access its value using the new getname()
// method, that was dynamically generated
alert( user.getname() == "Bob" );
// Finally, we can see that it's possible to set and get the age using
// the newly generated functions
user.setage( 22 );
alert( user.getage() == 22 );

The example code won't work as expected. My test with Firefox 2.0.0.1 shows that the user.getname and user.getage are actually undefined. But window.getname and window.getage are there! The error is caused by the scope induction trick:
(function(){})(). Inside the anonymous function, the this variable somehow points to the window object! In the simplest case:

var o = {f: function() {(function(){alert(this === window);})();}}; o.f(); 
//alerts true (but false if you evaluate the whole line in Firebug 1.0b8)

Seems that the implementation treats anonymous functions as properties of the window object?

null, 0, ‘’, false, and undefined are NOT all equal (==) to each other

In Chapter 3 >> != and == vs. !== and ===

"...In JavaScript, null, 0, ‘’, false, and undefined are all equal (==) to each other, since they all evaluate to false... "

Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined
// You should use !== or === instead
null !== false
false === false

Actually 0, '' and false all equal (==) to each other and null equals (==) to undefined but both null == false and undefined == false evaluate to false. This is reasonable because both null and undefined indicate "no value" while false is a valid value.

domReady Race Conditions

In Chapter 5 >> Figuring Out When the DOM Is Loaded
Listing 5-12. A Function for Watching the DOM Until It’s Ready

function domReady( f ) {
	// If the DOM is already loaded, execute the function right away
	if ( domReady.done ) return f();
	// If we've already added a function
	if ( domReady.timer ) {
		// Add it to the list of functions to execute
		domReady.ready.push( f );
	} else {
		// Attach an event for when the page finishes loading,
		// just in case it finishes first. Uses addEvent.
		addEvent( window, "load", isDOMReady );
		// Initialize the array of functions to execute
		domReady.ready = [ f ];
		// Check to see if the DOM is ready as quickly as possible
		domReady.timer = setInterval( isDOMReady, 13);
	}
}

// Checks to see if the DOM is ready for navigation
function isDOMReady() {
	// If we already figured out that the page is ready, ignore
	if ( domReady.done ) return false;
	// Check to see if a number of functions and elements are
	// able to be accessed
	if ( document && document.getElementsByTagName &&
	document.getElementById && document.body ) {
		// If they're ready, we can stop checking
		clearInterval( domReady.timer );
		domReady.timer = null;
		// Execute all the functions that were waiting
		for ( var i = 0; i < domReady.ready.length; i++ )
			domReady.ready[i]();
		// Remember that we're now done
		domReady.ready = null;
		domReady.done = true;
	}
}

Notice that in the domReady function, isDOMReady is added as a handler of the "load" event of window. The purpose of this is to take advantages of browser caching cabability to gain extra speed. However, the extra gain here causes troubles. When I tried to use this domReady implementation in a GreaseMonkey user script, sometimes the onDOMReady handler gets triggered twice. It isn't always reproducable. But if you refresh the page 15 times, you can see the double triggering problem one or twice. The only possible cause is the addEvent line. So I commented out the line and tested again, as expected, everything went OK.

I looked carefully at the code to find a possible race condition in function isDOMReady. The function

1. Checks domReady.done
   
2. ClearInterval and call handlers if DOM is ready
   
3. Mark domReady.done true

When a page gets cached by browser, the window "load" event and an interval event almost occur at the same time, resulting two threads of isDOMReady executing side by side. In case that one thread is in step 2 but before step 3 while the other is reaching step 1, the later will read domReady.done as false and proceed to step 2, causing every handler triggered a second time.

There are two ways to work around

1. Remove the addEvent line and be happy without the extra speed gain
   
2. Advance the domReady.done = true; line as early as possible (may reduce but can't eliminate race conditions)

Update 2007年2月06日 09:16:03 GMT window.onload reopened

The domReady() function above will prematurelly execute the handler if document.write() is used. The document ready solution in jQuery is so far the most robust. But in IE, premature execution will occur if innerHTML modification is performed before the document finishes loading. So the window.onload problem is now reopened. Great effort has been made to solve the problems.

• The window.onload Problem - Solved!
  
• window.onload - An Alternative Solution
  
• window.onload (again)
  
• The window.onload Problem Revisited
  
• The window.onload problem (still) //a very complete coverage

Posted by Arrix at 10:37 PM 0 comments

Labels: javascript

2007年06月27日 08:26:49 UTC Update: Microsoft has fixed IE memory leaks problem. KB929874

2006年10月24日 +8 Update: According to IE 7 vs IE 6, IE 7 seems to have solved the memory leaks. Cheers!

(削除) 2006年09月24日 +8 Update: See (削除ここまで)(削除) the follow up (削除ここまで)

"Betty: Your umbrella leaks, Professor Boffin!" ---- Look, Listen and Learn

IE leaks memory like a sieve and my web page is getting slower and slo...ower. But memory usage keeps climbing...

I've tried everything including banging my head on the desk. It just doesn't change anything.

I read the following articles and fell asleep.

• IE: WHERE'S MY MEMORY?
• JavaScript Closures for Dummies
• JavaScript Closures
• Leak Free JavaScript Closures
• Memory Leakage in Internet Explorer - revisited
• addEvent() - My Solution
• Understanding and Solving Internet Explorer Leak Patterns
• Closures and IE Circular References
• Fabulous Adventures In Coding

The fact is that IE has separate garbage collecting mechanisms for COM interfaces and JavaScript objects and is unable to resolve circular references between DOM(or ActiveX or any kind of COM) objects and JavaScript objects. When objects form the two worlds have circular references between them, GC can not detect them and the memory cannot be reclaimed until IE exists. There are several patterns that cause circular references. Unfortunately, assigning nested functions as event handlers falls into this category. IE is rejecting the use of closure, one of the most powerful and flexible feature of JavaScript.

It is frustrating to know that experts at Microsoft like Eric Lippert suggest "Don't use closures unless you really need closure semantics. In most cases, non-nested functions are the right way to go." It sounds like that programmers are abusing closures, completely ignoring that IE has a big problem with closures. It would be relieving and reasonable to expect that IE will reclaim leaked memory after a page has been unloaded. But that's not the fact. And here I found some explanation: "...the application compatibility lab discovered that there were actually web pages that broke when those semantics were implemented. (No, I don't know the details.) The IE team considers breaking existing web pages that used to work to be way, way worse than leaking a little memory here and there, so they've decided to take the hit and leak the memory in this case." I don't understand. Maintaining backward compatibility with rare web pages which even an scripting engine writer does not know much about at the cost of leaking memory possibly for all web pages? What kind of decision is it? They don't admit their own faults but instead suggest poor coding practices.

But we have to code for IE, however buggy it is. I've run the test from Mihai Bazon(see IE: WHERE'S MY MEMORY?).

function createEl(i) { 
	var span = document.createElement("span"); 
	span.className = "muci"; 
	span.innerHTML = " foobar #"+i+" "; 
	span.onclick = function() { 
		alert(this.innerHTML + "\n" + i); 
	}; 
	document.body.appendChild(span); 
} 

function start() { 
	var T1 = (new Date()).getTime(); // DEBUG.PROFILE 
	for (var i = 0; i < 3000; ++i) createEl(i); 
	alert(((new Date()).getTime() - T1) / 1000); // DEBUG.PROFILE 
} 

The first request in IE took 1.797s, the tenth 8.063s. Memory usage kept growing. Firefox reports a typical value of 1.6xs with no memory leak. Prototype.js avoids IE memory leak by hooking window's unload event, unobserving all events and clearing its event handler cache. I replaced the line span.onclick = function() { alert(this.innerHTML + "\n" + i); }; with Event.observe(span, 'click', function() { alert(this.innerHTML + "\n" + i); }); and rerun the test. The good news is that the leaked memory in IE is reclaimed when the page unloads. The bad news is that each request takes approximately 17s in IE while Firefox only needs 2.1xs! The Prototype event system makes it possible to free memory when page unloads but is extremely slow and uses more memory in a single request. The speed degradation is explainable: Event._observeAndCache saves extra references thus uses more memory and IE gets slow as it leaks memory. Event.observe does more things than a simple assignment thus is much slower. However, memory leak is under control... I admire Edward Dean's addEvent though it doesn't solve the memory leak problem with closures. (Dean insisted that his script does not leak memory in comments. Maybe he is not talking about the closure case). Leak Free JavaScript Closures solution can really prevent memory leak. (削除) The way it breaks circular reference inserting a new closure between the nested function and its closing scope. The fancy part is that when another level of closure is added, the inner closure can still access variables in its initial closing scope indirectly via scope chain without causing circular references between DOM objects and JavaScript objects. (削除ここまで) The way it breaks circular reference is create a new function which holds no references to the closing scope.

In the simplest case:

<script type="text/javascript">
//Holds references to functions
__funcs = []; 
//The code fragment is for demonstrative purpose only and lacks of optimization.
//Do not use it in productive environment!
Function.prototype.closure = function() {
	__funcs.push(this);
	return function () {
		return __funcs[__funcs.length - 1].apply(null, arguments);
	};
}; 
function setup() {
	var span = $('span1');
	span.bigProperty = new Array(1000).join('-_-');
	span.onclick = function() {
		alert(span.bigProperty.length);
	}.closure();
}
setup();
</script> 

This will not leak memory in IE. The nested function in setup() forms a closure so it's able access span. span.onclick does not refer to the nested function but a newly created function returned by the closure() method of the nested function. The newly created function invokes the nested function via global array __funcs and have no references to the scope of setup(). So there is no circular reference. You may argue that the newly created function is able to call the nested function, it must have some kind of reference to it while the nested function have reference to span via closure, so there will be a circular reference. However, ECMA 262 treat this as a keyword rather than an identifier, this keyword is resolved dependent on execution context in which it occurs, without reference to the scope chain (see Javascript Closures ). A global array is used to hold references to closures without modifying the internal [[scope]] object. This is a hack indeed. IE always needs hacks to amend its holes.

Posted by Arrix at 10:02 PM 3 comments

Labels: javascript

The arguments object is an Array-like object providing access to arguments passed to a function. When hacking with functions, we frequently need to manipulate and pass around arguments as an Array. The Prototype library uses it's $A() function to accomplish the conversion, which is intuitive and beautiful.

Function.prototype.bind = function() {
 var __method = this, args = $A(arguments), object = args.shift();
 return function() {
 return __method.apply(object, args.concat($A(arguments)));
 }
}

Yet there is a another way.

//... inside a function definition
var args = [].slice.call(arguments);

// or var args = Array.prototype.slice.call(arguments);
//...

The slice(start, end) method of an Array object returns a copy of a specified portion of the array. Here we omit the start and end arguments and call slice() upon the arguments object. An array containing all arguments is returned. Then we can modify the array as we need and pass it to the apply() method of functions.

Notice that slice() only does a shallow copy and the return value is just an array any without magical behavior of the arguments object. There is no args.callee property. Moreover, if a parameter is listed at the nth position in the parameter list of the function definition, arguments[n] is a synonym for the local variable corresponding to the nth argument. Any change made to arguments[n] will affect the local variable because it's actually modifying the named property of the call object. However, since args is just a shallow copy of arguments, assigning args[n] will not affect the local variable. To demonstrate this,

function f (a) {
alert('a: ' + a);
var args = [].slice.call(arguments);
arguments[0] = 'Assigning arguments[0] affects a';
alert('a: ' + a);
args[0] = 'Assigning args[0] does not change a';
alert('a: ' + a);
}
f('JavaScript rocks!');

The three alerts will display "a: JavaScript rocks", "a: Assigning arguments[0] affects a" and "a: Assigning arguments[0] affects a" in order.

Tip: [].slice.call() can be used for any Array like objects, not only limited to the arguments object.

Posted by Arrix at 8:45 PM 5 comments

Labels: hack, javascript