views:

124

answers:

7

Is there a JavaScript framework that focuses on extending JavaScript by levelling the implementation differences? I don't mean a framework that simply provides the same functionality across different browsers, but something that makes non-standard browsers behave as if they were standards-compliant.

Basically I want something that does for JavaScript what ie7.js does for MSIE or what html5shiv does for HTML5 elements. Or the various workarounds for Web Sockets or Canvas.

I guess jQuery and its ilk could do the trick, but I'd prefer something that allows me to write normal, standards-compliant JavaScript as if there were no differences between the browsers.

EDIT: As every other answer seems to point out that, yes, jQuery is JavaScript and, yes, most JavaScript frameworks try to improve cross-browser compability, let me clarify what I mean.

The differences between JavaScript implementations across different browsers don't have much to do with the language itself these days. Apart from a few built-in methods missing in older browsers, the types mostly behave the same, too. But there are still differences, especially between the present status quo (Chrome/Firefox/Safari) and legacy versions of MSIE (i.e. MSIE 7). Most notably, the DOM tends to have less-or-more subtle peculiarities to its API.

I don't want just a framework that lets me write JavaScript that works across most browsers. Those are a dime a dozen. I want a thin layer that allows me to write code that works in modern browsers and legacy browsers alike. jQuery, Dojo, etc all go way beyond that and provide their own unique APIs instead of unifying the existing ones.

Saying "use jQuery" is like saying I should use Rich Ajax Platform (or other code generation frameworks) if I want to avoid cross-browser rendering differences. I don't want a "substitute", I want a "bugfix" (not literally).

EDIT2: Just to drive the point home: I'm not looking for just any framework. I'm deeply familiar with jQuery, have tried YUI and am currently considering to give Dojo a try. I don't simply want a "good" framework. I want one that fits my very specific description. It's okay if there isn't anything like it, though it'd be interesting to know why not (i.e. technical reasons, not "everybody's too busy using jQuery").

A: 

You have that with JQuery. Using JQuery gives you the ability to query the DOM with the consistency that is lacking across the different browswer implementations. I'd say that and ajax calls deals with the largest set of issues that people deal with in JavaScript these days.

Achilles
True, but jQuery makes you write jQuery code. The framework I'm looking for would let you write JavaScript "the way it's meant to be" (i.e. plain), but cross-browser.
Alan
@Alan - There is no jQuery code. jQuery is JavaScript (and it uses plain old JavaScript syntax). Most of the cross-browser issues come in when you interact with the DOM which is what makes jQuery selectors so nice.
Justin Niessner
I'm aware jQuery is JavaScript, but it still encourages a particular syntax and code structure that is quite different from plain old JavaScript. That's what I'm referring to. Otherwise the question would be pretty pointless.
Alan
jQuery doesn't 'replace' JavaScript style; it replaces DOM. DOM isn't JavaScript.
Javier
JQuery doesn't use a particular syntax, it's just a fluent interface. If anything JQuery is a DSL for manipulating the DOM.
Achilles
@Achilles - That's the point exactly. It provides its own API instead of unifying the existing one. By "JavaScript" I meant the browser's JavaScript API including the DOM, `XMLHttpRequest` etc. Curious experiments like `skulpt` or `processing.js` aside, the actual language doesn't depend on the framework. But conventional APIs provide too thick a layer for my taste.
Alan
+5  A: 

All JavaScript libraries attempt to "level the playing field" by allowing you to write clean cross-browser compatible JavaScript code.

Some of the most popular:

Prototype

MooTools

Scriptaculous

jQuery (my personal favorite)

Justin Niessner
+1 for putting your favorite in the end :)
Sarfraz
I'd give you a vote for being helpful by pointing me at several decent frameworks, but your answer seems to completely ignore the part where I said what I was looking for in particular. Thanks, though.
Alan
+2  A: 

I don't believe there's a simple "make browsers behave correctly" framework - they all go quite significant degrees beyond this.

That said, there's no value in re-inventing the wheel so it might be wise to invest the time in something like jQuery (perhaps using a custom minimal build), etc. whilst ensuring that there are sensible fallbacks for users with JavaScript disabled.

middaparka
A: 

I'd prefer something that allows me to write normal, standards-compliant JavaScript as if there were no differences between the browsers.

What do you mean by normal? Sure you could try to hack together a library that makes every browser behave like FF and say that's the standard, but you wouldn't really be gaining much. Each browser has inconsistencies and deviations from perfection in javascript features that are annoying, so why stop there as a standard? Why not create a whole new 'standard' of what javascript SHOULD be like: Simple, readable, and consistent across browsers? That's the REAL goal of jquery. :D

CrazyJugglerDrummer
+6  A: 

If you're as minimalist in your thinking as your post suggests, you might try compiling your own micro-library that provides cross-browser functionality for some of the most often annoying divergences, like addEventListener vs. attachEvent, getTagsByClassName vs. no method, scrolling disparities, window dimensions, etc. Most of the Javascript disparities are actually disparities in DOM methods anyway, and the list, while long, doesn't have to be compiled all at once. Add your own cross-browser functions as they come up in your coding.

Short of that, use jQuery.

Robusto
+3  A: 

There is no chance of achieving exactly what you want. IE does not expose the prototypes of DOM nodes, so you have no way to extend them without doing it for each individual node. Also, it's usually (maybe always?) not possible to overwrite existing read-only properties of host objects such as DOM nodes in IE, so you won't be able to fix wrongly-implemented DOM properties on DOM nodes themselves. Even if you just fix DOM methods, you'll still need to call a function to do this every time you get hold of a new node reference:

var el = someNode.nextSibling;
fixUp(el); // Adds missing methods to the element and fixes broken ones
var matchingEls = el.getElementsByClassName("someclass");

For a really good, detailed explanation of why what you want is impossible, I'd recommend having a read of this: http://perfectionkills.com/whats-wrong-with-extending-the-dom/

Tim Down
+1  A: 

When writing "standard" JavaScript, I tend to define my own functions that provide cross-browser implementations of commonly used features. addEvent and removeEvent (there are several implementations) are common examples of this technique. I've researched and written several functions that enable me to call one function for a specific problem, rather than feature-detect and execute the correct code at every turn.

Things like getting height, width, and offset of an element require different implementations for different browsers, but can easily be written into a function and reused wherever you need them.

So, my "solution" is largely a DIY solution. Create a file called "utilities.js" and start adding functions as you need them. addEvent, removeEvent, and a cross-browser XMLHttpRequest are a good place to start. Here, I'll start you off:

function createXHR()
{
    var xhr;
    if (window.ActiveXObject)
    {
        try
        {
            xhr = new ActiveXObject("Microsoft.XMLHTTP");
        }
        catch(e)
        {
            alert(e.message);
            xhr = null;
        }
    }
    else
    {
        xhr = new XMLHttpRequest();
    }

    return xhr;
}

That function will return an XMLHttpRequest object for use as you see fit. Enjoy.

Edit: Do note that this approach could theoretically crowd your namespace quite a bit. You may be best off creating a utilities object, and calling utilities.createXHR.

Ryan Kinal