How to Use?

Not much has changed in the way of syntax from the previous version. The first argument accepts either the id of the element you wish to animate or the element itself. The second argument specifies the attributes of the animation, by defining the style and an ending value (“to”) and optionally a starting value (“from”) which otherwise defaults to the elements currently computed style:

var fx = new FX(el, {
    'font-size': {to: 14},
    'background-color': {from: 'FF0000', to: '0000FF'}
});

Additionally, you can optionally specify a duration (defaults to 0.7 seconds) as the third argument, the transition (brand new) as the fourth argument, and finally a callback method and the context you wish to execute the callback in as the fifth and sixth parameters:

var fx = new FX('element', {
    top: {to: 200},
    left: {to: 200},
    width: {from: 100, to: 200},
    height: {from: 100, to: 200}
}, 1.3, 'easeOut', callback, this);

The only method you need to concern yourself with is the start method, which starts the animation and requires no arguments:

var fx = new FX('element', {height: 400}});
fx.start();

That’s it! In just a couple of lines, you have the ability to animate any element any which way you want! What more could you ask for? I’d actually like to know!

CSS Multi-Unit Support

Brand new to the framework, FX now supports multiple CSS units for all scalable styles such as width and height. By defining an optional “units” property for each attribute you can specify which unit to apply to that specific style:

var fx = new FX('box', {
    width: {to: 20, units: 'em'},
    height: {to: 60, units: '%'}
});

Any and all CSS units are supported, including; em, pt, %, ex, in, mm, cm, and more. If no unit is specified for the attribute, it defaults to px.

Transitions

A feature promised and often asked for, FX now includes a much greater support for various transitional easing methods. Included in the library are your four basic transitions; linear, easeIn, easeOut, and easeInOut which is defined as an optional fourth parameter of the constructor, defaulting to easeInOut if not provided:

var fx = new FX('component', {
    opacity: {to: 1},
    left: {to: 300, units: 'ex'}
}, 1, 'easeIn');

In case that isn’t enough, you can also download the optional transitions pack, which adds an additional 30 transitions to the framework such as; quint, expo, circ, elastic, bounce, and many more!

Optimizations

Version two features over a dozen optimizations designed to improve performance, usability, browser support (still without a trace of browser sniffing), and overall efficiency. For you this means increased speed and a smoother animation.

Demo

To try an illustrative example of all the old features mixed with the new, click here. The example demonstrates multiple tweens against multiple styles using multiple units, and multiple transitions – all of which are randomly generated.

What’s Next?

The framework itself still has many different directions it can go, and I’m sure in time we’ll gain support for any and all features we’ve yet to attain. From here I hope to create additional functionality exclusively related to elements and element control, this including animation queues, delays, and a wealth of helper methods for effects such as fading, sliding, highlighting, motion, morphing, and many more. If you have any suggestions as to what you would like to see in upcoming versions, as always, I welcome your input and look forward to supporting this framework for a long time to come.

Download

• Compressed (5kb)
• Fully Documented (10kb)

Transitions

• Compressed (4kb)
• Uncompressed (5kb)

Since browser detection is entirely unreliable and unnecessary, we need to find something better. Therefore, we will instead test to see if the browser is capable of computing the style we are trying to determine support for.

In IE we can use the little known runtimeStyle object inherit to all elements in IE, it allows us to set the cascaded style (represented in currentStyle) which will override any and all other styling influences (stylesheets, inline styles, etc.) on the element. However we won’t be using runtimeStyle to set the style, but to check the value it holds to determine whether or not the style was properly computed. By simply examining the value held for the style in the runtimeStyle object, we find that it returns undefined for unsupported styles:

typeof el.runtimeStyle.width !== 'undefined'; // true
typeof el.runtimeStyle.opacity !== 'undefined'; // false

As for any standards compliant browsers, we check for support in a similar fashion; using the getComputedStyle method we can check to see if the style is capable of being computed/parsed. As with runtimeStyle in IE, only unsupported styles will return a value of undefined when we check the element’s computed style:

typeof view.getComputedStyle(el, null).test !== 'undefined'; // false
typeof view.getComputedStyle(el, null).minWidth !== 'undefined'; // true

Thats it! When we combine these techniques we get a robust method to detect CSS style support in all the mainstream browsers. Throw in some caching for increased performance against multiple tests of the same style and isStyleSupported is born:

isStyleSupported = (function(){
    var cache = {};
    var el = document.createElement('div');
 
    return function(style){
        if(style in cache){
            return cache[style];
        }else{
            var supported = false;
            if(el.runtimeStyle){
                supported = typeof el.runtimeStyle[style] !== 'undefined';
            }else{
                var view = document.defaultView;
                if(view && view.getComputedStyle){
                    var cs = view.getComputedStyle(el, null)[style];
                    supported = typeof cs !== 'undefined';
                }
            }
            return cache[style] = supported;
        }
    }
})();

Perfect right? Well not so fast, we don’t have to stop there, why not extend the method to not only determine support for styles, but assignable style values? Fixed positioning, currently not supported in IE6, can be a valuable style for UI components such as overlays, so how can we test for that? Rather than using browser detection or adding an event listener to dynamically reposition the overlay every time the user scrolls the window, we can just employ fixed positioning for those browsers that support it!

Amazingly, IE makes this quite easy using the technique we’ve already employed for determining style support. All we need to add is value assignment via the style object and wrap the test case in a try-catch block as IE will throw an error for unsupported style values.

However, if we are looking to determine support for the style values in standards compliant browsers, than getComputedStyle proves to be unreliable. Take for instance any number of scalable styles such as width and height, the method will always convert any units back to pixels, meaning a quick comparison would fail:

el.style.width = "1em";
document.defaultView.getComputedStyle(el, null).width; // 16px

In addition to that testing against unsupported style values will not always return a definitive result where as support can be easily determined. For example, setting an element’s color to an unrecognized value will always result in the return of the rgb representation of the color black:

el.style.color = "test";
document.defaultView.getComputedStyle(el, null).color; // rgb(0,0,0)

To quickly resolve this and avoid making some elaborate parsing method, we need to use a secondary test case. We create a new element as part of our base element’s innerHTML and add the styling we wish to test for as inline styles. When we retrieve the new element and examine its style, we find that unsupported style values will always return an empty string:

