How To Map Your Code

Most of the tools we use on daily basis to develop applications with any kind of programming language need to understand our code in order to help us while we are writing, reading, or creating code.
We open an editor, we read highlighted code, we like suggestions when we write a dot and we use compilers, minifiers, compressors, obfuscators, converters, documentation generators ... but have we ever though about the program behind our same program? Have we never thought that highlights, suggestions, minifications, and syntax analyzer do not come for free and these are primordial programs we've ever used often without even realizing we are using it?
This post is about general suggestions, techniques, and practices, used to map code. In this specific case, we will analyze step by step the logic behind a code mapper using the most used programming language in the world: JavaScript.

Map VS Tokens

First of all we need to understand what we need. A Map could be considered a generic list of coordinates able to tell us "what is where" while a tokenizer is usually an extremely detailed map with extra info, where everything is deeply analyzed and hopefully never casual, as a map could be.
Every programming language has an interpreter, and usually an interpreter is able to analyze the syntax and create tokens to use runtime or to compile the language into another one (byte/machine code). As metaphoric example, the world is an open source application and we, nature and animals included, are tokens, then everything is part of a global application.
So far, services such Google Map, are applications able to map the world. Google Map does not (yet) care about our role in the system, it simply tells us what/who is where. Silly metaphors a part, being global tokens analysis much harder to perform, this post will talk about the simple way: the generic Map, but if interested, and again via JavaScript, we could have a look into Narcissus, a good old Mozilla Project able to analyze JavaScript via JavaScript itself.

Time To Start Thinking About The Problem

OK, everything seems so easy for human eyes ... we take a string, we recognize what is where, and that's it! Easy! Specially with an highlighter able to make code lecture a pleasure, isn't it?
Well, we'll see that things are not that simple as we think, and that is why historical projects such Scintilla are still under development.

What We Are Interested About

As I have said, JavaScript will be the reference language but problems and techniques are similar for every other.
The first requirement to understand is what as what are we looking for. In JavaScript case, we can split the language in these main cases:

• strings, we cannot touch them!
• literal regular expressions, untouchable as well
• comments, we may consider to get rid of them
• E4X, damn cool XML as is, again untouchable
• everything else, considered code

For above categories, we could slit them in sub categories:

• single quoted strings
• double quoted strings
• single line comments
• multiline comments

So far, we have just decided what will be our map about, and nothing else. Now it's time to think how to implement this map.

The Basic Problem: Who Comes First

Somebody could think:dude, what's the fuss man, just search via RegExp and that's it... and no it's not.
This is a classic case where everything could go wrong, included your favorite JavaScript editor, but still perfectly valid syntax:

// ... code

var theWeirdCase = /"['//*"]'/;

// other code ...

Uhm, check that out, a regular expression with a string "['//*" inside plus another intersected string '//*"]' plus a single line comment // plus the beginning of a multiline one /* ... well done, surrounded by code, that case, reproducible with every combination with a string and a regexp inside, a comment with a string inside, etc etc, could fuck up all our parsing plans, isn't it?
So rule number one: understand what part of the map is more relevant, where in this case, relevance is defined by who comes first.
If we have whatever inside a string, whatever IS inside a string.
If we have whatever inside a literal RegExp, whatever IS inside a regexp.
Same is for E4X or comments, single or multi line, whatever will be part of that comment. Does anybody agree?

Char By Char VS Regular Expressions

OK, here we are, let's define the best strategy to analyze code, right? Char By Char could be the easy way to analyze code: it's simple to implement, we feel like we have control over every single char, we can spot who comes first without problems or errors, isn't it?
Regular Expressions are simply abstracts and clever char by char parsers. We delegate tedious code to the RegExp engine which aim is to understand the expression, and gives us the match, if any. Regular Expressions are somehow similar, conceptual speaking, to SQL: we type Maya and Egyptians characters and magically we obtain the result, without caring at all about lower level layers.
I can still spot the dude ... guy voice saying:
mate, I am not a noob, if RegExp are char by char parsers, my char by char parser will be faster for sure.
This time the dude guy is not completely wrong but as usual, it depends.
If we are programming with C, C++, or heyholetsGo!, without considering better suited programing languages for this purpose such Caml or OCaml, Regular Expressions will require a library with such overload for generic purpose that maybe we can do better and faster for the specific case.
On the other hand, all we know about programming is that less is better and if we can trust extremely tested and famous regular expression engines (PCRE) why on earth we should waste time writing whatever specific case parser which aim will be the same of a RegExp?
And why on earth we think our check/test/verify implementation will be more stable than a short, quick, and dirty RegExp?

JavaScript Is Not As Fast As C Is

Thanks to competitors and new strategies to manage JS dynamic code, performances are often faster even than PHP, Ruby, Python (not Iron or C-) but JS cannot compete with lower level languages compiled directly into machine code and without dynamic nature.
Rather than explain in 3 hours why char by char is not always worth it with JavaScript, here I am with a test anybody can try and with every browser.

// commented to avoid problems with highlight used
// n this blog, an old char by char parser ;-)

// PLEASE REMOVE NEXT COOMMENT CHARS "//" TO TEST

// var theWeirdCase = /"['//*"]'/;
var aLongString = new Array(150001).join(".") + theWeirdCase;
var i = 0;
var skip = false;
var time = [new Date];
var position = [(function(){
    var length = aLongString.length;
    var mlc = aLongString.indexOf("/*");
    var slc = aLongString.indexOf("//");
    var sqt = aLongString.indexOf("'");
    var dqt = aLongString.indexOf('"');
    var rex = aLongString.indexOf("/");
    if(mlc < 0)mlc = length;
    if(slc < 0)slc = length;
    if(sqt < 0)sqt = length;
    if(dqt < 0)dqt = length;
    if(rex < 0)rex = length;
    var position = Math.min(mlc, slc, sqt, dqt, rex);
    if(position === length)position = -1;
    return position;
})()];
time[i] = new Date - time[i];
time[++i] = new Date;
position[i] = (function(){
    for(var
        position = -1, c = 0, length = aLongString.length;
        c < length; ++c
    ){
        switch(aLongString.charAt(c)){
            case "'":position=c;c=length;break;
            case '"':position=c;c=length;break;
            case "/":
                if(c < length - 1){
                    switch(aLongString.charAt(c + 1)){
                        case "*":position=c;c=length;break;
                        case "/":position=c;c=length;break;
                        default:position=c;c=length;break;
                    }
                }
                break;
        };
    };
    return position;
})();
time[i] = new Date - time[i];
try{aLongString[0]}catch(e){skip=true};
if(!skip && aLongString[0] === "."){
    time[++i] = new Date;
    position[i] = (function(){
        for(var
            position = -1, c = 0, length = aLongString.length;
            c < length; ++c
        ){
            switch(aLongString[c]){
                case "'":position=c;c=length;break;
                case '"':position=c;c=length;break;
                case "/":
                    if(c < length - 1){
                        switch(aLongString.charAt(c + 1)){
                            case "*":position=c;c=length;break;
                            case "/":position=c;c=length;break;
                            default:position=c;c=length;break;
                        }
                    }
                    break;
            };
        };
        return position;
    })();
    time[i] = new Date - time[i];
};
time[++i] = new Date;
position[i] = aLongString.search(/\/*|\/\/|'|"|\//);
time[i] = new Date - time[i];

alert([
    time.join("\n"),
    position.join("\n")
].join("\n"));

Above benchmark try to replicate common techniques to find a single piece of the full map, in this case over about 150Kb of fake JavaScript code.

How To Read The Benchmark

dude ... the benh confirm that ... shut up! The bench shows that Regular Expressions are the fastest way to parse code via JavaScript. It does not matter if the score could not be the fastest in above case, what matters is that with a single Regular Expression we can grab 0, 1, or every match in the code.
If we think that in 150Kb of code to highlight showed time will increase for each mapped part in the same code, while the regular expression could be just one, we can easily see that:

• the RegExp is able to find and validate at the same time what we are looking for, above benchmark misses all manual validations we need to do to understand if the case, first found char a part, is exactly the one we where looking for
• with a single regular expression we save a large number of characters and the code is easier to maintain
• for each manual parsed char we need to perform a manual check for the exact case, the total amount of manual checks increase with number of chars and code complexity
• with a single regexp we don't care that much about code size because the engine, hopefully written in C, should be fast enough to be able to parse a large amount of data

We Still Need Good Regular Expressions

This is the most critical part, if we use bad regular expressions we could have a lot of false positive and we could mess up the map. The reason Regular Expressions are not always well considered, is that these could be hard to read, write, or understand, and people could put "chars around" without improving anyhow the regexp, adding more false positives instead. I do not pretend to give you best regular expressions ever for all cases, but it's since 2000 I am using RegExps and hopefully I know a chicky bit about them.

JSMap.parser = [
    // WebReflection Suggestion
    {
        test:/\/\/[^\1]*?(\r\n|\r|\n)/g,
        type:JSMap.COMMENT_SL,
        place:function(value, a){
            return value.charAt(2) === "@" ? value : a;
        }
    },{
        test:/\/\*[^\1]*?(\*\/)/g,
        type:JSMap.COMMENT_ML,
        place:function(value){
            return value.charAt(value.length - 3) === "@" ? value : JSMap.parser[0].place(value, "");
        }
    },{
        test:/(["'])(?:(?=(\\?))\2.)*?\1/g,
        type:JSMap.STRING
    },{
        test:/\/(?:\[(?:(?=(\\?))\1.)*?\]|(?=(\\?))\2.)+?\/[igm]*/g,
        type:JSMap.REGEXP
    },{
        // Note: experimental, not fully tested/supported
        test:/<>[^\1]*?(<\/>)|<(\w+|\{\w+\})(?:\s*\/|[^\>]*?>.*?<\/\2\s*)>/g,
        type:JSMap.E4X
    }
];

