Sunday, March 28, 2010

just a quick post about ES5 Object.create performances. While in More ES5 Friendly Patterns paragraph I have described how to use new ES5 features to create instances in a better way, I have never tested directly performances against classic ES3 pattern.

The Benchmark Logic

Pretty simple, create a new object with a "privileged property" plus an inherited one. The test prototype looks like this object:

var proto = {toString:function () { return this.name;}}

The assumption is that somehow the object should be able to return it's name, which is not shared via prototype.

ES3 Game

I hope I don't have to explain this piece of code:

function F(name) { this.name = name;}F.prototype = proto;

To test above classical pattern, all we need is to confirm this behavior:

var o = new F("instance");alert(String(o) === "instance");

ES5 Game

Using an updated browser, it should be possible to replicate ES3 behavior via this piece of code:

var o = Object.create(proto, { name: { value:"object" }});

Right, Object.create comes with much more power than a simple property assignment, but here we are testing a basic task just to analyze what's the outcome, right? Just to be sure about the result:

alert(String(o) === "object");

Optimized ES5 Game

What can we do to improve performances? Avoid global scope look up, the Object constructor, plus use a static/fixed property to cheat the test:

The Result

Based on Atom N270 nad testing via Chrome 5 for devs, this is what I read in the alert:

ms: 7ms: 2325ms: 2218

The first result goes up to 54ms, reaching 5ms, the second one is pretty much stable while the latest one goes down 'till 1987 ms ...

Conclusion

new Constructor seems to be the best option for those cases where the initialize/init/construct method needs to somehow setup the created instance. Only if we need special Object.create features it is worth it to use it, but if we base a whole framework over Object.create, considering eventually emulations for old browsers, this framework will be inevitably slower than older code. This means that as example a classic Point class option, should still be exactly like this:

function Point(x, y, z) { this.x = x; this.y = y; this.z = z;}

or eventually like the next one, if we don't need chained methods, neither new before each call:

Tuesday, March 16, 2010

When a function is to be invoked immediately, the entire invocation expression should be wrapped in parens so that it is clear that the value being produced is the result of the function and not the function itself.

Why Bother

Actually, I have always found the expression:

var something = function(){

// do stuff // return something

}(); // invoke

kinda enough to invoke inline a function expression.Somebody argued that above style is ambiguous.Since an inline invoke could be performed against a massive function body, the point is that we may need to scroll 'till the end of the function expression to know if it has been executed or not.In my opinion, whenever there is a function expression, we should always check the end of this function or we'll never be sure about the assigned value.Fair enough, even if the function could not be necessary invoked:

var something = function(){

// do stuff // return or not

}.bind(this);

expressions are usually wrapped in any case regardless what's up at the end.

Still ... Why Bother

The most common implementation of this code convention we can find almost everywhere, included my shared code, is this one:

var something = (function(){

// do stuff // return something

})(); // invoke

What is actually wrong with this implementation?Let's simply imagine the function returns a function:

var something = (function(){ return function(){ return 123; };})();

Now, let's imagine that we would like to execute runtime the returned function, since we know that expression will return one:

I am pretty sure that ()() at the end of a runtime invoked expression, will bring us back to origins, where "we had to check 'till the end of the function", at least to understand what is going on ... In few words, and as I have said, the scroll 'till the end of whatever function should be mandatory, if the code is not our one, and we would like to understand what this code actually does.

Non Ambiguously Speaking

If we follow Mr D. suggestion, we could say that this strategy will be rarely ambiguous.To spot a wrap is definitively more easy than spot a potential typo, as 4 brackets could suggest:

var something = (function(){ return function(){ return 123; };}());

With latter snippet we can certainly say with a quick look that something refers the value returned by the invoked expression. It's wrapped, it must be an invoke rather than a function assignment, and it could be whatever value.The instant we add other brackets, we are obviously dealing with the returned value:

In other words we are able to split the inline invoked expression, with the rest of the logic, but still scrolling through the end!

Moreover

The usage of brackets makes the assignment superfluous:

// first case analyzed without brackets(function(){

// do stuff

}());

In this case we are clearly creating a closure to avoid global space pollution and to perform some useful operation.Since this is basically what we can find almost everywhere in many different libraries or piece of libraries, and since we have some shortcut to instantly reach the end of a file, why should we put the inline invoke outside the operation?

// first case analyzed without brackets(function(){

// do stuff

})();

The sequence of )() could suggest that something happened before and somehow it constrict us to check if there are other 2 round brackets before those spotted at the end.Furthermore, if we have an expression this is what we could write:

var something;

// other code

(something = function(){

// do stuff

})();

Again, unless we did mean that operation, maybe to avoid IE problems with named function expressions, those brackets outside the "wrap" could truly be considered ambiguous: was I trying to assign the expression result or the function itself?

something = (function(){

// do stuff // return stuff

}());

There we have again a clear statement of what we were planning to do, isn't it?

Anonymous Assignment

We could think about some common pattern we can consider less error prone, and less ambiguous ... the first one is the classic assignment, performed for prototype properties, to avoid IE problems, or simply assign callbacks:

something = function(){};

Inline Invoke

We may agree that next one is the bets way to make an inline invoke non ambiguous:

something = (function(){}());

Same is if we are not returning anything, so that the expression will be called simply because we need a closure:

(function(){}());

Inline Constructor

This is not truly such common technique, but there is a massive difference if we use brackets or not.

As Summary

Earlier, I found the initial advice kinda redundant or superfluous, but I must admit it could make sense specially in weird cases, and this is why I have personally started to adopt it without feeling less readable at all.Is there any other case where we could try to avoid expression ambiguity?

Monday, March 08, 2010

I am very busy these days with my last (hopefully) moving into my new and completely empty rented flat ... and while I am building home utilities and preparing my last post about A Better JS Class, with some extra case where common libraries fail with their parent implementations, I would like to quickly share this require function I wrote days ago but just recently came back in front of my eyes.

Why require

In CommonJS we have different techniques and agreement about how developers should structure/organize their namespaces and libraries.The first common function adopted from CommonJS "followers" is the require one. This function aim is to load once, and runtime, a namespace, allowing scripts loaded via this function to define exported properties/variables or methods/functions.

Above piece of code fit into about 350 bytes once minified, less than 260 bytes gzipped ... sweet, isn't it?Bear in mind if we need a root, we can simply add it via require.root = "./my/js/path"; without last slash after the final folder (e.g. require.root="." to load from the current one).

YAGNI In Details

For those unable to understand the acronym, YAGNI simply means "Ya ain't gonna need it".The YAGNI behind my proposal could be summarized in this way:

server side frameworks have their own native require, no need to fully replicate it, it's already there

simply Ajax, if the browser does not load via other protocols and you are testing, enable file: via about:confing/strict or the local support for XHR

the most used case is the one we all know, require function will be there, as global one, and module object is not yet important (CommonJS is constantly updated as well)

A well organized namespace will improbably affect object properties (e.g. Object.prototype["my.name.space"] does not make much sense). No need to use hasOwnProperty, specially not the object itself one, since Object.prototype.hasOwnProperty could be redefined without problems and most probably this is an edge case more dangerous than the prototype["my.long.namespace"]

All these points are better considered in another version I did not know, the one from David Flanagan.In any case, we should consider this valid point of view about require and JavaScript client, from Lucas Smith.At least now we have more alternatives in the field, with this one that should simply bite others at least for size, and for common case reliability.Enjoy!