el.innerHTML = '<div style="color:test ; width:10px"></div>';
el.firstChild.style.color !== ""; // false
el.firstChild.style.width !== ""; // true

Using this technique means any styles supplied must be in standard hyphenated CSS format (background-color) as opposed to the previous method which must be handed camel-cased styles (backgroundColor). This means that we need to include a function to handle camel case conversions; a small hit on performance yes, but also some syntastic sugar for the method – give and take I suppose.

Throwing these new techniques together results in a method capable of determining support for not only styles but their supported assignable/recognizable values by supplying an optional second parameter.

isStyleSupported = (function(){
    var cache = {};
    var el = document.createElement('div');
 
    var toCamelCase = function(str){
        var parts = str.split('-'), camel = parts[0];
        for(var i=1, len=parts.length; i < len; i++){
            camel += parts[i].charAt(0).toUpperCase() + parts[i].substring(1);
        }
        return camel;
    };
 
    return function(style, value){
        var key = style + value || "";
        if(key in cache){
            return cache[key];
        }else{
            var supported = false;
            var camel = toCamelCase(style);
            if(el.runtimeStyle){
                try{
                    el.style[camel] = value || "";
                    supported = typeof el.runtimeStyle[camel] !== 'undefined';
                }catch(e){};
            }else{
                var view = document.defaultView;
                if(view && view.getComputedStyle){
                    var cs = view.getComputedStyle(el, null)[camel];
                    supported = typeof cs !== 'undefined';
                    if(value){
                        el.innerHTML = '<div style="'+style+':'+value+'"></div>';
                        supported = supported && el.firstChild.style[camel] !== "";
                    }
                }
            }
            return cache[key] = supported;
        }
    }
})();

So how reliable are the methods? Well in all my testing in all the browsers I could get my hands on – I have yet to encounter a single false positive in any case. So to help prove the reliability, I have put together a simple test page which includes various styles and their corresponding results when tested against isStyleSupported. In addition to that, I have included two free-form text inputs so you can try any styles you wish.

Hopefully we’ll see some of the developers of the mainstream libraries take notice and employ these techniques in future versions of their respective frameworks and finally rid themselves of the unreliable browser detection so many of them still utilize today in cases such as this.

Support

The bread and butter of the library is of course the capability tests, Env.support is designed to provide a reliable test case for some of the most popular browser features available today that are difficult to detect and/or not well supported amongst the various browsers. Tested features include; canvas, flash, native array conversion, dynamic script eval, mutation events, the box model, and more!

By default, any features that cannot be immediately resolved to a Boolean value are set to false and must prove their support. For instance, the test cases for box model support and CSS fixed positioning support require DOM node injection, this means the DOM needs to be at least partially loaded. Currently, we poll for the body element and once found execute a method to inject the nodes into the DOM and complete the test cases. However due to inconsistent and unreliable results and conflicts in execution order with the load event listener of the window and onDOMready-related methods, Env.onReady is provided to manually execute the method and finish any DOM related capability tests.

It should be noted that for the most part, I intentionally disregarded any feature tests that can otherwise be detected with simple object or typeof inference. Don’t expect objects or methods such as addEventListener or querySelectorAll to be supported, this suite is exclusive to capabilities tests that are typically difficult to detect.

Bugs

Although they are few and relatively easy to avoid, being able to harness the native capabilities of the browsers that do not possess a flawed implementation or bug versus those that do can work wonders in terms of ease and performance. For example, if you ever wanted to know if your browser supports DOM injection via innerHTML for table or select elements – now you do, and can fully exploit the faster technique for each browser. In addition to that, bugs pertaining to getElementById, getElementsByTagName, querySelectorAll, and getElementsByClassName are also all supported.

Type Detection

As a means of determining exactly what a specific object is at any given time, Env supports advanced type detection for a wide variety of objects including arrays, functions, elements, numbers, and strings, just to name a few. However, aside from the more rudimentary objects, there is also support for the much more unique objects such as nodelists, events, windows, and native methods. This allows for a definitive and reliable test for almost all objects you will encounter within the JavaScript environment:

Env.isArray([]); // true
Env.isNodeList(element.childNodes); // true

In addition to that, Env.isEmpty is a very useful method that can be used to test if a variable holds a value. Inspired by PHP’s empty function, Env.isEmpty can be tested against strings, numbers, booleans, arrays, nodelists, objects, and null and undefined values:

Env.isEmpty({}); // true
Env.isEmpty("   "); // true

Of course, what would be a feature testing library without the three methods made famous by Peter Michaux’s classic article on feature detection. Env.isHostMethod, Env.isHostCollection, and Env.isHostObject are three helpful methods designed to determine if a member of a host is what you think it is:

Env.isHostObject(element, 'firstChild'); // true
Env.isHostMethod(element, 'appendChild'); // true
Env.isHostCollection(element, 'childNodes'); // true

Finally, what might be the most innovative method to the library is Env.type which is quite simply a much greater expansion of the typeof operator. Now you have the ability of knowing exactly what any object is by simply supplying it to this method and receiving a string representation of its type:

Env.type([1, 2, 3]); // array
Env.type(element.childNodes); // nodelist

Ultimately, if no match is found for the object provided, the method will default to the typeof operator.

Event Support

One of the most difficult aspects to feature testing is determining support for event listeners of specific elements. Whether it be mutation events, contextmenu, or IE’s much desired mousenter and mouseleave; there is a wealth of varying event support amongst the respective browsers with no standard means of detecting support for them, which ultimate leads many developers to browser sniffing.

Env.support.event aims to fix this by providing a reliable test case suited for all modern day browsers. Testing for event support is simple:

Env.support.event('click');
Env.support.event('DOMNodeInserted');

By default, all event types are tested against a standard div element created within the context of a method call. As an optional second parameter, you can specify element inference by providing either a tag name (which will be used to create the element), or a raw element itself:

Env.support.event('abort', 'img');
Env.support.event('load', window);

Currently, the only mutation events supported are DOMNodeInserted, DOMNodeRemoved, DOMAttrModified, and DOMSubtreeModified, none of which are actually tested for within the context of a Env.support.event method call, but rather the context of Env on initial load and are available as part of the Env.support namespace (Env.support.DOMNodeInserted).