Above collection contains all kind of things we would like to Map for JavaScript.
Some object contains a place method which aim is to avoid, if necessary, the match replacement. In this case I have considered Internet Explorer conditional comments and nothing else, but there are other cases where a comment should not be removed (e.g. /*! my license */ )
Each object contains a map type, 'cause we would like to know what we have found there, don't we?

JSMap.CODE      = 1;
JSMap.COMMENT_SL= 2;
JSMap.COMMENT_ML= 4;
JSMap.STRING    = 8;
JSMap.REGEXP    = 16;
JSMap.E4X       = 32;
JSMap.ALL       = 63;
JSMap.DEFAULT   = ~JSMap.E4X;

Since we are creating a customizable map, we would like to choose what we want to find or not. We can decide using some bit operation.
As we can see, the default one exclude the E4X case, it's not common, since it has not been implemented yet in every browser, plus for this post and example is not perfect.
To exclude something all we need to do is to use ~ char, while if we want to decide just few thing we can always use the or | :

JSMap.COMMENT_SL | JSMap.COMMENT_ML

Above example will look for single and multi line comments. Maybe we want just understand if there is some conditional comment?
In cany case, bear in mind that who comes first is still the main problem, so if we restrict the searh we could find false positives (e.g. comments inside strings or regexps)

How To Logically Proceed With The Mapper

OK, we have reduced code size already 1/3rd thanks to god regular expressions. Now what's next?
The problem is still the same: Who Comes First!
For each performed Regular Expression we should store results somewhere. In this case we will have 4 searches performed via RegExp for the entire code, rather than a check for each possible matched character, but false positives could always be there.

