It might seem like one of those unnecessary things, but it can help to bridge the gaps, adding that little something extra for the end-user’s experience. A smooth animation allows a user to fully understand the actions taking place by visually seeing components in transition. Here, I present to you my animation framework appropriately named FX. The motive here was to create a script with the mentality of keeping it simple, library independent, and lightweight. In the end all you get is a seamless transition in all browsers while maintaining complete control over the animation.

You cannot undervalue the cost-benefit of iteration, despite being such a simple construct, it is a frequently used process fundamental to any framework. For these reasons, we want to maximize the efficiency and effectiveness of the routine by leveraging native implementations where they are available. This is an important concept for all enumerable objects, not just arrays but also array-like objects such as nodelists and arguments. By harnessing the capabilities of the native environment we can utilize the improved performance and reliability inherent to the JavaScript engine.

To harness or exploit the most out of CSS classes is to take advantage of what truly is the unsung hero of advanced RIA development as it relates to the presentation layer. When we observe our markup, we find that various portions of the DOM may require styling influences on the initial page load as well as interaction events or cues to adjust its structure, positioning, visibility, state, and skin. For this classes are the clear suitor, as it brings flexibility, modularity, inheritance, and a dynamic and unobtrusive nature to the table.

If you have ever wanted to manipulate those brand spanking new styles such as -moz-transform, -webkit-transition, or even some older ones like opacity in IE and max-width in IE6 but didn’t because you were reluctant of browser support, than you are not alone. For this article, I will be exploring some unique tactics in an effort to solve the dilemma as it relates to JavaScript.

It is still a controversial issue today despite the recent evolutions in the industry including new modern browsers and new resources such as jQuery (as of version 1.3) that now entirely base their implementations on feature testing. However, somehow the practice of browser detection seems to still be alive and well, whether it be new browsers bringing about new bugs, features that are difficult to detect, or simply shortcuts spawned out of pure laziness, the practice is not only being used but defended. Browser sniffing can be found around just about every corner you look – from the smallest of websites, to your favourite JavaScript library (Mootools, Prototype, YUI, etc.) utilized in corporate giants such as Chrysler, Gamespot, and Yahoo!

It is rarely even a question anymore; deciding whether to use a JavaScript library on your next project typically goes without saying, the real question developers find themselves asking is which library should it be? However the decision to adopt any framework for a project should not be taken lightly and deserves a proper evaluation of requirements before making a decision based on assumptions. Often a library may ask of a developer, “Does the JavaScript library help me to write JavaScript?”, but shouldn’t they ask if the library helps them to learn JavaScript? Learning the syntax of your favourite JavaScript library does nothing for the developer’s understanding of the language itself or the impact on performance, memory, and reliability of their implementations. For this article, I will be looking at both sides of the argument, but hiding my bias will not be easy, my hope here is that perhaps a few developer’s may rethink their approach.

Scope or context as it is often referred to as is one of the fundamental aspects of Javascript, playing a significant role unlike that of any other language. Scope refers to the accessibility of variables and its execution context which belongs to the object or function in which it was defined. However this does not always hold true as scope can be lost or changed depending on how and where it used, specifically as it applies to functional execution.

For the most part, I’ve typically relied on window.onload for my various projects; its simple, cross-browser, and the alternative onDOMReady functions were unreliable due to their utilization of browser sniffing in some fashion. However, the problem with window.onload, as I’m sure you’re all aware, is that it doesn’t fire until the entire page has loaded including all images. This can make for a usability nightmare for any page with a lot of images and/or anybody with a slow connection. If your page relies on JavaScript then there could very well be an extended amount of time whereby the user is interacting with the page and it hasn’t yet been initialized. An onDOMReady-related function is the more modern approach, allowing you to define a function that will execute as soon as the DOM is in a usable state, that is to say structurally complete. The main obstacle now is to create a solution that is not dependent on browser detection.

There is something inherently powerful about what direct data interaction and manipulation is capable of and the ease at which it performs. XSLT may be called a stylesheet but it is nothing like CSS, it deals directly in data management and presentation, utilizing advanced functionality typically reserved for a scripting language. Similar to what Smarty is to PHP templates, XSLT basically defines the rules for rendering an XML file, with one important distinction – the data is live. The data is subject to further XSL manipulation after the XML document has been initially transformed, facilitating many dynamic features. This has great implications on the web applications of the future; loading a widget could be as simple as dynamically loading an XML document which contains all settings and instructions, performing an XSLT transformation and appending the result document to the DOM. With those kind of capabilities the potential for such an application is limitless.

Here I will not only be sharing the latest news, resources, tutorials, and tools but it will also serve as a platform. As a long time supporter and beneficiary of the open source community, I figured it was time to give back. The main focus of my projects will be to fill a certain niche market of open source Javascript, that being library independent and free of browser detection.

You see I have a problem with Javascript libraries in general, it has always been my contention that each project deserves its own library containing only required modules. The facilitation of browser sniffing is just the icing on the cake; more often than not I find it a simple means to an end or an unnecessary shortcut, all you have to do is view the source of some of the most popular Javascript libraries to see examples of this. A solution short of checking the user agent is often easier than one might have thought.

In that spirit, I will be releasing various modules that promise to be lightweight, standalone, cross-browser, and contain no browser sniffing whatsoever. Be warned, I don’t like rewarding or encouraging bad programming, so don’t expect me to support your mistakes; if your working without a doctype, that is your problem!

I look foward to future dialog.