Much of the credit for the techniques utilized within this method goes to Juriy Zaytsev and his recent post concerning event support detection along with the talented developers involved in the discussion over at Ajaxian for all the information and inspiration, thanks!

CSS Style Support

With all the revolutionary things we’re seeing with CSS these days including transforms, transitions, rounded-corners, and the truly awesome effects such as gradients and reflectors coming out of webkit, why the hell are we still stuck looking for support for opacity, min-width, or fixed positioning. Wouldn’t it be nice to harness these latest CSS styles without resorting to browser detection or some nasty hacks?

Well wait no longer,  if you’re simply looking to determine support for a CSS property, just call the method and get your answer – no browser sniffing, no elaborate test case, no false positives, nothing but a definitive result, what else could you ask for?

Env.support.style('min-width');
Env.support.style('-moz-border-radius-topleft');

As if that wasn’t enough, you can also determine support for a specific style’s assignable values, such as fixed positioning. By simply providing the value as an optional second argument, you now have a 100% reliable test case for not only the CSS styles themselves but their supported values:

Env.support.style('position', 'fixed');
Env.support.style('-webkit-transform', '2ex');

Now were golden, so go start using those CSS styles you’ve longed to try! For a detailed description of how this method works, see the post here; http://ryanmorr.com/archives/detecting-browser-css-style-support.

Example

To see a simple example of all the tests available within the Env.support and Env.bugs namespaces, try clicking here and see how your browser stacks up!

Summary

My greatest hope here that the community of developers will realize (if they haven’t already) where and when feature detection can and should be utilized. It has always been my contention that browser detection has no place within a script, not now and not ever. Despite some long dilemmas and unique workarounds, I for one am still waiting for that immense problem that can only be solved via browser detection – in three years of developing in Javascript (which I know isn’t very long) I haven’t encountered anything to that effect yet, and Env will help to ensure that I never do. So this is it people, no more excuses, defending browser detection is like defending gas-powered cars – it may be faster, but the world is moving to a much cleaner and environmentally safer approach, or at least I hope they are!

Please report any bugs or false positives you may experience, and if you have any suggestions of bugs or features to test for in future versions, I would love to hear them.

Download

• Compressed (11kb)
• Fully Documented (27kb)

What is Browser Detection?

Browser detection or sniffing is the practice of detecting the browser runtime environment in which JavaScript is being executed. This helps to restrict execution of certain fragments of code to that browser based on features or bugs that are believed to be associated with that specific browser. This exercise is not only restricted to the type of browser (IE, Firefox, Opera, Safari, etc.) but also the browser version and the operating system. The most common method of detecting the browser is via the userAgent string of the navigator object, for example, the following is the output of the userAgent string of your browser:

As you can tell, you will be required to parse that string to get a definitive browser and version out of it.  Some developers will choose to ignore the user agent electing instead to facilitate unrelated object inference to detect the browser, such as ActiveXObject for Internet Explorer, despite common belief this should not be considered object detection.

The goal of browser detection is too provide a simple method in which to detect a browser’s native feature or method support (XMLHttpRequest, ActiveX, etc.), object support (event.clientX, event.pageX, etc.), and most importantly bugs (IE can confuse id and name attributes when using document.getElementById).

The Dangers

The practice of browser detection is nothing new and from the perspective of a relatively new developer to the language, it is a justified solution to obtain cross-browser compatibility which can be so difficult to achieve. However at some point along the way, the exercise has been abused, quickly becoming common routine rather than a last resort, finding its way into scripts where simple object detection would suffice.

The fundamental problem with browser detection in any capacity is the inherent dependency on what is widely believed to be true associations between a browser and a bug or feature. In other words, you are making an assumption about every browser of every user that visits the page, and assuming every feature and bug that is being tested for is a correct affiliation with that browser. These assumptions as always can be very dangerous, your application as a whole may just depend on it.

The flaw in browser detects themselves are their static nature, whether your testing the user agent or relying on a specific object (ActiveXObject) to identify the browser, a static browser detect is only as reliable as your knowledge of the browser environments you currently support at the time of implementation. As browsers continue to evolve, new browser and browser versions released, and API’s updated, your application will become a fragile implementation at the mercy of the evolution. What were previously thought to be true associations between a browser and a feature or bug are now false and inconsistent.

Browser spoofing is an issue developers have been tackling ever since the days of Internet Explorer and Netscape Navigator. What is browser spoofing? Well, quite simply it is the ability for one browser to attempt to imitate another via the userAgent string. If you re-examine the example I provided above of what your user agent is, you may notice (depending on the browser your using) hints of other browsers. A quick test in the various browsers for me reveals words such as “Mozilla” in IE7 and  “Gecko” and “Safari” in Chrome. This makes it very difficult to create a reliable and consistent browser detect, requiring a developer to constantly change their methods of browser detection. To view the history of the user agent string and browser spoofing, see http://webaim.org/blog/user-agent-string-history/

The ultimate goal of any application is to increase and maintain traffic, this starts with attempting to support as many browsers as possible. Typically, browser detection infers a specific list of supported browsers as is the case with most JavaScript libraries. However, this not only isolates your browser support but also alienates alternative browsers and browser versions that may otherwise be fully capable of supporting your application. Upgrading your browser version may be all that is required to break the browser sniff and all subsequent dependencies. Ideally, you should aim to support any browser that supports only the features your application utilizes, and offers a graceful degradation for those that do not.

It should also be noted that the greatest discrepancies between browsers is in rendering of the web page, which is not so much a JavaScript issue but a CSS and markup issue, so lets keep it that way. Making adjustments to various measured CSS properties such as width and height in JavaScript based on the type of browser should not be necessary. Of course there are the well known asterisk and underscore hacks, as well as many other browser specific workarounds in CSS, but that is another topic for another day.

Feature Testing