function JSMap(CODE, type){
    if(!type)
        type = JSMap.DEFAULT
    ;
    for(var
        Map = [],
        length = JSMap.parser.length, i = 0,
        a, b, exec, parser, value;
        i < length; ++i
    ){
        parser = JSMap.parser[i];
        if(parser.type & type){
            while(exec = parser.test.exec(CODE)){
                value = exec[0];
                Map.push({start:exec.index, end:exec.index + value.length, value:value, type:parser.type});
            };
        };
    };
    // ... the rest of the code

OK, looping over the list of RegExp we have collected every match.
Each match has been stored as an object where properties are:

• where the match start, we can reuse start and end info regardless for other purposes
• where the match end
• the match itself, alone could be reused or simply replaced in the current CODE
• the match type, what we have found

Start and end are valid for every match and compatible with substring.
If for some reason we will change a single value and its length will change, we can easily synchronize the Map adding or removing the difference between old length and the new one for every other mapped objects after the current one.
these properties could be superfluous but we want control for any kind of occasion.

An Ordered Map Without False Positives Collisions

The simplest way to reorder the map is a native Array.sort operation, perfect to understand who comes first!

Map.sort(function(a,b){
    return b.start < a.start ? 1 : -1
});

The start point is the sort key and thanks to Regular Expressions we will rarely have same start point. If we have one, we need to rethink the RegExp because it is not good enough since, for example, a comment cannot be a regexp and viceversa.
The native sort operation is hopefully fast enough to guarantee still better performances. All we need to do now is to add, if necessary, the code.

Cleaning Adding Surrounding Code

Once we have mapped all we were looking for, we can consider CODE everything before, in between, or after our matches.

// type could NOT include CODE
// and if code starts with a comment, there
// is nothing to do ...
if(type && 0 < (i = Map[0].start))
    Map.unshift({start:0, end:i, value:CODE.substring(0, i), type:JSMap.CODE})
;
// every other Mapped case will be ordered by start
// Accordingly, the first start we will encounter
// will be the valid one ... the first match
// will be considered valid by dafault (var a)
for(length = Map.length, i = 1, a = Map[0]; i < length; ++i){
    b = Map[i];
    switch(true){
        // if there is a gap between the
        // precedent a match and b one
        // there MUST be code between
        case a.end < b.start:
            // let's add it if we need
            // continue otherwise
            if(type){
                Map.splice(i, 0, {start:a.end, end:b.start, value:CODE.substring(a.end, b.start), type:JSMap.CODE});
                ++length;
                ++i;
            };
        // if there is no gap or code
        // has been inserted
        // we can go on with the for loop
        // considering the current b
        // valid, assigned for this reason to a
        case a.end === b.start:
            a = b;
            break;
        // if there is no gap
        // which means next match starts
        // before a.end and no after
        // we have a false positive
        default:
            // remove this match in any case
            Map.splice(i, 1);
            --length;
            --i;
            break;
    };
};
// if the last match ends before the string.length
// there must be another piece of code to add
if(type && (i = Map[i - 1].end) < CODE.length)
    Map.push({start:i, end:CODE.length, value:CODE.substring(i, CODE.length), type:JSMap.CODE})
;

Finally, if there is no match but JSMap.CODE is part of the search, we can consider the entire string a piece of code:

Map.push({start:0, end:CODE.length, value:CODE, type:JSMap.CODE})

How To Use A Map

Almost the end of this tedious post. Once we have created a map of our code, we can reuse matches in any way we prefer.
This is a "paste and go" example that will let us test whatever code we want:

/**
 * JSMap test case
 */
onload = function(){
  document.body.appendChild(
    document.createElement("textarea")
  ).onchange=function(){
    var time    = new Date,
        Map     = JSMap(this.value/*, JSMap.CODE|JSMap.COMMENT_ML|JSMap.COMMENT_SL|JSMap.REGEXP*/)
    ;
    time = new Date - time;
    if(!Map.map)Map.map=function(fn){for(var i = 0, length = this.length; i < length; ++i)this[i]=fn(this[i]);return this};
    document.body.innerHTML = 'Mapped in ' + (time/1000) + ' milliseconds.<pre>' + Map.map(function(o){
        var value = o.value.replace(/</g, "&lt;").replace(/>/g, "&gt;");
        switch(o.type){
            case JSMap.STRING:
                value = '<span style="color:#66F">' + value + '</span>';
                break;
            case JSMap.COMMENT_SL:
                value = '<span style="color:#999">' + value + '</span>';
                break;
            case JSMap.COMMENT_ML:
                value = '<span style="color:#F66">' + value + '</span>';
                break;
            case JSMap.REGEXP:
                value = '<span style="color:#F00">' + value + '</span>';
                break;
            case JSMap.E4X:
                value = '<span style="color:#00F">' + value + '</span>';
                break;
            default:
                // eventually we can parse
                // the code with numbers
                // spaces, keywords, methods
                // and whatever we need
                // that would be another Map
                // specific for the language
                // or simply a replacer via RegExp
                break;
        };
        return value;
    }).join("") + '</pre>';
  };
};

Save in an html page, paste some valid code into the textarea, disabling spell check if the source is massive, and click somewhere outside the area.

Conclusion

Even if the case is JavaScript and a JavaScript map, with this post we can hopefully better understand problems behind generic code parsing.
What is missing in this post is a code parser able to highlight or understand every piece of code present in the map.
If we loop over the returned map it is possible to understand which one is code and what is next. If a variable is going to be assigned to a regexp or string, as example, the value will be found in the next object present in the map.
I did not consider numbers 'cause these are simple to parse in a code portion, while these could slow down every other operation since these could be easily spotted inside strings, comments, regexps, or E4X syntax.
Considerations, techniques, and benchmarks, are relative for this case but generally valid for any kind of purpose. CSS selectors, HTML, and other cases, need to consider when Regular Expressions are worthy (e.g. not that fast char by char parser due to used programming language) and when a simple indexOf could be the best solution ever. I hope you enjoyed this post, I surely did writing it since the argument is not that frequent and techniques extremely different (and trust me, I have showed maximum a 30% of what we could fnd out there).
Oooops, I almost forgot the JSMap source code!

Literal Regular Expression Safe Regular Expression

... sorry for the redundant title but that's exactly what is this post about ... after yesterday explanation about problem, logic, and solution, to grab valid strings inside JS code, here I am with the literal RegExp able to grab literals RegExps in a generic JavaScript code.

Why Do Not Add Just A "/" Into Other Strings RegExp

One comment gave me the hint to write this second post about RegExps. While time is a bit over during days, this answer is simple, but not obvious!
Differences between strings and literal regular expressions are basically these:

• there must be at least one char, or the parser will consider the literal RegExp an inline comment //
• the slash does NOT necessary need to be escaped. If we have a slash inside a range [a/b] the latter one won't break the RegExp and the slash will be considered just one valid char in that range
• there could be one or more chars after, where i(ignore case), g(match all), and m(multi line) can be present one or more times

Latter point is not truly a problem since this syntax will break the code in any case:

function igm();
var a = "string"igm();

But still, we need to understand first couple of points.

The RegExp Safe Regular Expression

// WebReflection Solution
/\/(?:\[(?:(?=(\\?))\1.)*?\]|(?=(\\?))\2.)+?\/[igm]*/g

Since yesterday after 10 seconds somebody pointed me another solution, I bet this will happen again but so far I have tested above little monster enough to say that should work without problems but obviously only if the code is valid, otherwise we don't even need to waste our time trying to parse it.
As example, yesterday somebody told me:look, it does not work with this

a = \"string"

Well, now consider that an escaped char could be everywhere in the code but again, these regular expressions are not code sanitizer, n any case improbable since:

// tell me what do you expect and WHY!
a = "string\"
b = \"other"
\"
" c = what?!"

So any kind of weird combination wont work but if the regular expression is valid, escaped or not escaped, the precedent solution should work like a charm.

Explanation

I won't go step by step for the entire RegExp this time, things are the same described in my precedent post so please read there if you want to know more. The emulated look-behind pattern has been included in this regexp to skip groupd of possible ranges present in the regexp. When a range is encountered, starting with char "[", it is skipped till the end. If there is no end theoretically the literal RegExp is broken and the code won't execute. Same strategy is used for the other case, where no [ is encountered, if there is a char followed by a slash, we go on as described in the other post. In this way we should be sure that whatever will be, we'll find the end of the RegExp included chars. I did not spend too much time ensuring consistency for these flags since "/whatever/ii" will be part of inconsistent code which is a syntax parser problem, and not mine.

Test Cases

//comment <-- should not be matched at all
var a = /a/;
var b = /\//i;
var c = /[/]/;

I bet there are hundreds of RegExp or minifier out there able to fail with the latest one, since even different Editors have problems trying to understand what is going on.

The Test Case

Same code I have posted yesterday, except the alert will be for all arguments. I know I have used an empty replace, which is a bad practice, but that was good enough for test purpose:

onload = function(){
  document.body.appendChild(
    document.createElement("textarea")
  ).onchange=function(){
    this.value.replace(
      // WebReflection Solution Test
      /\/(?:\[(?:(?=(\\?))\1.)*?\]|(?=(\\?))\2.)+?\/[igm]*/g,
      function(){
        alert([].slice.call(arguments).join("\n"));
      }
    );
  };
};

Please let me know if you find a better solution or whatever gotcha via the test case, considering that arguments[0] should be exactly the matched RegExp, thanks.

P.S. about the inline comment, it's not worth it to avoid that case for two reasons: we can always test that match.charAt(1) !== "/" plus the problem is still: who comes first? If we have a string inside a regexp or vice-versa there is no way to exclude these cases in a single, reasonable, RegExp. As I have said, as soon as I'll find some time, I will explain how to create a proper function able to manage all JavaScript cases, stay tuned!

String Escape Safe Regular Expression

I should have probably investigated more but apparently I did it ... the most problematic I've encountered so far with JavaScript RegExp seems to be solved!

Update

Indeed, I should have investigated ... I just like to find solutions by my own. I am not surprised somebody already investigated this classic parsing problem.
Steve talked about it a year ago, using the lookbehind missed feature I talked in this post.
Above post has much more details than mine (and much more Edits as well).
The good part I am happy about is that both me and Steve came out with basically the same solution, but His one is definitively more compact:

// Steves Levithan compact solution
/(["'])(?:(?=(\\?))\2.)*?\1/g

The assumption of above regexp is that if there is a char followed by an escape one, there must be another char that cannot be the initial single or double quote, being the latter one outside the second uncaptured part, and after a non greedy operation.
If the second condition, \2, does not exist, the dot "." will pass the current char, no escape found, performing the char by char parsing I have described in my solution.
The dot is my [^\\], the double escape is represented by "\2.", as is for the escape plus whatever else that is not the end of the string, equivalent of my [\\(?=\1)]\1
I don't want to edit lots ot times this post, and I'll leave it as is to let you understand the problem, the logic, and the solution.
The only thing I would like to check are performances, since my less compact solution should be theoretically faster for common strings where the escape char is not present while Steve one will try to look for the escape plus will assign the possible missed match plus will pass whatever else char after, if any, considering outside there is a "break", and all these operations for whatever length, and still a char by char operation.
Whatever will be, we know we have at least two alternatives, and both mine and Steves one should be cross browser.

A Bit Of History

In all these years of programming with different languages, I have created dunno how many code parsers. WebReflection itself is using one of these parsers to highlight my sources. My good old PHP Comments Remover (2005 though ...) used another code parser. MyMin project used another one as well ... in few words, in my programming history I don't know how many times I had to deal with sources. The strategy I have always adopted, specially for JavaScript, is the char by char parser. The reason is simple, I have never created or found a good regular expression able to threat this case:

var code1 = "this is some \"test\"\\";
var code2 = "and this is \"anot\\her\" one!";

Above code, managed as a string, will become a stringe like:
"var code1 = \"this is some \\\"test\\\"\\\\";
var code2 = \"and this is \\\"anot\\her\\\" one!\";"
And if you know Regular Expressions, you know why this case is not that simple to manage isn't it?
Well, right now I was forking a project with a massive usage of Regular Expressions for CSS selectors and I could not avoid to notice the classical wrong match to manage strings:

/['"]([^'"]*?)['"]/g

Above match is almost a non-sense. If we have a string such "told'ya!" that RegExp will match told', leaving "ya!" out of the game. To make it a bit better the classic procedure is this one:

/(['"])([^\1]*?)\1/g

Whit above RegExp we are looking for quote or double quote char and we are searching the next one being sure if the first match is a single quote, the string will finish with a single one, and viceversa. There is still the problem that if we have the first matched quote or double quote and an escaped one in the middle of the string, that regular expression will truncate again the latter one giving us a untrustable result.

Why It Is More Difficult Via JavaScript

Regular Expressions in JavaScript miss at least one of most common features in PCRE world: the look-behind assertion!
Fortunately, we have an helpful Backreferences able in some case to slow down the match, but often the only or best way we have to create more clever matches!

The String Escape Safe Regular Expression

// WebReflection Solution
/(['"])((?:[^\\]|\\{2}|[\\(?=\1)]\1|[\\(?!\1)])*?)\1/g

I am not sure above little monster is the best RegExp you can find for this problem, and JavaScript features, what I am sure about, is that I have done dozen of tests and results seems to be perfect: Hooray!!!
If you are not familiar with RegExp, please let me try to explain what's going on there:

/
  // look for a single or a double quote char
  // this will be referenced as \1 in the rest of the regexp
  // in order to completely ignore the other one
  (['"])

  // the second match is performed over the string
  // that could be empty, or it could contain
  // any character included the first match, if escaped
  (

    // the second match will be a char by char parser
    // the only character we are worried about
    // is the one able to escape the first match
    (
      ?: // we are not interested about next capture
      // since the only scary char is the escape
      // but it is not necessary present
      // (let's say is less present than any other)
      // speed up the RegExp validating every char
      // but the escape ... these are all good!
      [^\\]
      |
      // if we encounter an escape char and this
      // is escaping itself we can skip 2 chars
      \\{2}
      |
      // alternatively, we could have
      // an escaped match (current one: single or double)
      // in this case we want to be sure that the escape
      // is for the matched char and not just an escape
      [\\(?=\1)]\1
      |
      // we need to validate whatever else has been
      // escaped as well so if the escape char is
      // NOT followed by the initial match or
      // another escape char it's ok
      // and we go on with next char
      [\\(?!\1)]

    // precedent cases should be performed for each
    // encountered char but these cannot be greedy
    // otherwise we risk to wrap the full string
    // var a = "a", b = "b";
    // 'a", b = "b' <-- greedy!
    )*?
  )

  // to make precedent assumptions valid
  // we need to be sure the string terminates
  // with the initial matched char
  \1
/g

That's pretty much it, if we use match method, replace, or exec, the matched[1] or RegExp.$1 will be the char used to encapsulate the string, single or double quote, while matched[2] or RegExp.$2 will contain the string itself.

In Any Case It Is Still Not Perfect

If we consider JavaScript regular expressions, same stuff used to solve the problem, we'll have another one.

var re = /ooo"yeah/;
var s = "no way";

In above example there will be some problem since the double quote inside the regular expression will be matched like a charm with my suggestion.
This is the reason we still need char by char parsers but hey ... I was trying to parse some selector and the usage of @test="case" which is even apparently not standard, so bear in mind we cannot use this RegExp unless the code won't contain literal regexps.
What is the trap here? That char by char a part, it's quite impossible to decide who comes first, "the slash or the quote"?

Quick And Dirty Solution Tester

With this code it should be simple to copy and paste some valid source to read parse after parse what is OK and what is not:

onload = function(){
  document.body.appendChild(
    document.createElement("textarea")
  ).onchange=function(){
    this.value.replace(
      // WebReflection Solution Test
      /(['"])((?:[^\\]|\\{2}|[\\(?=\1)]\1|[\\(?!\1)])*?)\1/g,
      function(){
        alert([arguments[1], arguments[2]].join("\n"));
      }
    );
  };
};

Please share whatever problem you'll find with such Regular Expression or suggest me a better faster approach to solve this problem with same test cases, thanks.

Google Closure ? I'm Not Impressed

We all know that Google is synonym of performances, simplicity, and again performances. A search engine that uses a truncated body for a not valid W3 markup should be the most bytes and performances maniac in the current web era, isn't it?
Well, Google Closure Tools has been a negative surprise, at least this is what I can tell about it after a first quick review.

Closure Compiler

It's since ages I am wondering what kind of tool Big G is using to produce their scripts and finally we got the answer: Closure Compiler ... ooooh yeah!
Packer, YUIC, it does not matter, when Google needs something, it creates something. This is almost intrinsic, as developers, in our DNA: we spot some interesting concept? We rewrite it from the scratch pretending we are doing it better!
This is not the case, or better, something could go terribly wrong!

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// ==/ClosureCompiler==

(function(){
   "use strict";
   this.myLib = this.myLib || {};
}).call(this);

myLib.test = 123;

The produced output:

(function(){this.a=this.a||{}}).call(this);myLib.test=123;

And 2 warnings:

JSC_USELESS_CODE: Suspicious code. Is there a missing '+' on the previous line? at line 2 character 4
"use strict";
^
JSC_USED_GLOBAL_THIS: dangerous use of the global this object at line 3 character 4
this.myLib = this.myLib || {};
^

Excuse Me?
The sophisticated compiler is able to understand the "use strict" ES5 activation statement and the fact we are passing the global object as this reference in the closure. It does not matter, as showed in the produced code the result will be a broken library, thanks to its missed name, magically transformed into "a".
Advanced Optimization Could Fail to both give us right suggestions and fix or optimize the code, since in that case, as example, this.a won't perform anyhow faster than original this.myLib.
Advanced Optimization parameter could also be dangerous for lazy loaded libraries.
We need to be extremely careful with this option and, as result, rather than a Compiler, we will deal with a "code messer" where hard debug will become automatically the hardest ever.
Read Carefully This Page if you are planning to use this option because under the flag "best ratio" and "removed dead code" we could have massive surprises in the middle of the application.

As summary, SIMPLE_OPTIMIZATIONS as compilation_level directive is so far the recommended one, but at the same time it won't offer that different ratio compared against YUI Compressor or Dean's Packer (NO base62) produced outputs while ADVANCED_OPTIMIZATIONS could be tested for single stand alone files hoping these won't break the global namespace via renamed variables.
In this case a JavaScript closure, the real one, is an absolute must!

Closure Library

This is another part, not strictly related with the Compiler, but apparently able to work with it. The Closure Library is a wide namespace loads of core features and a cross browser User Interface. I have to admit this library is a massive piece of work, but techniques used to make it happen are often hilarious.
First of all, this is the first time I read protected variables called with an underscore at the end, rather than as first char:

// normal code
function Constructor(){
    this._protected = [];
};

// Closure Library Creativity
function Constructor(){
    this.protected_ = [];
};

Why On Earth? Python style a part, where the underscore has a concrete meaning, the technique to use underscore as first character has a reason to exists.

function copyOnlyPublic(o){
    var $o = {}, k;
    for(k in o){
        if(k.charAt() !== "_")
            $o[k] = o[k]
        ;
    };
    return $o;
};


var myC = new Constructor;
var $myC = copyOnlyPublic(myC);

No Way! To make the style "creative" the charAt method with optional 0 as argument needs to become:

if(k.charAt(k.length - 1) !== "_")

Is this what we would expect from the performances king? I don't think so.
Is this faster to read at least for human eyes? Neither!
Gotchas are everywhere in the library ... the most redundant stuff I've ever seen is the array namespace!

goog.array.indexOf = function(arr, obj, opt_fromIndex) {
  if (arr.indexOf) {
    return arr.indexOf(obj, opt_fromIndex);
  }
  if (Array.indexOf) {
    return Array.indexOf(arr, obj, opt_fromIndex);
  }

  var fromIndex = opt_fromIndex == null ?
      0 : (opt_fromIndex < 0 ?
           Math.max(0, arr.length + opt_fromIndex) : opt_fromIndex);
  for (var i = fromIndex; i < arr.length; i++) {
    if (i in arr && arr[i] === obj)
      return i;
  }
  return -1;
};

OMG, I can't believe performances matter only for a missed body tag in the layout ... it cannot be real, can it?
What we have there? 1 to 2 possibly missed checks for each call (IE) and everything just to emulate the native Array.indexOf which is present in basically every browser except truly old or Internet Explorer?

goog.array.indexOf = Array.indexOf || function(arr, obj, opt_fromIndex) {
  var fromIndex = opt_fromIndex == null ?
      0 : (opt_fromIndex < 0 ?
           Math.max(0, arr.length + opt_fromIndex) : opt_fromIndex);
  for (var i = fromIndex; i < arr.length; i++) {
    if (i in arr && arr[i] === obj)
      return i;
  }
  return -1;
};

Array.indexOf is used as fallback if for some unknown reason (and browser...) an Array has not indexOf but Array.indexOf is present ... well, if we can trust that case is there any valid reason to create a performance gap like that for almost every method?
forEach, lastIndexOf, every JavaScript 1.6 or greater emulated method contains redundant checks performed for each call ... where is the performance maniac here?
The feeling is that this library has been created by some Java guy, probably extremely skilled with Java, but definitively not that clever with JavaScript programming style. Google if you need skilled JS developers there are hundreds of us out there. What I mean is that it does not matter if a minifier is able to remove dead code because dead code should not be there at all, isn't it?

// WebReflection Suggestion
goog.array.clone = (function(slice){
try{slice.call(document.childNodes)}catch(e){
    slice = function(){
        var rv = [];
        if(this instanceof Object)
            // suitable for arguments
            // and every other ArrayLike instance
            return rv.slice.call(this)
        ;
        for (var i = 0, len = this.length; i < len; ++i)
            rv[i] = this[i]
        ;
        return rv;
    };
};
return function(arr){
    return slice.call(arr);
};
})(Array.prototype.slice);

Above suggested snippet is based on Features Detection, a technique apparently completely discarded in those files I've read in this library.

Features Detection Cons

• performed runtime, few milliseconds before the library or function is ready to use

Features Detection Pros

• performed once, and never again for the entire session
• best performances, browser independent and browser focused at the same time
• being usually based over most recent standards, features detections could cost a bit more only for deprecated, obsolete, or truly old browsers

Moreover!

If the problem is the wasted millisecond to perform a feature detection, we can always fallback into lazy feature detection.
I agree that web performances are more about download time and round trip, but if Google has V8 as engine monster, do we agree that better JavaScript practices could make even V8 faster?

Lack Of Creativity

Even if this library uses some weird practice, most logical and common techniques to speed up execution and reduce code are often not considered. As example, this is just one method we can find in the crypt file:

goog.crypt.byteArrayToString = function(array) {
  var output = [];
  for (var i = 0; i < array.length; i++) {
    output[i] = String.fromCharCode(array[i]);
  }
  return output.join('');
};

Oh Really? So now a JavaScript developer should create a function which accept an array in order to create another array to populate over a loop and a global method call to perform a join at the end? That's weird, I thought that method could have been written in this way:

// WebReflection Suggestion
goog.crypt.byteArrayToString = function(array) {
  return String.fromCharCode.apply(null, array);
};

... but maybe it's just me that noob that I cannot spot the difference except better performances over less code ... please enlighten me!

Closure Library, The Good Part

Is massive, for basically each file there is a test case so it is robust. For sure as we have seen before, this is not the fastest general purpose library we could find in the net, something I was expecting from Big G, but hey ... we cannot blame the excellent work done so far, can we?

Closure Templates

Well, here I am almost without a word ... I mean, the number 1 search engine able to create monster pages via JavaScript templates? I do hope those files will be performed everywhere but a web page and runtime, 'cause with incoming HTML5 I feel horrified thinking about a new web loads of document.write and nothing else. Where is the semantic? Where is the logic applied before and not during execution? Where are best practices? Looking at examples even V8CGI project is not able to perform that code ... what is that, exactly? And WHY???
The only thing I do like there is the definition file, something simple, clever, easy to parse, exactly the opposite of its implementation via JavaScript: please avoid it!

Closure Conclusion

No this is not another piece of the puzzle, just the end of this post. I've been probably too aggressive and it's only thanks to Google decision that I can write a post like this: Open Source is the key, or your libraries, operating systems, whatever, will be always behind 'cause developers able to help you are not only in your team.
I was expecting excellent ideas, new killer techniques unknown for everybody else, what I have found is "yet another toolkit". I am always up to contribute so if interested put my name in the committers list, I have already lot of stuff to optimize because a Compiler, whatever it does, cannot create a better code, it can simply try to make a bit better and shorter the existent one: never delegate skills to a machine until these will be able to take decisions for us!

Android DOM "Finger" Events

This is the Android based device I am talking about and the installed software is version 1.6, apparently with multi-touch support for more recent devices so mine is not the case.

Disclaimer

The reason I am writing this post is my attempt to reproduce the Android OS interface via browser, hilariously possible with every browser except the original one: the WebKit in Android.
Why would I do that? The mouse has been around for ages, thanks Xerox, but later these years we've seen so many touch screen based devices without common mouse pattern. Since I think both Android, iPhone, and others, have done an excellent work with the way we use the device UI I thought: Why not! It could be a great time to start analysis and piece of libraries to replicate in a cross browser way some device independent event. Well, as I've already said, and as you'll see next, right now it is not possible!

Mouse Events .. ahem, Finger Events

Every mouse related event we know does not make much sense with a touchscreen, at least the tested one. Think about it: a finger points something (aka: mousedown) move somewhere (aka: mousemove) remove the finger itself (aka: mouseup). This is not what truly happens.

Mouse Events Order

• mouseout, optionally fired when point if before we pointed another element
• mouseover, optionally fired if the pointed event is different (or no elements have been pointed before)
• mousemove, always before mousedown, sometimes fired twice if the internal cursor is in position 0,0 - this event is not performed while we move the finger!
• mousedown
• mouseup
• click, which is so far the only event that makes sense
• DOMActivated, a common WebKit "bug"

Mousemove Events ... Whatever ...

Fired events are device dependent, my device fires these events just in order but whatever we change in the DOM wont be called/rendered until we release. Mousemove is fired once, maximum twice, but never during movement.
In few words the only "mouse event" that makes sense is click, not performed if we scroll.

Forget The Drag And Drop!

Even if the most interesting part of the Android interface is the drag and drop, via WebKit mobile we cannot even try to emulate it just because the only event fired while we move the pointer is scroll.

Scroll ... Whatever ...

This event could be considered just a notify and nothing else. If we do whatever action while we scroll a page nothing will happen until we release the pointed element. Accordingly we cannot use the element to synchronize somehow the rendered page since again, nothing will happen during the scroll. The phone browser is basically frozen during the entire lifecycle of a gesture, or a pointer (via finger) operation.

(window || document) // it does not matter
    .addEventListener(
        "scroll",
        (function(i){
            return function scroll(e){
                // it's a waste of time
                // to perform whatever
                // action here
                // let's speed up things
                // adding delay
                if(i)
                    clearTimeout(i);
                i = setTimeout(function(){
                    i = 0;
                    onScroll();

                }, /* about */ 250);
            };
        })(0)
    )
;

Above snippet represents a delayed onScroll event which aim is to be performed faster without slowing down the page while we are scrolling.
I know this could sound a nonsense but operation will be performed in any cases but never rendered so why should we let our phone compute stuff will never be showed?
Also a scroll could be not perfect, since the mouse wheel won't be there and a pointer has 10 pixels of tolerance so just wait the end of the action, and only at that point perform something.

Resize

Both window or document, no difference in this case, will always perform a resize event. This is the last reliable event we have so far in a G1 device.

Drop Down Menu Not Worth It

Common JavaScript drop down menu usually activated via mouseover and removed on mouseout won't work as expected in common touchscreens while if we implement a "clever" click manager Desktop users will be a bit disoriented 'cause we failed implementing these menus everywhere just because these are strictly device pointer dependent, so not re-adaptable/usable at all.
Moreover, a finger is not a mouse and it's more complicated to click the right menu/link at first shot. We need to rethink a little bit the UI if our aim is to make a website usable, without having 2 versions to maintain, with both desktop and mobile or touchscreen.

As Summary

We have basically 3 events, and few others, such onload, DOMContentLoaded, focus and key related for inputs, but these a part other events won't necessarily act as expected.
We need to bear in mind that mousemove or mouseover/out are quite meaningless since there is no mouse and no sensor able to monitor the finger activity when close to the screen. iPhone implemented a touch event but still, touch does not allow drag and drop so if we would like to emulate the Mobile OS interface via the Mobile Browser, we simply cannot: what a joke, but that's how it is.

Node sourceIndex for every browser

I was doing a couple of tests in my bloody Android and I don't even know how I ended up with such snippet ... anyway, accordingly with @ppk table sourceIndex is a node property compatible with every version of Internet Explorer and latest Opera browser but not with Chrome, Firefox, or Safari (WebKit Android and iPhone as well).

Being these unsupported browsers compatible with both native Array.prototype.indexOf and __defineGetter__ and being 5 to 100 times faster than IE, I thought: why don't put this as well into vice-versa?

/** sourceIndex by vice-versa - Mit Style License
 * @target  FireFox, Safari, Chrome
 */
if(typeof document.documentElement.sourceIndex == "undefined")
    HTMLElement.prototype.__defineGetter__("sourceIndex", (function(indexOf){
        return function sourceIndex(){
            return indexOf.call(this.ownerDocument.getElementsByTagName("*"), this);
        };
    })(Array.prototype.indexOf));
;

I so much would have cached the live getElementsByTagName("*") object then I thought there must be a reason if different libraries pass via node.ownerDocument rather than direct document ... isn't it? Well, if not I'll change soon but right now I am pretty much happy with performances :)

Why sourceIndex

If we would like to know, as example, if a node is before or after another one (considering that nested nodes will be considered always after their container) I bet there's nothing simpler than:

if(a.sourceIndex < b.sourceIndex){
    // move up b, move down a
} else {
    // move up a, move down b
}

... or something similar, enjoy

Update
Apparently in jQuery dev list somebody already talked about analogue snippets (thanks @diegoperini) but it's not my idea to normalize anything, respecting what sourceIndex should do: compare index in the full HTMLCollection and nothing else, the rest could be easily implemented over this snippet :)

JavaScript For In Madness

Have you never instinctively written a for in loop like the next one, instantly correcting it since you need a variable to perform it?

for(var k in {oops:null}){
    // cool, got "k" here ...
    // now how do I get
    // the bloody "oops" value?
}

This quick post talks about above nonsense case providing a solution I will explain only if anybody will be interested about it, since (I am quite lazy and tired right now and ...) I think I've been able to solve the trick using almost every JavaScript bad practice :D

Runtime Assigned For In Loop

(function(self, Function){
// Another (C) WebReflection Silly Idea
"use strict"; // Mit Style Weirdness
var $o;
self.o = function o($){
    if(!$)
        self.o = $o;
    else {
        $o = self.o;
        self.o = Function(
            "$", "return function o(" +
                new Array(($.length || 0) + 1).join(",k").slice(1)  +
            "){return $(arguments[0])}"
        )(o);
        for(var k in $)
            self.o[k] = $[k]
        ;
    };
    return $;
};
})(this, Function);

WTF Is That

Above agglomerate of dynamic assignments/compositions let us perform a forIn without creating (virtually speaking) a variable. How?

for(var k in o({a:"b", c:"d"})){
    alert([k, o[k]]);
};

In few words we don't need to define the "o" object in any place. The trick works as expected with blocked properties, as length is for a function, name, and whatever else was assigned to the object and even nested

for(var k in o({
    length:123,
    name:"test"
})){

    alert([k, o[k]]);

    // nested for in ...
    for(var k in o({a:"b"}))
        alert([k, o[k]])
    ;

    o(); // back in town parent object

    alert(o.name); // test
};

Isn't it cool? Even with Arrays!

for(var k in o([1, 2, 3])){
    alert([k, o[k]]);
    // 0,1
    // 1,2
    // 2,3
};

The good part is that break will work as expected and the changed object is quite static since it is a function, looped over original object properties.

Why This Abomination

Well, let's say with let and var we can do what we want in a generic for loop but we are kinda stuck with a single variable with a "for in" one.
What would be truly nice in my opinion is the possibility to implement this kind of syntax:

for(var o = {a:"b"}, k; k in o){
    // common loop with o and o[k]
};

Something similar to PHP world where we have:

foreach(array('a'=>'b') as $key => $value){
    // do stuff and forget about the config variable
}

I am pretty much sure JavaScript will never implement above syntax but hey, that's why I have created a monster I'll probably never use in my programming life :P

The main trick about supported length property is described in this post.

DOM Node Proxy

This is just a quick post from home sweet home.
A common DOM related problem is to create an association between a node and a generic object. The most dirty, memory leaks prone, and obtrusive way to perform this task is this one:

document.body.obj = {
    prop:"value",
    otherProp:function(){}
};

Above snippet is a bad practice for different reasons.

1. obtrusive, it's assuming that no other libraries will use "obj" property name to perform an analogue task
2. dirty, if we associate a primitive value Internet Explorer will expose it in the node string representation
3. memory leaks, if the object points something "live", another node, or a HTMLCollection, the generic node will never be collected by the garbage

Alternatives

Specially to avoid last problem, the memory consumption, it's a good practice to store an index, rather than an object. To make things less obtrusive and get rid of conflicts, we usually create a "unique id".

// the array with all objects
var stack = [];

// the unobtrusive property name
var expando = "prefix" + new Date().getTime();

// the obejct to relate
var o = {};

stack.push(o);

// the relation via index (last object)
document.body[expando] = stack.length - 1;

As I have already linked and explained, this technique is still dirty because Internet Explorer will show the unique id via outerHTML or generic node representation.

Strategies

jQuery, and many others, create an association for each manipulated dom node. This could consume RAM without a reason since there could be a lot of nodes with an associated object that will never be used.
Next version of jQuery, right now in alpha stage, understood this point changing the object association logic. I have not read how yet, but I would like to write something I've been used for a while, a sort of proxy object created for DOM nodes and object relations.

DOM Node Proxy

var proxy = (function(){
    // another (C) WebReflection silly idea
    var expando = "@".concat(+new Date, Math.random()),
        stack   = []
    ;
    return function proxy(){
        return stack[this[expando]] || stack[
            this[expando] = new Number(stack.push({}) - 1)
        ];
    };
})();

Above snippet uses almost all strategies I know to avoid obtrusive property, dirty layout, and direct object assignment (index strategy).
To better understand what exactly is above function I have commented each part of it:

var proxy = (function(){

    // another (C) WebReflection silly idea

    // one function to associate as proxy
    // Being assignment a direct one
    // standard browsers won't modify
    // attributes while being proxy
    // an object (not primitive value)
    // IE won't expose it in node string
    // representation (e.g. outerHTML)
    function proxy(){

        // a proxy call costs only once:
        // the first time it's called
        // Other calls will return the object
        // This is to avoid objects association
        // even if these are not necessary
        return stack[this[expando]] || stack[
        
            // the index is the last one in the
            // private stack Array. To avoid
            // leaks we don't associate directly
            // an object but simply an integer.
            // If we directly associate
            // a primitive value, IE will expose
            // is in the dom string representation
            // (e.g. outerHTML)
            // To avoid this we can just assign
            // a Number instance, rather than
            // a primitive "number"
            this[expando] = new Number(
            
                // push returns the new length
                // we need last inserted object
                // index to relate the object
                stack.push({}) - 1
            )
        ];
    };

    var
        // private unique expando with
        // an  invalid char as prefix
        // in order to make attr name
        // easy to recognize in a possible
        // IE attributes loop
        expando = "@".concat(
            +new Date,
            Math.random()
        ),
        
        // list of associated object
        stack   = []
    ;

    // ready to go!
    return proxy;

})();

Is it clear enough? This is a simple usage example (please reado NOTEs):

onload = function(){

    // associate a proxy
    // NOTE: this is still obtrusive
    // the property name should be a unique id
    // or it should have library prefix
    // otherwise we could have conflicts
    document.body.proxy = proxy;
    // aka: node[expando] = proxy;

    // retrieve the proxy object
    var p = document.body.proxy();

    // test proxy: true
    alert(p === document.body.proxy());

    // test clean body string representation
    alert(document.documentElement.innerHTML);

    // find proxy created property
    for(var k in document.body){
        if(k.charAt(0) === "@")
            alert([k, document.body[k]])
        ;
    }
};

As Summary

This is more a proof of concept but I hope showed code will help us to replicate the behavior. The main missed part is the internal stack management: how can I clean the stack index when I don't need the node anymore? All we need is an extra in-proxy-scope function or a specific associated instance rather than a raw object.
In ew words there are no best strategies for this second problem, it just depends what we need.
From a logical point of view, if we give indirect access to that stack, exposing its length or via functions able to modify it, stack safety could be compromised. What I could suggest is something like:

var proxy = (function(){
    // (C) WebReflection - Mit Style License
    function proxy(){
        return stack[this[expando]] || stack[
            this[expando] = new Number(stack.push(new $proxy) - 1)
        ];
    };
    function $proxy(){
        this._index = stack.length;
    };
    $proxy.prototype.destroy = function destroy(){
        delete stack[this._index];
    };
    var expando = "@".concat(+new Date, Math.random()),
        stack   = []
    ;
    return proxy;
})();

where the stack is manipulated indirectly while nothing is publicly exposed.

Internet Explorer Scope Resolution

I have enclosed in only 5 steps JScript weirdness, hoping all precedent deliriums about functions, standards, and Internet Explorer, will make more sense now.

Here there is the link to original HTML slides, I hope this will help everybody to have clearer ideas.

Named function expressions demystified III

Update For those interested about Internet Explorer scope resolution, I summarized everything in 5 slides.

---

This is hopefully the end of the Named function expressions demystified trilogy, where here you can find episode I, and episode II.
Juriy knows I am hard to convince, but apparently he is not better than me at all ...

Inglorious Correction

Sure, it's better than nothing, but after I have spent dunno how many tweets plus 2 posts, all I have obtained is a small correction in the whole article (and you have to scroll a bit before):

Generally, we can emulate function statements behavior from the previous example with this standards-compliant (and unfortunately, more verbose) code:

  var foo;
  if (true) {
    foo = function foo(){ return 1; };
  }
  else {
    foo = function foo() { return 2; };
  };

  // call the function, easy?
  foo();

Above snippet is the best solution in the entire article but probably to avoid my name in article credits, and it does not matter since I have already said it's not about the copyright, and surely to avoid personal ego conflicts, the suggested one is a surrogate of above snippet, quite embarrassing from a developer point of view, isn't it?

  var f; // create an alias, WHY!!!!!!!!!
  if (true) {
    f = function foo(){ return 1; };
  }
  else {
    f = function foo() { return 2; };
  };

  // create a reference in order to remove a reference, WHY!!!!!!!!!!!
  var foo = null;

  // call the function via another alias, WHY!!!!!!!!!!!
  f();

Above snippet is just a surrogate because the first one simply create an alias which will refer the proper function. Let's be simply developers avoiding obtuseness, OK?

Re Solution Pros

1. it's standard, no excuses at all!
2. variables on top, no way we can forget to nullify the function and we don't need to create a reference which aim is to remove a reference, cause the reference is already assigned, no memory problems at all (possibly less, since there is nothing referenced to a null value)
3. semantic, we can easily refer to the function, since the whole point is to solve the missed arguments.callee plus IE inconsistency ...
4. standard again, because it perfectly emulates ECMAScript 3rd Edition behavior even in Internet Explorer
5. the day we will need to nullify the function will be the day we meant it, and not a surpassed convention

Why My Re Solution Is More Standard

This is the expected behavior in all browsers, except Internet Exlorer and Opera, via Internet Explorer emulation:

  var f; // let's use the suggested alias
         // for demonstration purpose
  if (true) {
    f = function foo(){
        // this is LOGICAL
        // but in IE it will be false
        // because foo will be the 
        // the other one, even if that
        // else will never be executed!
        alert(foo == arguments.callee)
    };
  }
  else {
    // IE will declare this function
    // in any case since there is NO DIFFERENCE
    // between expression and declaration
    f = function foo() { return 2; };
  };

  f();

With my Re Solution the behavior is the expected one, alert(foo == arguments.callee) will be true in every browser ... do you still have doubts?

Re Solution Cons

1. unfortunately, more verbose

This must be a joke ... more verbose? First of all we are dealing with developers that don't care at all about verbosity. Kangax as everybody else in credits always preferred verbosity since minifier and compressor could take care about this verbosity recreating, and I love the irony of this part, exactly the suggested case.

Re Solution Pros II

1. being the function name declared on the top of the function, as I have said a well known good practice, every IDE will automatically suggest that name as soon as we'll startt to type it: does verbosity matter?
2. As we all know gzip and deflate compresses repeated words more efficiently, as result the Re Solution is even smaller if we don't munge it, does verbosity matter?

Re Solution Is More Logical And Smaller

Here the simple test everybody can do. Two pages, same code, except the first one is Re Solution, 99 bytes, while the second one is Juriy suggestion, 111 bytes.

<?php ob_start('ob_gzhandler'); ?>
var foo;
if (true) {
    foo = function foo(){ return 1; };
}
else {
    foo = function foo() { return 2; };
};


<?php ob_start('ob_gzhandler'); ?>
var f;
if (true) {
    f = function foo(){ return 1; };
}
else {
    f = function foo() { return 2; };
};
var foo = null;

Do we have a single valid reason to use the Juriy suggestion over mine? I would honestly feel an idiot preferring the second one, since few bytes and more logic (foo is the function foo) against spread variables declarations (top and the middle with F = null) via aliases rather than function names inside the function itself where a debugger will show the name but we have to remember the alias, plus the possibility we forget to nullify the reference consuming more memory ... I mean, this is not the first of April, isn't it?

And That's Not All Folks

We are developers, not monkey, I always dislike generic affirmations a la eval is evil, the most used function since Ajax epoch, obviously included in json2.js itself, since is natural and logical to use it when necessary. Juriy corrected his article to underline how unprofessional am I suggesting a last option for IE behavior ... well, probably he has never thought about ternary assignment, isn't it?
// Never do this!, that's what I can read at some point, but we should think carefully before these statements.
Here there is an example where the function will be a named one but there are no differences in this case for IE, indeed the last option is the IE one.

// somewhere in a closure ...
// (otherwise add will be public in IE,
// but I hope we went further than this
//  at this point and after 3 posts
//  plus an entire article ...)
var event = {
    add:document.addEventListener?
        function add(){
            alert([add, document.addEventListener]);
        }:
        function add(){
            alert([add, document.attachEvent]);
        }
    ,
    del:document.removeEventListener?
        function del(){
            alert([del, document.removeEventListener]);
        }:
        function del(){
            alert([del, document.detachEvent]);
        }
};

In one shot we have created a unique add reference, a named function, plus the right one for the event object. Now guess what's up if we invert the order putting the IE version at the end ... add will be the last option ... the one with addEventListener, got the point?

As Summary

I am pretty much sure I'll be criticized again and only for the last part of this post where obviously things work but somebody will argue about future IE9 sci-fi behavior or stuff like that ... well, that day my library will be deprecated in any case and, if needed, it's easy to implement over my Re Solution

var event = {
    add:(function(add){document.addEventListener?
        (add = function add(){
            alert([add, document.addEventListener]);
        }):
        (add = function add(){
            alert([add, document.attachEvent]);
        }); return add
        })()
};

Now let's see if the most interesting analysis about functions expressions and declaration will keep ending up with the wrong suggestion, rather than mine ... kinda curios, still hopeful though.

ES5 and function default scope

This is just a quick one. One of the worst decision about ES5, after the one to remove arguments.callee when "use strict" is present, is the missed default reference to the global object. Probably the most secure trick to retrieve the native window in JavaScript is this one:

// wherever we are
var global = function(){return this}();

// while window, could be simply a variable
// assigned somewhere else in this scope

I have already talked about this, and I am still against some ES5 "feature" which aim is probably the one to make JavaScript as fast as possible, regardless all code that will break if "use strict" is present in the generic scope.

Another non-sense is to allow a this in a context where there is no this. Rather than an error, ES5 will point refer this to undefined.
Are you kidding me? this is a special keywords related to the context and you are telling me a context is undefined? so I guess open(), as example, should throw an error there, since window cannot be implicit in an undefined context, isn't it? ... anyway, fortunately the whole problem could be quickly solved in this way:

// ES5 problem
(function(){
"use strict";

this === undefined; // true ... LOL!!!

})();


// WebReflection QAD solution
(function(){
"use strict";

this === window; // true ... yeah baby!

}).call(this);

This simple modification could avoid lots of headaches plus could avoid scope resolution for every window variable.

It's probably quite obvious but I can already imagine lots of people changing the whole function body rather than add a call at the end :D

The trick to retrieve the global context won't work in any case for nested functions, unless we are not sure that this points to window, but being the trick goal the one to make window resolution quick and safe, there is not window,self,top, whatever check that could solve the problem (unless [].sort() will be still buggy ...)

As summary, the day JavaScript will be that fast thanks to removed dynamic and run-time features, it won't be JavaScript anymore but another language a la ActionScript 2 when ActionScript 1 was enough, and the problem was the player rather than the language, which indeed has been replaced by ActionScript 3 even if the problem is still the player and not the language, since it can be compilable into old versions.

Named function expressions demystified II

Update If after this reading things are still the same, please read the part 3 of this post, thanks.

---

I have been criticized just for fun and in a impulsive way without analysis or tests (I am not talking about Juriy who gently replied with interesting points in the part 1 of this post - and I replied back).
First of all, if the purpose of an article is to describe a behavior and provide a solution, there should not be any challenge or run for the copyright ... we are developers, and we want the best solution, for us and others, if this solution has been published.

Specially for a complicated language as JavaScript is, Virtual Machine and cross browser troubles speaking, is really difficult, sometimes impossible, to find the ultimate and perfect solution, so let's keep the argument in a professional way, agree?

What Is Wrong With Juriy Solution

Somebody does not get it, and it could be my fault. So this is about inconsistencies, and I'll show you Juriy code to avoid any kind of misunderstanding, OK?

  var fn = (function(){

    // declare a variable to assign function object to
    var f;

    // conditionally create a named function
    // and assign its reference to `f`
    if (true) {
      f = function F(){
          // now try to create a setTimeout here
          // assuming we need it

          // error, there is no F reference
          // anymore in this context.
          // This function obviously exists and
          // the entire point is to find a solution
          // to replace arguments.callee
          // so do you think is a good design
          // we cannot use the function name
          // with every browser?
          setTimeout(F, 1000);

          // insted we have to use another name
          // but there is NO REASON to do this
          // if you understood my precedent post
          setTimeout(f, 1000);

          // so the purpose is to make function
          // call possible via name and the solution
          // is to do not use the function name
          // am I the only one spotting
          // inconsistency here?

          alert(f == F); // FALSE
          // because F was the last option
          // and F has been referenced to null
      }
    }
    else if (false) {
      // same as above
      f = function F(){ }
    }
    else {
      // same as above
      f = function F(){ }
    }

    // Assign `null` to a variable corresponding to a function name
    // This marks the function object (referred to by that identifier)
    // available for garbage collection
    var F = null;

    // NO, this does not mark anything
    // this is another layer in JScript
    // the function exists, as exists the last one
    // if we are nullify a reference, the garbage
    // will discard the function because not
    // referenced ANYWHERE in this contest
    
    // This behavior is EXACTLY THE SAME
    // if we have last option callback
    // in IE since the last function reference
    // will be the only one, then other functions
    // will be collected

    // Moreover, with "Re Solution"
    // the function is trapped in the reference
    // where the reference HAS THE SAME NAME
    // this means we have THE FUNCTION NAME
    // as valid one in the current scope
    // NO ALIASES, and garbage is fine


    // return a conditionally defined function
    return f;
  })();

Re Solution

To keep best compatibility the last option could be a bit messy in Opera or old Safari. That is why I have suggested my Re Solution.

  var fn = (function(){

    // declare the FUNCTION NAME we want to use
    var F;

    // conditionally create a named function
    // and assign its reference to ITS NAME
    if (true) {
      F = function F(){
          // EASY!!!
          alert(F == arguments.callee); // TRUE
          setTimeout(F, 1000);
      }
    }
    else if (false) {
      // same as above
      F = function F(){ }
    }
    else {
      // same as above
      F = function F(){ }
    };

    // In this cotext there is
    // ONE AND ONLY ONE
    // reference to function F
    // being the reference evaluated
    // AFTER function declaration
    // It does not matter if 
    // there are other functions
    // with the same name because
    // the reference, which comes after
    // WILL POINT TO THAT FUNCTION
    // which is a named one

    // EASY ???
    return F;
  })();

As Summary

I hope things are finally clear for everybody. I hope Juriy will get my point, and I am always ready to negate everything I wrote as soon as somebody will demonstrate it is wrong. Again, we are developers, there's no trophy here if we want make something public for developers community.

Named function expressions demystified

Update If after this reading things are still the same, please read the part 2 of this post, thanks.

---

This is a re-post, and few considerations, about the good Juriy article, which I suggest for every JavaScript developer with a deeper knowledge than just an API (jQuery or others).

Github For Everything!

My first consideration is about github, something I've never used that much since via Google Code I feel pretty comfortable with subversion. I find truly interesting the way Juriy is tracking his documentation, I've never thought about an article, as my old JavaScript Prototypal Inheritance could be, in a code repository as kangax did: good stuff!

My Alternative Solution

There are few extra consideration to do over Juriy explanation, plus minor inconsistencies. The first thing is that Internet Explorer basically manages Function expressions and Function declarations in the same way, there's no such VS in the middle.
The fact we assign the function to a whatever named variable does not make any difference:

alert(F); // (function F(f){/*IE Function*/return f})

F((function F(f){/*Function Declaration*/return f}));
F((function F(f){/*IE Function*/return f}));

var f = (function F(){return F}); // <== which F?
function F(){/*IE Function*/};    // this one!

alert(f()); // function F(){/*IE Function*/};

We can play with above IE traps for ages but the point is simple: the last defined function with that name, will simply take the place of the other one, if any, in the same scope, and at the end of its resolution, before code execution.

What IE does is basically a top-down parsing over functions without taking care at all about code execution or normal and expected syntax execution flow.
This simply means that return whatever, var whatever = function whatever(){} ... does not change anything for our loved IE:what we see or what we expect is not what will be, otherwise IE would have been a perfect browser.
To better understand what I am talking about, this example should speak for me:

var f = 123;
alert(F); // last function
(function(){
alert(F); // (function F(){alert(f);return arguments.callee})
var f = (function F(){alert(f);return arguments.callee})();
// undefined
})();
function F(){};

After these two snippets is quite logical understand this behavior:

1. scope resultion
2. function resolution plus optional inline assignment, if any, before next function resolution
3. code interpretation/execution over scope resolution

Accordingly with this Richard Cornford post, in JScript every function is performed sending the execution context, a behavior somehow similar to the injected context via eval in Firefox few months ago.
The latter one has been considered a security hole ... same kind of hole we need to deal with IE on daily basis every time we would simply chose a name for a bloody function.

My Solution

Juriy perfectly knows my point of view about this problem, he knows it so well that his addEvent solution example is created ad hoc to make mine inefficient (and I'll tell you later why).
It does not matter, as long as I can use the same example, avoiding IE4 support ...

var addEvent = (function(){
    var docEl = document.documentElement;
    if (docEl.addEventListener) {
      /* return */ function addEvent(element, eventName, callback) {
        element.addEventListener(eventName, callback, false);
      };
    } else {
      // IE has to be the last option
      // other addEvent will be "lost"
      // cause this will be the only named reference
      // in this scope ... 
      function addEvent(element, eventName, callback) {
        element.attachEvent('on' + eventName, callback);
      }
    };
    return addEvent;
})();

The key is simple, and is based exactly over same considerations and suggestions Juriy gives in the Alternative solution paragraph, except my suggestion uses an explicit last option callback, without requiring var this or that plus var this or that = null in any place, and for this purpose.

Indeed, for the same reason Juriy did not perform this task at the end of his latest suggestion and before the returned function:

if (typeof docEl.addEventListener != 'undefined') {
      attachEvent = addEventAsProperty = null;
      return addEventListener;
    }
    elseif (typeof docEl.attachEvent != 'undefined') {
      addEventListener = addEventAsProperty = null;
      return attachEvent;
    }
    addEventListener = attachEvent = null;
    return addEventAsProperty;

totally boring and absolutely anti pattern, on daily basis and real case scenarios, with my suggestion there is absolutely no need to remember to nullify variables used only to refer inline assignments and, moreover, only as Internet Explorer workaround!!! That's too much, I mean we have to change our code, change JS logic, to support such drama JS engine, we even need to write more and nullify everything? No way!

But It Could Be Inefficient

The only real side effect about my suggestion, surprisingly working in Safari 2 as well and solving its problems with names, is that if we have to deal with two different versions of IE in the same scope, we cannot use the "last definition" trick, 'cause one out of 2, 3, or 234567 versions of the most problematic browser since Web epoc, still Internet Explorer and JavaScript speaking, will mess up like a charm ... to be honest, IE4 days, the one without try catch and much more support, are far away from 2009, and I've never had to deal with such problem but in this case, there is nothing better, so far, than Juriy proposal.

Update
In my addEvent example Opera, thanks to its duality, will behave IE like. This is not a problem, since addEvent will work in any case, but we can return if we would like to force Opera with addEventListener (avoiding Safari 2 then). To solve this problem, when necessarym we can use the best from both proposal.

Re Solution

  var addEvent = (function(){
    var docEl = document.documentElement,
        addEvent;
    if (docEl.addEventListener) {
      addEvent = function addEvent(element, eventName, callback) {
        element.addEventListener(eventName, callback, false);
      }
    }
    else {
      addEvent = function addEvent(element, eventName, callback) {
        element.attachEvent('on' + eventName, callback);
      }
    }
    return addEvent;
  })();

Quite semantic, isn't it? ;)
The principle is still the same suggested by Juriy except there is nothing to nullify, just a reference to return, and being based on variable assignment, we can have 2345IE versions in the if else without problems at all.

As Summary

In Internet Explorer there is no difference between function expression and function declaration, this is the whole point of this post, plus the updated suggestion which makes things a bit more logical, from a developer point of view - addEvent is a well defined reference, and that's what we need.
The var F = null; in Juriy suggestion is useless for IE. References comes after, in the interpretation flow, while references come before in the execution one. var F = null; will nullify a reference, it won't mark anything for the IE garbage collector.
Juriy article is in any case a must read as soon as we understand JavaScript scope and lambdas, and specially if we would like to support multiple browsers.
Hopefully these gotchas will disappear with ES5 and the next "dreamed" IE9 with its totally new fabulous V8 engine ( OK, OK, ... let me dream please ... )
The day IE will disappear from browsers panorama I'll be the most happy and drunk web developer in the area but until that day, we can say the panorama is still weird, at least well explained, and with all possible solutions, we have choices!

devpro.it is down

As usual, when there is a merging or an acquisition, the classic "Dear customer, don't worry, everything will be just like before and even better" becomes automatically "Who are you, what'ya want from us, do we know each other? Re-buy the service if you have troubles!" ... in few words, devpro.it and 3site.it are down because there is no such thing anymore: the host! ... a little detail, that will be hopefully solved soon (next week at some point).
Fortunately, I have my backup, thanks to SQLite, actually version 2, which has maintained in performances and stability for years and hundreds of thousands of records both read only or constantly changed (counters, stats, code serving).

Maybe it's a good occasion to re-think devpro.it? Dunno yet, and time is zero, I am just sorry for any inconvenient caused by my different programming languages sources.

At least we can have fun with a classic video from The Web Site Is Down

NWMatcher - A Quick Look

As usual, as soon as I decide it's time to go to sleep, somebody :P has to post a stunning benchmark about a selector matcher ... did I shut down? No, I had to read the entire source code of the library, and this is my quick summary, but consider I am tired ...

NWMatcher, A Selector Monster

First of all, I did not know or remember this project and I must congrats with Diego Perini for different reasons.
The first one is that Diego used almost all best and unobtrusive technique to make it as reliable as possible, which is good, the second one is that Diego introduced something new to achieve its goal: create a Ferrari matcher via pre-compiled functions.

About NWMatcher

It is a lightweight stand alone library (so far, but already namespaced) which aim is to standardize some common DOM related task. The initial aim was to create a faster way to understand if a node matches a specific selector, something truly useful with event delegation.

About The Technique

To make things as fast as possible, Diego used a pre compilation strategy which is absolutely brilliant. Without XPath transformation, which is also not fully compatible with CSS in any case, and taking care of every single browser "gotcha", Diego creates once, and never again, the function able to perform selector related tasks. The result is that first call a part, with a new selector, the match method will perform a light speed!

This is the notable good part of NWMatcher, and now there's the bad one (not that bad in any case)

Few Inconsistencies

Except a weird procedure to understand if array slice could be performed over nodes, something I always got in 3 lines:

var slice = Array.prototype.slice;
try{slice.call(document.childNodes)}catch(e){slice=function(){
    // whatever to emulate slice for this scope
}};

Diego uses a callback to understand native methods from fakes. This is generally good, and this function is isNative, but since these kind of checks are for greedy developers with global pollution maniac, I cannot understand why at some point there is a root.addEventListener ? ... and no checks if addEventListener is native one, something that could make the entire caching system useless or able to generate errors. OK, that would be silly, I mean to inject an event like that, impossible to emulate in Internet Explorer, but who knows what a library could do with such event ...
Another inconsistency is about being unobtrusive, goal reached 99.9% ... what is that, a public property attached directly in the used context? We need to be aware that the document will probably have a snapshot, plus an isCaching property, not a drama, but I think those are the exception that confirm the rule.
Another thing I'll never get is the usage of new in front of functions which aim is to return a non primitive value.

function A(){
    return {};
};

Above function could be called with or without new and the result will be always the same, the returned object. This simply means that if we use new we are consuming CPU and RAM for no reason. So why a performances based library should not take care of this simple fact?

// example
function Snapshot(){
    // here this exists
    // and it has a prottype attached
    // and it has been internally initialized
    // to be used as Snapshot instance

    // we return an instanceof Object?
    // well done, so the garbage collector
    // has to consider this instance
    // which is a ghost instance, never used
    // but it has been created
    return {
        // whatever ...
    };
};

// let every comment inside the function
// make sense simply adding new
var snap = new Snapshot();

// a non-sense, imho, since this
// would have produced exactly the same
// without instance generations
var snap = Snapshot();

That's it. This stuff is really simple to get with C, C++, or those languages where we have to declare types, names, etc etc, and a new in front of a function is not transparent, is something to think about, cause a new is a new, we are asking for an instance, and a function able to return always another value, rather than the generated instance, shouldn't be called via new.

Diego, I am sorry, I am using this irrelevant gotcha simply because I wrote about these things dunno how many times ... please remove every new Snapshot from your code, or just use the instance, attaching proeprties.

Snapshot =
    function() {
        this.isExpired = false;
        this.ChildCount = [ ];
        this.TwinsCount = [ ];
        this.ChildIndex = [ ];
        this.TwinsIndex = [ ];
        this.Results = [ ];
        this.Roots = [ ];
    }

Makes sense? For performances reason, I still suggest to simply remove every new, leaving just Snapshot ... OK, that is probably more than I was planning to say ...

Mutation Events Side Effects

For compatible browsers NWMatcher uses mutations events such DOMAttrModified, DOMNodeInserted, and DOMNodeRemoved. The cache is partially arbitrary, activated by defaults, deactivated via setCache(false).
Mutations events are used to cache results. Why mutation events? Let's say in a single function is so common, specially in jQuery world as example, to search the same bloody thing hundreds of time ...

$("body").doStuff($whatever);
$("body").doOtherStuff($whatever);
$("body").doSomethingElse();

Above way to code is present in dunno how many examples, articles, books, and is as elegant as illogical. If we need a collection, I know we all like the $("thingy") style, but it's that difficult to write code such:

var $body = $("body"); // that's it, wrapped once, SPEED!
$body.doStuff($whatever);
$body.doOtherStuff($whatever);
$body.doSomethingElse();

I am sure it is difficult, and Diego knows this stuff better than me, indeed he is using result cache to avoid repetitive expensive searches over potentially massive structures as a DOM could be, in order to guarantee best returned results performances. So far, so good ... and mutations events, attached to the root of the DOM, the document, are able to clear the cache ... how? via a callback. Simple? Sure, it is simple ... but there is a little detail we should consider.

Nowadays, Ajax based Web applications are constantly muted, eachAjax call aim is to change something, show something, or remove something. With these perpetual changes whatever event is attached into a mutation event will be fired dozen of times but Diego, which is not the last JavaScript hacker, found a way to partially avoid this problem. He removes the mutation so the first fired one, will avoid same operations for other N times. This is good, but there is still an event to manage, internally, and a callback to call, but the bad part is that for each select, those events have to be reassigned, or checked, again (isCached attaced property).
Talking about performances, we need to consider the real case scenario, rather than a static benchmark over the same selection, or couple of selections, where nodes are, as I have said, constantly changed via innerHTML, innerText, appendChild, removeChild, insertBefore, insertAfter, all operations probably present in every single function of our JavaScripted page.

Now, is it truly worth it to cache results? Why, if it was the key, browser vendors are not caching results when we perform a getWhateverByWhatever or querySelectorAll?
Is our library truly that slow that a couple of searches performed consecutively are such big problem so we need to increase libraries complexities, side effects, and browser problems/behaviors, for something that on daily basis will be used I guess 5% of the time due to constant DOM manipulation?

Always Cached Matches

The brilliant strategy used to pre compile functions could be a bit greedy if used lots of time, over lots of different CSS queries, and for a long online session. What am I talking about? Mobile devices, a la iPhone with 2Mb of RAM limit, and all those lambdas stored in any case in memory. Is there any test about this? I'd love to see or create one, but I need a good iPhone web app before. Finally, this is just a hint, when the selector "*" is present, I think there is no point to parse anything or create the pre-compiled function. That return true in the body, should be enough, so in dozen of reg exp, I would have used a simple "*" check, and return just true. OK, talking about consistency, this is not a real case scenario, 'cause we have to be silly to know if a node matches "*" ... of course it will ... but what we should not forgot, at least in version 1.1.1, is that a node, not present in the DOM, will match "*" in any case, as is for every other match. This could be Diego aim as well, not sure WebKit and FF nightly behave the same, but I honestly don't think a non rendered element should match a CSS selector...

As Summary

NWMatcher is definitively the best answer I have seen so far to match a css. Diego experience is everywhere in the code, and people in credits gave good help and advices as well. I have been probably too strong about these few things I have spot in the code, but I am planning to use NWMatcher and to test it on mobile devices as well so the purpose of this post is: please, make it perfect Diego, and thanks a lot, truly good stuff!

Chrome Frame Options

As posted in Frame ML, twitted after (exactly 140 chars :D), and uploaded on my chromefix page, there is a new batch script file able to launch frame and let us clear, as example, the cache or perform some other operation.

start "Frame" /B "%PROGRAMFILES%\Google\Chrome Frame\Application\chrome.exe" "--user-data-dir=%APPDATA%\Google\ChromeExp\User Data\iexplore"

The reason this launcher could be useful is that apparently the cache used via Frame could be blocked and the user unable to clean it via common IE options procedure.
Enjoy, and thanks Tommi for the tip.

[Q&D] Fix Decimal Module Operator

This is a Q&D solution for some JavaScript precision problem when we use the module operator with floating point numbers.

The Problem

If we are dealing with the module operator we could have this case:

alert(
    8.25 % .05
);
// 0.049999999999999545 

We expected 0 but we have a floating point inconsistency instead. This is a well known problem, and not only with JavaScript, truly annoying when we have to show run-time computed money/trends operations.

The Solution

This comes from my reply in a JS forum, knowing that the module will be a simply floating point, let's say .1 to .001, if we remove floating point from the right side of the operation everything works just fine:

function mod(num, mod){
    // Another WebReflection silly idea
    var pow = Math.pow(10, (("" + mod).split(".")[1] || "").length);
    return ((num * pow) % (mod * pow)) / pow;
};

alert(
    mod(8.25, .05)
);  // 0


alert(
    mod(8.25, .1)
);  // 0.5

That's it, have a nice Sunday

Randomly Speaking ...

These days have been a bit chaotic, lots of news, good and bad, unfortunately somebody decided a day has only 24 hours and somebody else decided sometimes we need to sleep, so from 24 we pass to 18 ... this is a quick random post about changes and thoughts

I Am One Of The Ajaxians!

Thanks to Dion Almaer, or if you prefer "it's Dion fault!!!", I am glad to be one of those guys there talking about everything Web related, development, techniques, news, mobiles, whatever, as long as it makes sense and will keep us updated with the latest kill app.

Formaldehyde Has Been Updated

My simple Ajax / PHP debugger has slightly changed to solve a couple of annoying bugs. One was a typo, another one a new XHR feature (or better, limit) so theoretically, Formaldehyde should not caouse problems anymore.

The Real Problem Is Not IE6 But Windows 2000, 98, Me

Google Chrome Frame demonstrated that people want a better browser but there are still so many companies stuck in deprecated operating systems.
The most interesting analysis I could do is thanks to this reply in Frame ml:

Our company uses ALMOST 100% Windows 2000 OSes ... in our business, we always use a web application that uses a LOT of javascript, IE6 is Slow and always gets a javascript Error and needed the browser to restart.. the employees productivity
is continually monitored, this browser failures are a big problem.

Please let me summarize with a reply ...

Dear Companies

If your business is mainly based over a web/network architecture, the only one that will fall down day after day will be simply your business. An upgrade does not cost anything, and old PCs could install without any problems whatever free Operating System without slowing down your productivity making you, and your business, updated, 'cause the rest of the world and everything that works behind a browser is moving forward, so you are simply deciding to stay behind without a valid reason.
How can you justify slow productivity? How much this slow productivity, missed IE6 features, and an old, deprecated, application based over IE6, can mean for your incomes? Think!

The London JavaScript Group Should Survive!

This is the bloody Europe financial capital and one of the main IT center and nobody is interested into the programming language of the past, the present, and the future? This is unacceptable, is often thanks to JavaScript ignorance that our business is not that interesting as USA one ... with all those new thingy that "must be Flash or Silverlight!" while nowadays, 70% of the time, it is simply JavaScript!!! If I could have produced some silly stuff like the Liquid FX, guess how much JavaScript skills and knowledge could bring inside your on-line applications. Be interested, and do not follow Jurassic patterns a la "server side developer and just a web designer with jQuery knowledge", this is not enough for whatever start-up or whatever web based service.

TechHub Is Getting Started

This IS what I was expecting from this city when I moved here almost 2 years ago and not a dead JavaScript group ... ThechHub, finally some fresh air outside deprecated development models so loved in most of those companies fell down during the credit crunch ... Innovation is the key, everything that let us survive is wrong, everything that let us grow up, is good ... even in latter case, we could grow up even more, doing right steps, Think!

That's it, told'ya it was random ... have a nice week end if I won't have time to post again.