My favorites | Sign in
Project Logo
                
Code license: MIT License
Show all Featured downloads:
vice-versa.0.1.4b.min.js
People details
Project owners:
  andrea.giammarchi

vice-versa project

every browser has some good feature: it could be performances, it could be something "not standard yet", it could a feature ready for ECMAScript 5. vice-versa project aim is to bring good stuff from every browser into a single, cross-browser, lightweight, JavaScript file.

Philosophy

Array.forEach(document.all, function(node, i, all){
    // vice-versa project
});

As a JavaScript Ninja I have to deal on daily basis with hundreds of different problems because of "this or that" browser implementation. The Web is loads of libraries but too often what we need to do is "out of the box" and these libraries could help, or simply they could slow down our application performances because of unnecessary overload over common or simple tasks. Studying the DOM, which is notoriously a mess, I often "travel" between the MDC and the MSDN to solve a specific trouble which could cause a lot of headaches because of "some" missed W3C implementation. At the same time, bearing in mind that the most used browser is the one with the slowest JavaScript engine, I always try to find out solutions able to complete a task without killing performances. In most of the cases, I simply realized that since other browsers are fast and more powerful, it makes sense to bring some not standard functionality inside these browsers rather than implement, when it is possible, a missed functionality in Internet Explorer. As basic example, to convert an XML document into a string, we would like to use an XMLSerializer instance, but what is that wrong with Microsoft xml attribute shortcut?

// other browsers way
var xmls = new XMLSerializer;
var string = xmls.serializeToString(myXMLDocument);

// Internet Explorer way
var string = myXMLDocument.xml;

Moreover, document.evaluate is amazing stuff, but the most common call to this function is this one:

var xpresult = document.evaluate(XPathSelector, myXMLDocument, null, 0 /* as ANY_TYPE */, null);

In internet explorer we have a slightly different function: selectNodes

var xpresult = myXMLDocument.selectNodes(XPathSelector);

The main difference is number of character used to call the standard method rather than IE one, with a completely equal result during iteration where IE nextNode has the same meaning of other browsers iterateNext. Again, if we are in Internet Explorer we can rely in the most ugly property we have ever seen since first JScript implementation over the DOM: document.all. Now, why on earth we love YUICompressor plus gzip "miniaturization" but we prefer a meaningless syntax like this:

document.getElementsByTagName("*")

rather than

document.all

?

The list could go on with execScript to evaluate code in a global scope (both Ajax and runtime related) and Object.defineProperty, but at the same time we have lacks over the Array.prototype since ages, something kinda boring because of the global constructor prototye which should be "untouched" for compatibility reasons ... it's time to understand that nobody performs a for in loop over list or collections, so Array.prototype has to be standardized, there's no "maybe" or "perhaps", secially now that it has been implemented as standard in ECMAScript 5. As summary, these are concept inside vice-versa project: where it is possible to implement another interesting browser behavior, that will be part of the vice-versa project, specially if these behaviors could slow down general application performances, or these behaviors are not standards!

vice-versa features from Internet Explorer

vice-versa features mainly for Internet Explorer

vice-versa features ECMAScript 5

vice-versa extra features

vice-versa goals

More is coming, hopefully under 10Kb of total minified and gzipped size (les than 4 right now), this is just a partial implementation of my original idea. Third parts libraries will be welcome, contributors from other libraries team more than welcome and go on ... the main idea is to create a full hybrid of the JavaScript scenario making performances similar for every browser and providing a low level framework to build up complex libraries, applications, other, respecting where it is possible Internet Explorer, and bringing its features inside other fast and powerful browsers. Am I that insane?









Hosted by Google Code