The ultimate solution and alternative to browser detection is feature testing, the simple means of testing for a “feature” before utilizing it in some capacity. The technique is often applied as direct object, method, or typeof inference as it relates to the feature within the browser environment during runtime. Ultimately, the reliability of such a test case lies solely in it’s ability to execute successfully and provide a definitive boolean value in which to compare against. However, there is a right way and wrong way in which to approach this technqiue, for instance, evaluting support for event handlers typically will involve a test case for standards compliant browsers such as Firefox and falls back to IE’s implementation if addEventListener is not supported:

function addEvent(el, type, fn)
    if(el.addEventListener){
        el.addEventListener(type, fn, false);
    }else{
        el.attachEvent('on' + type, fn);
    }
}

However, even a perfectly suited feature test as common as this is making an assumption about the user’s browser; if it doesn’t support addEventListener, it must be IE, so lets use the attachEvent implementation. Ideally, a test case should be used for each browser specific implementation, and provide a final fallback on the off chance of a failed test case in an alien browser:

function addEvent(el, type, fn)
    if(el.addEventListener){
        el.addEventListener(type, fn, false);
    }else if(el.attachEvent){
        el.attachEvent('on' + type, fn);
    }else{
        el['on' + type] = fn;
    }
}

The only problem here is that the third case actually sets the event not adds to it, so it effectively removes previously bound handlers of that event type. However this can be quickly solved by caching event handlers of a specific event type, in which case addEventListener and attachEvent would be completely unnecessary, such is the case with Dean Edwards’ solution. Ultimately, this method combined with an unobtrusive implementation will almost certainly provide a reliable application suited for both browsers that support the method and those that don’t via graceful degradation, including the crowd that has disabled JavaScript.

The wild card are the various bugs or quirks; supported implementations that either do not perform or behave as expected. More often than not, a bug exists within a host method, meaning the only way it can possibly be tested is to actually execute the method in a meaningful test case, for example:

function(){
    try{
        var children = document.documentElement.childNodes;
        return Array.prototype.slice.call(children) instanceof Array;
    }catch(e){}
    return false;
}

This particular test determines support for a native nodelist to array conversion. The method utilizes a try-catch block which typically should be avoided, primarily because in a context such as this, an assumption is being made about what it means when a test fails and the exception is caught. We assume that the exception was thrown and the method returned false because the browser doesn’t support native array conversions. However the method would return the same if an error occurred due to a bug else where in the try-catch block, this makes for fragile code in future browser environments. Although the solution is not ideal, it is the best JavaScript will allow us do at this point in time so it will have to do.

Despite difficult and often cumbersome, there is almost always a test case available in some capacity capable of determining browser support. To view more common bugs as well as their respective test cases, have a look at Juriy Zaytsev’s fantastic resource.

Feature testing isn’t the perfect solution – there is no perfect solution, however from a practical standpoint, it is your best bet to ensure a reliable code base. As it relates to testing bugs, the dependency in the test will lie solely in the method in which you test the feature. The bottom line is if there is one thing that a developer should know; it’s the environment that he or she is dealing with. It is of far greater importance that a developer know the bugs and how to individually avoid them than to lump them all together based on assumptions in an eventual failure. To read more about feature testing, see Peter Michaux’s excellent and all inclusive article on feature detection.

Summary

Feature testing may not be simple and in some cases may require an elaborate and complicated test case, however it is the obvious answer. As oppossed to browser detection, it doesn’t draw on associations, assumptions, or false positives that are believed to be true affilations with a specific browser to create fragile test cases. Instead, feature testing relies on what it knows about the browser environment during runtime, not the precieved browser support at the time of implementation. The philosophy here is simple; if your unsure that a specific object/method is supported in the native environment or performs as expected, try it and let the test case tell you – don’t tell it. Resorting to browser detection should no longer be considered a last resort, but bad practice.

Why use a JavaScript Library?

The driving force behind JavaScript libraries and their very rise in popularity is based on two things; cross-browser compatibility and the lack of various native implementations. They create an easy-to-use implementation which helps to normalize behaviour across browsers and add additional functionality, specifically as it relates to the the four core aspects of most JavaScript libraries; event handling, animation, DOM (manipulation and traversal), and AJAX.

Additionally, some libraries also feature, as a plugin or as part of the core, various user interface (UI) components and widgets, most notably jQuery UI, YUI, Digit (Dojo), and Ext.

The typical reasoning as to why a developer adopts any JavaScript library for their project falls back to the common expression; why reinvent the wheel?

The Criteria

Evaluating a JavaScript library is no different than an evaluation of your own code, after all, once implemented, you will assume responsibility for it. Performance, compatibility, and bugs will immediately become your problem – it is you who will hear the complaints of your end users, not the authors of the third party software you’ve decided to utilize. Therefore, it is important to understand the flaws inherent in all JavaScript libraries and to properly justify your choice of implementation for a specific project.

With that in mind, it is important to outline the criteria when considering which framework to adopt or whether or not to use one at all. Much of the criteria including the weight of each measure will be specific to the project in question, most of which stemming from the scale of the project and the desired functionality. Does your project require certain UI components such as a grid, toolbar, or tabbed interface? Will my application require support for HTML, XML, SVG, flash, or canvas? These are just a few of the questions that should be evaluated on a case by case basis. In addition to that, there are several general questions a developer should ask of himself and the pending project that are relevant to any and all projects:

• the ease of implementation/updates (API)
• browser support
• file size (bytes)
• documentation
• performance
• extensibility
• robustness and modularity
• stability and reliability
• the developer’s overall capacity to understand and progress in their understanding of their implementations

The last point is especially important and should not be glossed over, dependency is something you should steer away from – to understand all the code is to know how to fix/improve it, even if it isn’t your code.

Advantages

Without question, a well developed JavaScript library has many advantages over the alternative and provides the developer a simple layer of abstraction on which to develop their application.

One of the primary advantages to a JavaScript framework is the ease and simplicity of development and implementation. Whether it be prototypical/classical inheritance, CSS selectors, animation and effects, or creating a wrapper class for things like elements, AJAX requests, or what have you, a library typically allows you to make quick implementations in little time and little bytes.

As I mentioned above, cross-browser compatibility and normalization is perhaps the greatest attribute of any library. The developer need not worry about the flawed implementations of the various browsers or what functionality is supported or isn’t, let the library worry about that.

If you are to adopt any third-party software, well documented code and a highly adaptive API are key. Although it is completely dependent on the framework at hand, typically a library will supply solid documentation set with examples.

Plugins, extensions, and user interface widgets are just a few of the byproducts of a healthy and active community. Extensibility plays a large role in developing and maintaining a community of developers for a specific library, and nobody does this better than jQuery. The library boasts an impressive amount of plugins ranging anywhere from drag-and-drop and layouts to data stores and media. With a community as active as that, virtually anything you could ever want is already available and ready for implementation.

Most of the JavaScript libraries available today are completely open-sourced, including; jQuery, Mootools, Prototype, YUI, Dojo, Ext, and more. Not only does this help to create an active community but can also help a developer in understanding how the framework implemented a certain feature by simply viewing the source and reading the documentation. It proves to be a very useful resource for anyone looking to learn and understand advanced JavaScript.

Disadvantages

At some point in the last four or five years, as the library revolution started to take over, too much attention has been placed on the positives and not enough focused on the negatives. These libraries are often portrayed as perfect, but they are not, and you should understand all the disadvantages inherent in their adoption for a project.

First and foremost, browser detection is a common problem amongst JavaScript libraries, and virtually all still utilize it. There is no feature/bug that can’t be detected, tested for, or worked around in some manner. Sacrificing bytes for shortcuts should never be permitted especially amongst the very best the industry has to offer. The goal should be to try and support as many browsers as possible, otherwise you could be turning away potential visitors without even knowing it. I would be remissed if I didn’t mention that jQuery (as of version 1.3) no longer utilizes browser sniffing as part of the base library, however many plugins still do!

Bugs are a common problem with any code, however when it isn’t your code and you don’t understand the implementations, your limited in your ability to resolve the bug. Such is the case with JavaScript libraries, a developer may find himself waiting for a new version or update of a specific framework to solve his bug as visitors continue to encounter the problem. Once that new version is released and implemented, he better cross his fingers and hope it gels well with not only his code, but any other plugins that also rely on that particular library. Often a library will release a version that unexpectedly drops support for specific methods, properties, and/or classes, forcing plugin developers to update their versions (which you will also have to wait for) unless you try and do it yourself.

Another common problem various JavaScript libraries internally struggle with is the battle between usability/simplicity (API) and performance. The layer of abstraction your working with may be on such a high level that the length and intensity of each method call is slower than it otherwise should be, specifically as it relates to DOM manipulation. For instance, jQuery contains all currently selected elements within an internal array that must be looped through on each method call, whether the array contains 100 items or 1 or 2, this creates unnecessary overhead. Although it is true that libraries consistently improve in this regard, performance still lacks where typical manual DOM manipulation excels, especially in IE. Just look at these performance results conducted by Anrea Giammarchi in a test that pits the various JavaScript libraries against the DOM.

A JavaScript framework is often guilty of trying to do too much, resulting in a bloated library of methods and classes that are rarely utilized, trying to answer questions nobody has asked.  Whats worse, is the encouragement and support for bad programming, trying to normalize behaviour not only amongst browsers but developers too. Of course, this results in a larger file size full of unused code – wasted bytes using unnecessary bandwidth. On a related note, many developers will use a JavaScript library solely for its support of a specific plugin, such as a lightbox or date picker. This requires them to import a large framework the majority of which is never utilized and therefore never justified.

As I mentioned before, the adoption of any JavaScript library does not progress a developer in the understanding of the language or the various implementations. It creates a certain level of dependence on methods, classes, and plugins that may not be there forever, as you fall at the mercy of the third party software. Sooner or later, the JavaScript language along with browser support will grow and improve, JavaScript libraries will quickly become obsolete in that environment, and any developers who rely on them will be left out in the cold – with their app of course.

The Solution

Ultimately the solution lies in learning the language and not a library, to know the bugs, the browser inconsistencies, and the supported implementations and knowing what to do about it. However, I realize that it is a time consuming goal that may not be realistic for the short term, that is why I propose a middle man; the module, think of it as a plugin for the language not a library.

Perhaps its a lack of support for lightweight and standalone modules that have driven people to the all inclusive framework and the various plugins that lie on top of them, in part this blog is dedicated to fill that void. Still third party software, a module however is small and concise and serves only one purpose, whether it be DOM manipulation, event handling, AJAX requests, or what have you. This makes for a much simpler approach and therefore easy debugging, not to mention, the author is more likely to update with greater frequency, plus no pesky dependencies.

Naturally, as many modules are thrown together, cohesion is likely to be effected resulting in code duplication and loose coupling, that is where you come in. Make it cohesive, merge the modules and create something custom for each project, your not reinventing the wheel but your also not relying on someone else’s. Take the tire, the rim, nuts and bolts and put it together yourself! You might learn something in the process!

Development is about one thing; to have a better understanding of what is going on behind the scenes, know your implementations and understand their impacts. The ultimate goal is the satisfaction of your end-user, and at the end of the day reliability should be your number one concern. For this, the answer is clear.

Aurora

The goal of the project is to provide a means of defining instance variables bound to a specific data type as you would find in Java or a variety of other languages. All subsequent calls to the methods of the instance result in automatic variable validation after the method call is complete. If a type violation is found, a descriptive exception is thrown and that specific variables value will be reverted back to what it was before the method call took place.

In addition to that, there is added support for class invariants, inspired by Eiffel, each class can declare a set of invariants for each instance variable which outlines the rules of that variable. For example, a variable called month in the class calendar must be an integer between the values of 1 and 12, if that rule is broken an exception is thrown.

Data Types

By default, there are 12 declared data types; String, Date, Number, RegExp, Function, Boolean, Array, Object, Null, Element, Event, and NodeList. In addition to that, a variable can not only be declared as type Array, but the contents of the Array can also be constrained to a specific data type:

items: [Object]
collection: Array(Element)

Also, any declared class will also automatically become a declared data type, meaning a class can define a variable to have the data type of another class. For example, a Menu class may have a variable assigned to hold an Array of instances of the class Menu.Item:

menuItems: [Menu.Item]

The define method allows you to add your own additional custom data types for the purpose of variable declaration. The method requires only two arguments; the name of the new data type as a string which does support namespacing and a function that will be used to validate all variables against.

Aurora.define('Hash', Aurora.isHash);
Aurora.define('Integer', Aurora.isInteger);
Aurora.define('Decimal', Aurora.isDecimal);

Without initialing them, there is a variety of functions available to allow you to easily add additional support for a variety of different data types. Almost all objects often encountered within Javascript have an associated validator included in Aurora to enhance the data type declarations, validators include:

• Aurora.isHash
• Aurora.isInteger
• Aurora.isDecimal
• Aurora.isXML
• Aurora.isXMLDocument
• Aurora.isXMLNode
• Aurora.isWindow
• Aurora.isDocument
• Aurora.isNode
• Aurora.isArrayLike
• Aurora.isVoid
• Aurora.isNative

Invariants

The class invariant is used to set constraints on specific variables to prevent unwanted data from being assigned to an instance variable. All invariants are defined in an invariant object, each invariant is assigned the same name as the variable they represent and are to constrain. They must take the form of a function and it also must return a boolean; true if the variable is valid and false if it is not. The following example demonstrates class invariants you might find in a calendar class:

invariant: {
    day: function(){
        return this.day >= 1 && this.day <= 31;
    },
    month: function(){
        return this.month >= 1 && this.month <= 12;
    },
    year: function(){
        return this.year >= 1 && this.year <= new Date().getFullYear();
    }
}

Classes

The declare method is used to define a new class and has a similar syntax to the dojo.declare method. The method can accept either two or three arguments depending on whether the new class will inherit from a superclass. The first argument is a string name of the class which also supports namespacing, if there is a superclass it will become the second argument, otherwise the property object will follow. The property object is where the constructor, all declared data types, methods, and the invariant will be declared. Both the constructor and the invariant are not required, additionally, any properties that are not declared with a data type will be treated like a typical property and not subject to type checking.

Aurora.declare('Clock', {
 
    hour: Number,
    minute: Number,
    second: Number,
 
    constructor: function(hour, minute, second){
        this.hour = hour;
        this.minute = minute;
        this.second = second;
    },
 
    invariant: {
        hour: function(){
            return this.hour >= 1 && this.hour <= 12;
        },
        minute: function(){
            return this.minute >= 0 && this.minute <= 59;
        },
        second: function(){
            return this.second >= 0 && this.second <= 59;
        }
    }
});

Inheritance

Classical inheritance is also supported and maintains the same behaviour and functionality that you would expect. However, in addition to the inherited methods and the ability to call superclass methods, both declared types and invariants of a superclass will also be inherited by all sublcasses. Any defined invariants with the same name as an invariant inherited by a sueprclass will automatically be overwritten. However, they maintain the ability to call the invariant of the superclass method for additional validation.

Aurora.declare('Component', {
 
    value: Number,
 
    constructor: function(value){
        this.value = value;
    },
 
    invariant: {
        value: function(){
            return this.value > 0;
        }
    }
});
 
Aurora.declare('Module', Component, {
 
    name: String,
 
    constructor: function(name, value){
        this.name = name;
        Module.superclass.constructor.call(this, value);
    },
 
    invariant: {
        name: function(){
            return this.name != "";
        },
        value: function(){
            return this.value < 10 && Module.superclass.invariant.value.call(this);
        }
    }
});

Exceptions

Whenever a violation occurs, whether it be a type or invariant violation, an exception is thrown that indicates the type of violation, the class and method in which the violation occurred, the variable that failed the validation, and in the case of type violations the expected type. For example, a type violation in Firefox’s error console looks like so:

Likewise, a violation on a variable with type Array with constrained contents will produce this error message:

Finally, if any variables break the contraints set by its invariant, an exception will be thrown:

Example

The example demonstrates a typical type violation and the exception thrown when one occurs. Click here to see it in action and be sure to open your error console.

Summary

As I mentioned in the beginning of the article, Aurora is a demonstration of the flexibility of JavaScript and not intended for serious use. Like many of the mainstream libraries available today, hacks and extensions are the name of the game, and there is almost nothing that can’t be simulated or imitated in one fashion or another. There is still much room for improvement within Aurora, the next most logical improvement would be adding validation to both method arguments and return values. No matter where Aurora goes from here, the most I can hope for is that other developers more creative and skilled than me can provide their own work of magic to the community.

Download

• Compressed (7kb)
• Fully Documented (17kb)

Each invocation of a function establishes a unique execution context that lasts only for the duration of that function call. Each execution context appends its local scope to the scope chain in which it was defined. Name conflicts amongst variables within a specific context are resolved by climbing up the scope chain, moving locally to globally. This means that local variables with the same name as variables higher up the scope chain take precedence.

Global/Local Scope

A variable can be defined in either local or global scope, which establishes the variables’ accessibility and context within the runtime environment. Any defined global variables, meaning any variables declared outside of a function body, live throughout the life of the page and can be accessed and altered in any context.

Local variables exist only within a function body of which they are defined. A local variable has a different execution context for every invocation of the function to which it belongs; it is subject for value assignment, retrieval, and manipulation only within that call and is non-accessible outside of that execution context.

Losing Scope

It’s a common problem developers find themselves dealing with when they delve into advanced techniques in Javascript, specifically as it refers to event handling and object orientation. Here the infamous this keyword plays an important role, but knowing what it is referring to at all times can be confusing.

Event handlers added using Internet Explorer’s attachEvent method causes a loss of scope when that event is fired and the callback is invoked, as the function is executed in the context of the window object. As a result, this will reference the window and not the element which registered the event handler as is the case with standards compliant browsers such as Firefox. Alternatively, when an event handler is added as an expando property (element.onclick), the callback will execute in the context of the element, even in IE. The reason for this is the scope chain, because the expando is a  property of the source element, it is appended at the top of the scope chain for each execution context. Meanwhile, due to a flaw in attachEvent, the window object is the only object associated with the callback and therefore is the only context available in the callback’s scope chain.

To better demonstrate this, try adding a function as a unique expando property and then execute it; this will now refer back to the source element:

var fn = function(){
    alert(this.id);
};
 
element['e'+fn] = fn;
element['e'+fn]();

Scope is also lost when dealing with object-orientation and event handling, which is not so much a flaw in the language but the implementation. Event handlers can only be added to DOM nodes which means (in standards-compliant browsers) this will always refer back to the source element, which is the way it should be. However if the callback happens to be an instance method, there is no way to properly call that method without altering scope. A quick solution to this is to declare a variable with the value of this and simply use a nested function to redirect the call to the desired method, like so:

var self = this;
element.onclick = function(){
    self.instanceMethod()
}

However, this can be cumbersome, the real solution involves what many believe to be one of the most useful techniques of the Javascript langauge; manual scope adjustment (more on than a little further down in the article).

Closures

One of the most powerful aspects to Javascript is the flexibility of functions; they can be sent as arguments, nested inside other functions, executed in any context desired, and encapsulate their own execution context. Closures can serve as quite the tool when scope becomes an issue as they can take on many different forms and can encapsulate and preserve a specific execution context for further manipulation.  In simplest terms, closures are variable functions local to another function that have the unique ability to retain their values between function calls. The most popular closure is what is widely known as the module pattern; it allows you to simulate public, private, and privileged members.

Module = function(){
    var privateProp = "";
    var privateMethod = function(args){
        //do something
    }
 
    return {
 
        publicProp: "",
 
        publicMethod: function(args){
            //do something
        },
 
        privilegedMethod: function(args){
            privateFunction(args);
        }
    }
}()

The module acts as if it were a singleton executed as soon as the compiler interprets it (hence the opening and closing parenthesis at the end of the function). The only available members outside of the execution context of the closure are your public methods and properties located in the return object (ex. Module.publicMethod). However, all private properties and methods will live throughout the life of the application as the execution context is preserved, meaning variables are subject to further manipulation and execution via the public methods. Another type of closure is what I like to call a global closure which is nothing more than a self-invoked anonymous function executed in the context of the window:

(function(){
 
    //Use this or window to define a global variable
    var Module = this.Module = window.Module = function(){
        //do something
    }
 
    Module.publicProp = "";
    Module.publicMethod = function(){
        //do something
    }
 
    var privateProp = "";
    var privateMethod = function(){
        //do something
    }
 
})()

The global closure is most useful when attempting to preserve the global namespace as any variables declared within the function body will be local to the closure but will still live throughout runtime, often one namespace is enough for interaction outside of the closure.

Call and Apply

If you want to know how all the mainstream libraries do it, well it’s simple; call and apply. These two very simple methods inherent to all functions allow you to execute any function in any desired context. Before I continue, it is important to know that everything in Javascript inherently has its own context, including DOM nodes, objects, arrays, strings, functions, etc. Meaning, any function can be executed in the context of any object using call and apply. This may seem insignificant, but understand it is this implementation that serves as an underlying bridge between the object-oriented and functional methodologies in the Javascript language.

The call method contains an unspecified amount of arguments, the first is the object whose context the function is to be executed in, all subsequent arguments will serve as the arguments for the callback function in question. Apply works similarly with one exception, rather than supplying each argument individually, an array will be supplied that will automatically build the arguments for the function.

method.call(scope, arg1, arg2, arg3);
method.apply(scope, [args]);

This is ultimately what should be used when referring to event handlers especially as it relates to object-orientation. One of the more popular functions used to quickly adjust context is the bind function, which utilizes closures by accepting the scope as well as arguments for the callback function and returning an anonymous function that behaves appropriately.

Function.prototype.bind = function(){
    var method = this;
    var context = arguments[0];
    var args = Array.prototype.slice.call(arguments, 1)
    return function(){
        method.apply(context, args);
    }
}

It is most commonly used where context is most commonly lost; event handling as well as a few other implementations such as  setInterval and setTimeout. The following example demonstrates a callback method bound to a specific context for execution for each loop of an interval:

setInterval(callback.bind(obj));

What is important to note here is that setInterval is not executing the bind function or the callback function. In fact it is the closure that was returned by the bind function that is being called on each loop of the interval. It promptly redirects the call to the callback function in the context that was supplied to the bind function: “obj”. While reviewing the source of the bind function, you may have also noticed what appears to be a relatively simple line of code involving a method of the Array object’s prototype:

var args = Array.prototype.slice.call(arguments, 1);

What is interesting to note here is that the arguments object is not actually an array at all, however it is often described as an array-like object much like a nodelist (anything returned by getElementsByTagName or element.childNodes). They contain a length property and indexed values but they are still not arrays, and subsequently don’t support any of the native methods of array such as slice and push. However, because of their similar behaviour, the methods of Array can be hijacked and executed in the context of an array-like object as is the case above.

This technique also applies to the methods of classes; making it easy to execute a method of a prototype chain in the context of a another instance and have all properties and methods of that instance immediately recognized and subject to execution and manipulation. The following example demonstrates a method of the Module class calling a method of the Component class in the context of the Module instance. This is also what makes calls to a superclass possible when simulating inheritance in Javascript.

Module.prototype.method = function(){
    //call another method of another class in the context of this instance
    Component.prototype.method.call(this, arg1, arg2, arg3);
}

Summary

Versatility is the name of the game here, in the attempt to try and do everything Javascript fails to present developers with a well integrated language, resulting in a very loose implementation. However, there is a method to the madness, and although these little quirks and workarounds are not ideal they are necessary if you want that efficient and effective app that we all strive for. All the techniques I’ve discussed here today are powerful ones, and they can work against you if implemented in the wrong fashion or the wrong place. Closures for example can reserve a lot of memory and ultimately cause memory leaks in IE. However, when done right, developing will never be easier and it will show, knowing your scope at all times is important and to know it is to utilize it, which will save you a world of headaches now and in the future.

References

• http://www.digital-web.com/articles/scope_in_javascript/
• http://www.robertnyman.com/2008/10/09/explaining-javascript-scope-and-closures/
• http://www.jibbering.com/faq/faq_notes/closures.html

If your anything like me then what your really looking for is something standalone. After googling for an extensive amount of time, I think I found five pretty good ones: Facebook animation, JSTweener, RUN, Bytefx, and Bernard Sumption’s Animator. These are all great solutions and fairly lightweight tipping in somewhere between 15 and 25 kb (uncompressed), and also support most of the bells and whistles found in the major Javascript libraries. The only knock against them is well actually, only a knock against Facebook’s version, simply because they decided to sniff out Firefox in just one segment of code, close but no cigar.

Now with no further delay, I present to you my version appropriately named FX. The motive here was to create a simple script for your basic animations and of course to be library independent, with emphasis on lightweight. Where I have strayed away from the other solutions I mentioned above is that I’ve stripped out most of the extra features, electing instead for the core functionality. The syntax is similar to that which you would find in YUI, I find it simple yet covers all the bases pretty well. I drew inspiration for the programming behind it from Mootools due to its simplicity as a whole. To use it is pretty simple; just tell it what to do, give it a duration, optional callback, and then let it fly.

Features

• Perform tween on almost all CSS properties
• Supports both scroll and color animations
• Allows for both to and from values for each attribute
• Supports transitional easing
• Optionally assign a callback and context to execute the function in upon animation completion
• Supports IE6+, FF, Opera, Safari, and Chrome
• No browser detection

Example

The syntax is pretty straigth forward, as I mentioned before it looks similar to what you would find in YUI. The following example demonstrates just some of the attributes supported for animation. For a more impressive sampling of FX, see this example.

var fx = new FX('element', {
    'top': {to: 500},
    'left': {to: 300},
    'width': {from: 100, to: 300},
    'height': {from: 100, to: 200},
    'scrollLeft': {from: 0, to: 50},
    'background-color': {from: '#FF0000', to: '#0000FF'}
}, 1.5, callback, context);
 
fx.start();

At the moment, only pixels are supported as the default units for all animations, and there is only one type of transitional easing available. At some later point in time I will be updating to add support for both of these features, so check back soon!

Download

• Compressed (4kb)
• Fully Documented (8kb)

Despite the debate over the very need of such a function, I decided to pursue it anyways out of pure curiosity. Once I committed to it and began coding I was fully expecting something to go wrong, after all, if all the major libraries couldn’t figure it out then there must not be a solution that doesn’t resort to browser detection, right? Unless of course they never even tried. To my surprise it was fairly simple, within 20 minutes I had a working version that was every bit as reliable as those found in YUI, Prototype, Mootools, etc. except no browser sniffing. Surely these talented developers (and I don’t doubt their skill) could have found a similar solution had they looked. The only exception to this is jQuery who I am very pleased to see have made great steps in completely removing browser sniffing with jQuery 1.3, including in their use of the ready function for onload handling, credit to John Resig and the jQuery team. Regardless, I present to you in just 42 lines of code, a simple function to handle all your onload requirements with no browser sniffing!

Features

The function itself works similar to the other solutions available around the web including those found in the various Javascript libraries. However, rather than separating each routine via browser detection, I simply use one function to parse the document’s current state and determine if the DOM is ready for manipulation. For Firefox and Opera a simple check of event type will determine if it is DOMContentLoaded. Safari and IE will check against the document’s ready state, and alternatively IE will routinely try to scroll the document left, if successful – the DOM is ready. Finally in case all else fails, the onload event will bring up the rear. Upon completion, the supplied function is called and all event listeners are removed and nulled out to prevent memory leaks. Test it out here.

function onDOMReady(fn, ctx){
    var ready, timer;
    var onChange = function(e){
        if(e && e.type == "DOMContentLoaded"){
            fireDOMReady();
        }else if(e && e.type == "load"){
            fireDOMReady();
        }else if(document.readyState){
            if((/loaded|complete/).test(document.readyState)){
                fireDOMReady();
            }else if(!!document.documentElement.doScroll){
                try{
                    ready || document.documentElement.doScroll('left');
                }catch(e){
                    return;
                }
                fireDOMReady();
            }
        }
    };
 
    var fireDOMReady = function(){
        if(!ready){
            ready = true;
            fn.call(ctx || window);
            if(document.removeEventListener)
                document.removeEventListener("DOMContentLoaded", onChange, false);
            document.onreadystatechange = null;
            window.onload = null;
            clearInterval(timer);
            timer = null;
        }
    };
 
    if(document.addEventListener)
        document.addEventListener("DOMContentLoaded", onChange, false);
    document.onreadystatechange = onChange;
    timer = setInterval(onChange, 5);
    window.onload = onChange;
};

I also made a similar version that utilized a defer script for IE and worked just as well, however due to a fundamental flaw in the implementation I recently became aware of, I decided the current version as it is now would suffice. Furthermore, the method could be modified to accept multiple functions and simply append them to an array which could then be iterated over and executed accordingly once the DOM is loaded, facilitating multiple onload handlers. Depending on the response I may add those or other features at some later point in time, or feel free to modify it as you see fit for your own personal use.

Download

• Compressed (1kb)
• Fully Documented (2kb)

In light of my new found appreciation of XML and XSLT I decided to put a little script together for your basic XML and XSLT importation and manipulation. Hopefully we can get those wheels turning again, maybe one day I can see that potential and not just read about it.

The script itself is fairly lightweight and handles the basic functions associated with XML and XSLT manipulation in Javascript as I’ve outlined below. If your looking for something a little more full featured, Sarissa is a great option as it can handle just about everything including the kitchen sink, you can find it here; http://dev.abiss.gr/sarissa/.

Features

• Load local XML and XLST files
• Encode and decode an XML string
• Serialize an XML string into a document
• Parse XML document into a string
• Transform an XML file with an XSLT stylesheet and apply to element
• Perform an XPath query on an XML document
• Supports IE6+, FF, Opera, Safari, and Chrome
• No browser detection

Example

The following example illustrates a simple transformation involving an XML document, XSLT stylesheet, and an element (container) that will house the results of the transformation. See it in action here

var processor = new XMLProcessor();
var container = document.getElementById('container');
 
processor.loadXML('xml.xml');
processor.loadXSLT('xslt.xsl');
processor.transform(container);

The topic of XML and XSLT and their use within a web application deserves its own post (there is a lot more to it then when I’ve discussed here) and I think I’ll probably do that in the not to distant future.  For now you can find more information on XML, XSLT, and their various elements and functions at the W3C and W3 Schools, two resources that I referred to in preparation of this article.

Download

• Compressed (3kb)
• Fully Documented (6kb)