You Don't Need jQuery!

Beyond jQuery

Mon, 29 Jun 2015 00:00:00 +0000

You asked for more, and I was happy to oblige, because this blog only scratches the surface. On Twitter, and in the discussion sections here, I mentioned that a longer-form version of my YDNjQ series was in progress. Back in early 2015, I began writing a new book titled “Beyond jQuery”. My goal was to greatly expand on the topics I wrote about in this blog. Well, it is finally finished, and it contains much more detail, much more code, and I cover many more topics! It’s 13 chapters, about 300 pages, and contains an accompanying full-stack code repository that touches on much of the material discussed in the book. You can now order a copy of my book on Amazon! Please contact me on Twitter if you have any comments, questions, or requests.

- Ray Nicholus

Utilities

Wed, 21 Jan 2015 00:00:00 +0000

In the sixth and final post of this series, I’m going to cover some of the utility methods that jQuery core provides, and show how you can acheive the same results with vanilla JavaScript. Focus will be on modern browsers, but I’ll also go over achieving the same ends in ancient browsers as well. Modern browsers are considered to be anything newer than and including Internet Explorer 9. Anything older than that is “ancient”.

I know I’ve stated the purpose of this series many times before, and most readers seem to understand. However, I continue to see comments from a few readers who seemed to have missed my point. So, once again, I am writing these posts to teach about the Web API and JavaScript as a language. If you really want to continue using jQuery, have at it. If not, these posts will hopefully give you the confidence and knowledge you need to remove this dependency from your future projects. At the very least, by reading all of this, you will gain a better understanding of the Web API and JavaScript as a language, which is important to your evolution as a web developer (whether you use jQuery or not).

All vanilla JavaScript code below will work in all browsers, unless otherwise noted. As always, edge cases not described here are always possible (both with and without jQuery), as this is the nature of software.

Is this an Object, Array, or a Function?
Combine and copy objects
Iterate over object properties
Iterate over array elements
Find an element in an array
Turn a pseudo-array into a real array
Modify a function
Trim a string
Associate data with an HTML element
Next

Is this an Object, Array, or a Function?

Due to the fact that JavaScript follows weak and dynamic value typing, you may find the need to check the type of a value and react accoringly based on the actual type. What follows is code that can help you achieve this goal in both jQuery and vanilla JavaScript.

jQuery

jQuery provides a few functions to identify a value as either an Object, Array, or a Function. They are appropriately and intuitively named. Each function returns a boolean.

$.isFunction(someValue);

$.isPlainObject(someValue);

$.isArray(someValue);

vanilla JavaScript

To determine if a value is a function, we can make use of the typeof operator.

// is this a function?
typeof someValue === 'function';

Determining if a value is an object is a bit less intuitive, but still doable in one line. We must include a null-check as some browsers will report null as an Object. The second half of the check uses the toString function of the Object prototype on the value to be tested.

// is this an object?
someValue != null &&
    Object.prototype.toString.call(someValue) === "[object Object]";

Checking for an Array is similar (but simpler) than the check for an Object. Plus, you’ll see that a convenience method exists as an alternative for modern browsers.

// works in modern browsers
Array.isArray(someValue);


// works in all browsers
Object.prototype.toString.call(someValue) === "[object Array]";

Combine and copy objects

Suppose you have two objects, o1, and o2:

var o1 = {
        a: 'a',
        b: {
            b1: 'b1'
        }
    },

    o2 = {
        b: {
            b2: 'b2'
        },
        c: 'c'
    };

What if you want to take o2 and append it to o1, or create a new object that is the aggregate of both objects? The combined object should look like this:

{
    a: 'a',
    b: {
        b1: 'b1',
        b2: 'b2'
    },
    c: 'c'
}

jQuery

// updates o1 with the contents of o2
$.extend(true, o1, o2);

// creates a new object that is the aggregate of o1 & o2
var newObj = $.extend(true, {}, o1, o2);

If we just want to create a copy of one of the objects, we can do that too, also using $.extend:

var copyOfO1 = $.extend(true, {}, o1);

vanilla JavaScript

Accomplishing this task without jQuery involves iterating over the properties in o2. For each property with an object value, we’ll need to iterate over that too, making a recursive call. As we encounter non-object values in o2, we’ll assign them to the corresponding property in o1.

// our helper function
function extend(first, second) {
    for (var secondProp in second) {
        var secondVal = second[secondProp];
        // Is this value an object?  If so, iterate over its properties, copying them over
        if (secondVal && Object.prototype.toString.call(secondVal) === "[object Object]") {
            first[secondProp] = first[secondProp] || {};
            extend(first[secondProp], secondVal);
        }
        else {
            first[secondProp] = secondVal;
        }
    }
    return first;
};

// example use - updates o1 with the content of o2
extend(o1, o2);

// example use - creates a new object that is the aggregate of o1 & o2
var newObj = extend(extend({}, o1), o2);

As you can see above, we can create a new object that contains the combination of o1 and o2, without modifying either of the source objects, simply by creating a copy of o1, and extending that with the properties of o2. In case you missed it, here’s a simpler example that focues specifically on copying o1:

var copyOfO1 = extend({}, o1);

Note: the simple code used above to iterate over object properties is fine for this example, but you may want to read the next section, which covers iterating over object properties for a more complete understanding of how this should be done with vanilla JavaScript.

Iterate over object properties

Let’s say we have the following Object, called parentObject:

var parentObject = {
    a: 'a',
    b: 'b'
};

…and then we create myObject, which inherits the properties of parentObject:

var myObject = Object.create(parentObject);
myObject.c = "c";
myObject.d = "d";

Now, myObject has 4 properties, but only ‘c’ and ‘d’ belong to myObject. Properties ‘a’ and ‘b’ are part of parentObject, which is on the same prototype chain as myObject. Most likely, when we want to iterate over the properties of myObject, we only want the properties that belong to this object, and not any that belong to parentObject.

jQuery

$.each(myObject, function(propName, propValue) {
    // handle each property...
});

The above code will iterate over all of the myObject properties, ignoring any properties that do not directly belong to myObject.

vanilla JavaScript

In the previous section, while discussing copying and combining objects, I included a barebones method of iterating over an object’s properties. In case you need to deal with something more complex or want to exploit native approaches available in modern browsers, I’ll go over some other approaches, as well as some things you should be aware of when dealing with object property iteration.

For reference, here is the simple for...in loop presented in the “Combine & Copy Objects” section, now iterating over myObject:

for (var myObjectProp in myObject) {
    // deal with each property in the `myObject` object...
}

So, if we outputted every property encountered by the loop above, we’d see the properties on myObject, as well as the properties of parentObject. Remember, parentObject and myObject are on the same prototype chain, and myObject inherits all of the properties from parentObject. But, this is not what we want. We only want the properties that myObject owns! To acheive this, we need to exclude any other properties, and this can be done via the hasOwnProperty method.

// works in all browsers
for (var prop in myObject) {
    if (myObject.hasOwnProperty(prop)) {
        // deal w/ each property that belongs only to `myObject`...
    }
}

All objects have a hasOwnProperty method, as this method is available on Object.prototype.

But wait! There’s another solution, specific to modern browsers. ECMAScript 5 defines a new function: Object.keys(someObj), which returns an array of properties on the passed object. Also, this array will only contain the properties owned by the passed object.

// works in modern browsers
Object.keys(myObject).forEach(function(prop) {
    // deal with each property that belongs to `myObject`...
});

Note that I’m using forEach on the returned array of property names above. I’ll talk more about iterating over arrays in the next section.

Iterate over array elements

Given an array, like this:

var myArray = ['a', 'b', 'c'];

…we’d like to be able to simply iterate over each of the elements in this array.

jQuery

Iterating over arrays in jQuery is a lot like iterating over object properties. In both cases, just use the jQuery.each method:

$.each(myArray, function(arrayIndex, arrayValue) {
    // handle each array item...
});

vanilla JavaScript

This isn’t much harder without jQuery, regardless of the browser. We can simply iterate over the elements in the array using a simple for loop:

// works in all browsers
for (var index = 0; i < myArray.length; i++) {
    var arrayVal = myrray[index];
    // handle each array item...
}

But that doesn’t look nearly as nice as jQuery, does it? ECMAScript 5 to the rescue again! We can make use of Array.prototype.forEach in modern browsers instead:

// works in modern browsers
myArray.forEach(function(arrayVal, arrayIndex) {
    // handle each array item
}

Notice that the order of the parameters passed to your callback function by Array.prototype.forEach differs from that of jQuery.each. I actually prefer the ordering used by forEach as it allows me to omit the index parameter if I only care about the values. Note that there are a lot of other useful functions on Array.prototype in ES5 and beyond.

Find an element in an array

Here’s I’ll cover two similar operations on an array:

Find the index of an array that contains a specific value.
Find all elements in an array that satisfy a particular condition.

Let’s again use a simple array:

var theArray = ['a', 'b', 'c'];

jQuery

To find the index of an array for a specific value, we can use the inArray function:

var indexOfValue = $.inArray('c', theArray);

indexOfValue will be -1 if the value represented by the first parameter, 'c', is not found in theArray. Otherwise, it will be the index of theArray where the passed value was found. In this case, that index is 2.

If we want to use jQuery to find all elements in an array that satisfy a particular condition, we can use the grep function:

var allElementsThatMatch = $.grep(theArray, function(theArrayValue) {
    return theArrayValue !== 'b';
});

allElementsThatMatch will equal ['a', 'c'] as our filter function excludes any value that matches ‘b’.

vanilla JavaScript

If you’d like to find the index of an array for a specific value, AND you are using a modern browser, you can make use of the Array.prototype.indexOf method:

// works in modern browsers
var indexOfValue = theArray.indexOf('c');

Sadly, the indexOf method didn’t come about until ECMAScript 5. So, if you are suffering with a requirement to support an ancient browser, such as IE 8, you must iterate over the elements of the array, using a for loop, until you find the desired element. For example:

// works in all browsers
function indexOf(array, valToFind) {
    var foundIndex = -1;
    for (var index = 0; index < array.length; index++) {
        if (array[index] === valToFind) {
            foundIndex = index;
            break;
        }
    }
    return foundIndex;
}

// example use
indexOf(theArray, 'c');

If you want to find all values that satisfy a specific condition in vanilla JS, you can make use of the shiny new Array.prototype.filter method in ES5:

// works in modern browsers
var allElementsThatMatch = theArray.filter(function(theArrayValue) {
    return theArrayValue !== 'b';
});

That actually looks a bit nicer than jQuery’s grep method!

If you need to deal with ancient browsers, such as IE 8, you’ll need to write a bit more code:

// works in all browsers
function filter(array, conditionFunction) {
var validValues = [];
    for (var index = 0; index < array.length; i++) {
        if (conditionFunction(theArray[index])) {
            validValues.push(theArray[index]);
        }
    }
}

// use example
var allElementsThatMatch = filter(theArray, function(arrayVal) {
    return arrayVal !== 'b';
})

Turn a pseudo-array into a real array

In JavaScript, there are real arrays:

var realArray = ['a', 'b', 'c'];

…and “pseudo”-arrays:

var pseudoArray1 = {
    1: 'a',
    2: 'b',
    3: 'c'
    length: 3
};

There are some native pseudo-arrays as well, such as NodeList, HTMLCollection, and FileList, to name a few. These are not real arrays in that they are not on the same prototype chain as Array. That is, they inherit nothing from Array.prototype because they are not arrays. In fact, they are just objects. But, due to the length property, you can treat them as an array, in some respects, by iterating over their “elements” using a for loop, just as you would any real array.

If you are dealing with a pseudo-array in an ancient browser, such as IE 8, it probably doesn’t matter much, since you’ll need iterate over the properties/elements using a for loop whether it is a real array or not. But, suppose you are using a modern browser, and you want to make this object that looks very much like an array act like an array. Perhaps you want to use forEach, or map, or filter. Or perhaps you must pass it to an API method that expects a real array.

jQuery

You can convert a pseudo-array to a real array in jQuery using the makeArray method:

var realArray = $.makeArray(pseudoArray);

vanilla JavaScript

If you’d like to transform a pseudo-array to a real array, and make all methods on Array.prototype available, you can use this trick:

var realArray = [].slice.call(pseudoArray);

If you only care to use a specific array method on a pseudo-array, such as forEach you can do this instead:

[].forEach.call(pseudoArray, function(arrayValue) {
    // handle each element in the pseudo-array...
});

Why does this work? There’s an excellent Stackoverflow answer that provides a nice explanation.

Modify a function

There are two ways to modify an existing function:

Change its context.
Create a new function with some pre-determined arguments.

In both cases, you would want to take an existing function and create a new function based on the original.

1 - Change a function’s context

To demonstrate #1, let’s propose we have an event handler. By default, the context of an event handler in modern browsers and jQuery is the element that started the event (except for inline event handlers, which are a bad idea anyway). But what if you want your event handler to assume a different context? For example, say you have some public instance variables attached to the context of a function, and you want to have easy access to these variables inside your event handler:

function Outer() {
    var eventHandler = function(event) {
        this.foo = 'buzz';
    }

    this.foo = 'bar';
    // attach `eventHandler`...
}

var outer = new Outer();
// event is fired, triggering `eventHandler`

Without any changes, outer.foo === 'bar'. Since the foo property is being set in the context of an event handler, the element that triggered the event is actually receiving a foo property with a value of ‘buzz’. But we want outer.foo === 'buzz'!

jQuery

It is possible to re-assign the context of a function in jQuery using the proxy function. To make this work, we simply need to wrap the function in a call to jQuery’s proxy utility method:

function Outer() {
    var eventHandler = $.proxy(function(event) {
        this.foo = 'buzz';
    }, this);

    this.foo = 'bar';
    // attach `eventHandler`...
}

var outer = new Outer();
// event is fired, triggering `eventHandler`

Now, when the event handler is triggered, outer.foo === 'buzz'.

vanilla JavaScript

Modern browsers provide a bind function on Function.prototype. This allows you to change the context of a function, just like jQuery’s proxy, but in a slightly more elegant way:

// works in modern browsers
function Outer() {
    var eventHandler = function(event) {
        this.foo = 'buzz';
    }.bind(this);

    this.foo = 'bar';
    // attach `eventHandler`...
}

var outer = new Outer();
// event is fired, triggering `eventHandler`

We simply call bind on the function, pass the desired context, and the resulting function assigned to eventHandler is associated with the context of our Outer function, which means outer.foo === 'buzz' when the event handler is ultimately invoked inside our Outer instance.

If you must support an ancient browser, like IE 8, you’ll need to take one of two alternate approaches. The first involves adding an implementation of bind to Function.prototype if the browser does not provide a native implementation (such as with IE 8 and older). Mozilla Developer Network provides some code for such a polyfill. I’m not going to repeat the code here, as it is displayed quite nicely on MDN. Simply invoking that function on page load will ensure that a bind utility function will be available for all functions. Another option is to take a completely different approach, and store the value of this in a variable inside of the Outer function. You can then reference that variable (instead of this) inside of eventHandler to ensure the correct property is updated. For instance:

// works in all browsers
function Outer() {
    var self = this,
        eventHandler = function(event) {
            self.foo = 'buzz';
        };

    this.foo = 'bar';
    // attach `eventHandler`...
}

var outer = new Outer();
// event is fired, triggering `eventHandler`

When the eventHandler is invoked, our instance of Outer, represented by the outer variable, will contain the expected value of foo, which is ‘buzz’. This is a feasible solution in all browsers.

2 - Create a new function with some pre-determined arguments

Another way to phrase the method demonstrated here is “partial function application” or “currying”. Instead of silly pointless examples involving functions that add numbers together, let’s try to demonstrate something at least a bit more realistic.

Say we have a utility function that is part of a shared library used among many of our applications. This function logs messages to a remote server for aggregation and further evaluation. The function takes an application ID, a level (such as “info” or “error”), and a log message. It looks like this:

function log(appId, level, message) {
    // send message to central server
}

We’ve pulled in the shared library containing this function into our app, and our application has an ID of “master-shake”. Now, every time we log a message in our app, do we really want to pass the same first parameter, our app ID, which never changes? We certainly could, or, we can create a new function that fills in this parameter automatically for us. In other words, we want to call a function and only pass in the variable data: the level and message, with the same end result.

jQuery

As before, we’ll use jQuery’s proxy function:

var ourLog = $.proxy(log, null, 'master-shake');

// example use
ourLog('error', 'dancing is forbidden!');

Invoking ourLog will more or less pass the application ID (“master-shake”), as well as the specified error and message, to the original function.

vanilla JavaScript

We can again use the bind function for modern browsers. As before, if an ancient browser is required, a shim can be used to help us out.

var ourLog = log.bind(null, 'master-shake');

// example use
ourLog('error', 'dancing is forbidden!');

You’re probably wondering about the significance of the null parameter we’ve passed to jQuery’s proxy and native JS’s bind function. We don’t care much about context in this example, but passing null as the context to bind will set the value of this inside the bound function to the global function (window if we’re in a browser). In the case of jQuery’s proxy function, a null context parameter (at least as of jQuery 1.9) means that the proxied function will assume a value of this equal to the context of the calling function.

Trim a string

Given this string:

"  hi there!   "

We want to trim all of the leading and trailing whitespace to produce this:

"hi there!"

jQuery

We can using jQuery’s trim function to do this:

$.trim('  hi there!   ');

The string, sans leading & trailing whitespace, will be returned by the function call above.

vanilla JavaScript

In modern browsers, we can use the trim function on String.prototype:

// works in modern browsers
'  hi there!   '.trim();

For ancient browsers, we aren’t so lucky, and have to resort to a regular expression to remove the leading and trailing spaces:

// works in all browsers, but needed in IE 8 and older
'  hi there!   '.replace(/^\s+|\s+$/g, '');

You can roll this into a function that will use the trim method if it exists, else the regexp if we’re dealing with an ancient browser:

// works in all browsers
function trim(string) {
    if (string.trim) {
        return string.trim();
    }
    return string.replace(/^\s+|\s+$/g, '');
}

Associate data with an HTML element

You may find yourself wishing to track data (objects, strings, numbers, and even other elements) in the context of a specific HTML element. The safest way to do this, cross browser, to avoid memory leaks associated with circular references between elements, is to not attach this data directly to the element’s associated JavaScript object as a property. If you’re only tracking string, number, or simply object values, then this isn’t much of an issue, but once you involve elements as data values as well, older browsers may spring memory leaks. For more information on that, feel free to read Joel Webber’s old but interesting points on the subject.

To keep things simple, straightforward, and safe, we’re going to avoid storing anything other than strings and numbers directly on the element. So, we’ll need to tag our elements with an ID/key, and attach that key to our data in an object maintained in a data store apart from the element.

Let’s say we have two elements, and when we click on one, we want the other to be either hidden or made visible (the opposite of its current state).

<div id="one">one</div>
<div id="two">two</div>

This example is a bit contrived, admittedly, but it illustrates our topic rather simply.

jQuery

jQuery’s data method will create an ID for each element we want to tag with data, add that ID as a property to the element’s JavaScript object, and use that ID to tie the element to the data in a central object maintained by the library.

// make the elements aware of each other
$('#one').data('partnerElement', $('#two'));
$('#two').data('partnerElement', $('#one'));

// on click, either hide or show the partner element
$('#one, #two').click(function() {
    $(this).data('partnerElement').toggle();
});

vanilla JavaScript

There are a couple ways to do this in vanilla JS. The first will work in all browsers, but requires a bit more code. For this first approach, let’s create a couple functions. One will tag an element with an ID and store that ID along with the data in an object. The other will retrieve data, given an element:

// works in all browsers
var data = (function() {
    var lastId = 0,
        store = {};

    return {
        set: function(element, info) {
            var id;
            if (element.myCustomDataTag === undefined) {
                id = lastId++;
                element.myCustomDataTag = id;
            }
            store[id] = info;
        },

        get: function(element) {
            return store[element.myCustomDataTag];
        }
    };
}());

…and now let’s use it based on our previously stated requirements:

// make the elements aware of each other
var one = document.getElementById('one'),
    two = document.getElementById('two'),
    toggle = function(element) {
        if (element.style.display !== 'none') {
            element.style.display = 'none';
        }
        else {
            element.style.display = 'block';
        }
    };

data.set(one, {partnerElement: two});
data.set(two, {partnerElement: one});

// on click, either hide or show the partner element
// remember to use `attachEvent` in IE 8 and older, if support is required
one.addEventListener('click', function() {
    toggle(data.get(one).partnerElement);
});
two.addEventListener('click', function() {
    toggle(data.get(two).partnerElement);
});

Yes, this is a hell of a lot more code than the jQuery example. I know. Remember, this is about understanding JavaScript, not necessarily about counting lines of code. But the awesome thing about JavaScript as a language is that it continues to evolve and make our lives easier. ECMAScript 6 brings a new collection, called a WeakMap. A WeakMap can contain keys that are objects, and values that are anything. Keys are “weakly” held by the collection. This means that they are eligible for garbage collection by the browser if nothing else references them. So, we can use the reference elements as keys!

While WeakMap is only supported in the latest and greatest browsers (IE 11+, Chrome 36+, Safari 7.1+) and Firefox 6+, we can perhaps make use of it if the browser provides such support. If we rely only on the WeakMap, we can eliminate our data helper entirely, and our entire set of code looks like this instead:

// works only in the latest browsers
// make the elements aware of each other
var weakMap = new WeakMap(),
    one = document.getElementById('one'),
    two = document.getElementById('two'),
    toggle = function(element) {
        if (element.style.display !== 'none') {
            element.style.display = 'none';
        }
        else {
            element.style.display = 'block';
        }
    };

weakMap.set(one, {partnerElement: two});
weakMap.set(two, {partnerElement: one});

// on click, either hide or show the partner element
// remember to use `attachEvent` in IE 8 and older, if support is required
one.addEventListener('click', function() {
    toggle(weakMap.get(one).partnerElement);
});
two.addEventListener('click', function() {
    toggle(weakMap.get(two).partnerElement);
});

Of course, we can’t rely entirely on WeakMap, yet (unless we only support IE 11+). So, we’ll probably instead want to continue to use our data provider, relying on WeakMap only if the browser provides an implementation:

// works in all browsers
var data = window.WeakMap ? new WeakMap() : (function() {
    var lastId = 0,
        store = {};

    return {
        set: function(element, info) {
            var id;
            if (element.myCustomDataTag === undefined) {
                id = lastId++;
                element.myCustomDataTag = id;
            }
            store[id] = info;
        },

        get: function(element) {
            return store[element.myCustomDataTag];
        }
    };
}());

“You Don’t Need jQuery (anymore)!” is complete! I hope you’ve found some use in these posts. I personally have enjoyed the format of this blog, and I think a series of posts about a central topic is interesting and useful in other instances.

I plan to write another similar blog series next, this time covering cross-domain browser-based communication. Some of the posts in that series will likely cover: the same-origin policy, CORS, JSONP, the Web Messaging API, and content security policies, among other topics. Stay tuned, and I’ll be sure to link to the new blog after I’ve completed the first post.

Events

Thu, 18 Dec 2014 00:00:00 +0000

In this fifth installment of “You Don’t Need jQuery (anymore)”, I’m going to talk about dealing with events in the browser without jQuery. As always, each section will cover the jQuery approach, followed by a solution using the native Web API instead. After reading this post on events, you should be confident enough to deal with events in your own project without using jQuery.

As I’ve mentioned (many times) before, this blog is not about bad-mouthing jQuery. jQuery is, without a doubt, ubiquitous in the world of web development. In the earlier days of web development, jQuery was required to smooth out the significant implementation differences and bugs found in various browsers when dealing with the DOM and the Web API as a whole. Also, the Web API was quite primitive at the time, in some respects, and jQuery helped to make development a bit more intuitive.

Browsers, and the Web API, have come a long way in the last several years. You can do a lot without jQuery, and I have mostly avoided jQuery in my new projects for the last several years. The jQuery approach may take less keystrokes, or look a bit more elegant in some cases. That’s fine, but the point of this blog isn’t to help you reduce the number of keystrokes, or write more beautiful code.

My last few posts covered selecting elements, DOM manipulation, and ajax requests. In those instances, the Web API is fairly elegant, and not much is gained by using jQuery. However, when dealing with events, the Web API is admittedly lacking in the elegance and convenience departments, even in modern browsers in some cases. That’s ok, because this blog is about helping you understand the Web API so that you can avoid blindly depending on jQuery to develop your web applications. When you rely on a library to develop a large part of your application, you had better understand how the low-level API works. Otherwise you will find troubleshooting unexpected behaviors that will inevitably pop up from time to time to be quite frustrating. Keep in mind that jQuery has bugs of its own.

This post on events will primarily focus on event handling in modern browsers. We’re going to define modern browsers as anything newer (and including) Internet Explorer 9. This is a commonly accepted definition, in my experience. That said, this post on events will also illustrate how jQuery was especially important when Internet Explorer 8 was commonly supported, and how you you likely will want to consider pulling in a events library, or even jQuery, to assist if you are in the unusual and unfortunate position to require support for Internet Explorer 8 or older in a new web application.

Keep in mind that the examples, descriptions, and comparisons below do not represent exhaustive references. This is all just something to help you understand what the Web API provides. Both jQuery and the Web API allow you to perform much more complex operations than the ones demonstrated here. I am merely supplying you with the basic knowledge/building blocks required to build something much more complex.

Sending Native (DOM) Events
Sending Custom Events
Listening For Events
Removing Event Handlers
Modifying Events
Event Delegation
Keyboard Events
Mouse Events
Browser Load Events
Ancient Browser Support
Libraries to Consider
Next in this Series

Sending Native (DOM) Events

We’ll start out simple here with DOM events, that is, events that are defined as part of the Document Object Model in the W3C (World Wide Web Consortium) specification.

Let’s say we have an anchor tag, and we want to programmatically click it using JavaScript.

jQuery

$(anchorElement).click();

Well, that was pretty easy! If we really want to do this the jQuery way (for whatever reason) we need to wrap the element so we can access jQuery’s API, of course.

Web API

anchorElement.click();

The above code will work in any browser available today (even IE6). jQuery certainly doesn’t help us here. The code follows the same intuitive syntax if we want to trigger some other DOM events, such as focus and blur, or submit on a <form>.

Sending Custom Events

We have an event, “my-custom-event” that we need to trigger. This event must bubble by default, and must be cancellable by a handler.

jQuery

$('some-element').trigger('my-custom-event');

The above code will fire the custom event starting with the someElement element. The event will bubble up the DOM by default. jQuery actually walks the event up the DOM itself, triggering any jQuery-specific event handlers and/or functions on each element that correspond to the event name (such as click() for a “click” event).

Web API

var event = document.createEvent('Event');
event.initEvent('my-custom-event', true, true); //can bubble, and is cancellable
someElement.dispatchEvent(event);

The above code will work in all browsers. But, the createEvent method on document has, for the most part, been deprecated. All browsers, to my knowledge, continue to support it though.

The more “modern” approach involves using the CustomEvent constructor:

var event = new CustomEvent('my-custom-event', {bubbles: true, cancelable: true});
someElement.dispatchEvent(event);

Unfortunately, the CustomEvent constructor is not supported in any version of Internet Explorer to date. This will work in all other modern browsers though. If you need to support Internet Explorer (and we all do) you will need fall back to the initial example in this section. For the most part, it is probably best to continue to use createEvent if it is supported by the browser. If newer browsers begin to remove createEvent from their implementation of the Web API, you should be able to easily detect this and use CustomEvent instead.

Listening For Events

The syntax required to consume an event, DOM or custom, is very similar for modern browsers between the jQuery and native approaches. For this example, we will set up some code that will notify us when an element we’re interested in has been clicked (either programmatically or via user interaction):

jQuery

$(someElement).on('click', function() {
    // TODO event handler logic
});

You can also make use of the click method, which allows you to register an event handler if the first argument is a handler function:

$(someElement).click(function() {
    // TODO event handler logic
});

Web API

As mentioned before, the syntax for registering an event handler using the native browser API in modern browsers (which includes IE9) is refreshingly similar to jQuery:

someElement.addEventListener('click', function() {
    // TODO event handler logic
});

Note that all elements (for the most part) inherit from the Node interface, which itself inherits from the EventTarget interface. The first version of Internet Explorer that includes support for the addEventListener method on the EventTarget interface is IE9.

Removing Event Handlers

Whether you use jQuery or vanilla JavaScript, you must keep track of your original event handler function in order to un-register it. While jQuery provides a convenience method to remove “all” event handlers of a particular type from a specific element, it is important to understand that this will only remove any event handlers that were attached to that element via jQuery (ignoring any that may have been attached directly via addEventListener). This is due to the fact that the Web API does not provide any way to obtain a list of registered event handlers, nor does it provide a way to blindly remove all event handlers attached to an element.

So, let’s say we’ve previously attached the following click event handler to an element:

var myEventHandler = function(event) {
    // handles the event...
}

…and we now want to remove it:

jQuery

$('some-element').off('click', myEventHandler);

Web API

someElement.removeEventListener('click', myEventHandler);

Modifying Events

The ability to modify an event generally refers to augmenting or squelching the event by one event handler before it reaches other event handlers.

Preventing the event from bubbling further up the DOM

Here, we want to ensure the event, caught by our event handler, will not reach any additional event handlers positioned on ancestor elements. This will stop the event from bubbling up the DOM.

jQuery

$(someEl).on('some-event', function(event) {
    event.stopPropagation();
});

Web API

someEl.addEventListener('some-event', function(event) {
    event.stopPropagation();
});

The syntax between jQuery and the modern Web API here is almost identical.

Preventing the event from hitting any additional handlers attached to the current element

Not only do we want to prevent this event from hitting any handlers bound to elements that are ancestors of this one, but we also want to ensure no other event handlers bound to this element are hit either. So, we want to prevent the event from hitting any further event handlers.

jQuery

$(someEl).on('some-event', function(event) {
    event.stopImmediatePropagation();
});

Web API

someEl.addEventListener('some-event', function(event) {
    event.stopImmediatePropagation();
});

Again, the syntax between jQuery and the modern Web API here is eerily similar.

Preventing the event from triggering an action defined by the browser

Let’s say we have the following element:

<a href="http://fineuploader.com">Go to Fine Uploader</a>

…and we want to prevent a click on this anchor from opening the associated page. This will involve adding a click handler to the anchor element and instructing the browser to not execute the its native/default action.

jQuery

$(someAnchor).on('click', function(event) {
    event.preventDefault();
});

Web API

someAnchor.addEventListener('click', function(event) {
    event.preventDefault();
});

Are you seeing a pattern here? The syntax required to deal with events is starting to look about the same between jQuery and the Web API.

Event Delegation

Suppose you have a list filled with list items that are sensitive to mouse clicks. You could attach a click handler to each individual list item. However, this may be inefficient and slow down your page with a large number of list items. Suppose items are added to this list dynamically. Now attaching a new event handler to each new list item, as it is added, becomes less appealing.

The solution here is event delegation. That is, attach one click handler to the list. When any of the list items are clicked, the event will bubble up to its parent, the list container element. At this point, your one event handler will be hit and you can easily determine, by inspecting the event object, which list item was clicked and respond appropriately.

The markup for such a list may look like this:

<ul id="my-list">
    <li>foo <button>x</button></li>
    <li>bar <button>x</button></li>
    <li>abc <button>x</button></li>
    <li>123 <button>x</button></li>
</ul>

If the user clicks on the “x” button, the list item should be removed from the list.

jQuery

jQuery will set the context of our handler to the element that initially received the click (the <button>). Also, only <button> elements inside this list will be examined.

$('#my-list').on('click', 'BUTTON', function() {
    $(this).parent().remove();
});

Web API

We have to write a couple more lines of code without jQuery, but this still isn’t exactly rocket science. The Web API always sets the context of the event handler to the element receiving the click event, which in this case is the list container element. Instead, we need to know which element was initially clicked, which is available in the target property of the provided Event object. We must also ensure that we only act on <button> clicks.

document.getElementById('my-list').addEventListener('click', function(event) {
    var clickedEl = event.target;
    if(clickedEl.tagName === 'BUTTON') {
       var listItem = clickedEl.parentNode;
       listItem.parentNode.removeChild(listItem);
    }
});

Remember, this isn’t about elegant code, it’s about exploring and understanding the Web API. After all, jQuery is just a Web API wrapper.

Keyboard Events

In this section, I’ll show how to handle various keyboard events. I’ll also show how to identify which specific key was pressed by the user.

First, we should take a moment to be sure we understand the difference between the three different types of general keyboard events:

keydown: Key has been pressed but not yet released. No default action has been performed yet.
keypress: Key has been pressed and a character has registered. This event will fire continuously if the key is held down.
keyup: Pressed key has been released.

Let’s say we are building a web application and want to make an interactive tutorial that we’ve build accessible via an intuitive keyboard shortcut. Anywhere in the application, our users should be able to pull up our help widget via the Ctrl-H key combination.

jQuery

$(document).keydown(function(event) {
    if (event.ctrlKey && event.which === 72) {
        // open help widget
    }
});

Web API

document.addEventListener('keydown', function(event) {
    if (event.ctrlKey && event.which === 72) {
        // open help widget
    }
});

Nothing is obviously gained, in this instance, with jQuery. Even the syntax is almost identical between the Web API and jQuery.

Registering for other keyboard events follows a similar pattern:

jQuery

$(someElement).keypress(function(event) {
    // ...
});

$(someElement).keyup(function(event) {
    // ...
});

Web API

someElement.addEventListener('keypress', function(event) {
    // ...
});

someElement.addEventListener('keyup', function(event) {
    // ...
});

For more information about keyboard event properties and browser compatibility among the properties of this event, have a look at the KeyboardEvent document on Mozilla Developer Network.

Mouse Events

There are a number of mouse events provided by the Web API, such as “mousedown”, “mouseenter”, and “mouseover” (to name a few). It isn’t particularly interesting to show how to register for and handle these events in jQuery and the Web API. Much like keyboard events, the syntax between the two is almost identical.

Instead, I’m going to focus on one special event that is part of jQuery’s API. Of course, the goal here is to create your own code by using the plain ‘ole Web API sans jQuery. I’ll show you how to do that too.

jQuery’s `hover` event

jQuery provides a way to notify you when a mouse pointer has hovered over a specific element, and then again when the mouse pointer leaves this element. For example:

$('some-element').hover(
    function hoverIn() {
        // mouse is hovering over this element
    },

    function hoverOut() {
        // mouse was hovering over this element, but no longer is
    }
);

We can do the same thing with the Web API pretty easily:

someEl.addEventListener('mouseover', function() {
    // mouse is hovering over this element
});

someEl.addEventListener('mouseout', function() {
    // mouse was hovering over this element, but no longer is
});

As I mentioned earlier, mouse events are fairly straightforward to handler with the Web API. For more information on mouse events, have a look at the MouseEvent interface documentation on the Mozilla Developer Network.

Browser Load Events

When talking about “load” events in the browser, we may be trying to answer any one of the following questions:

When have all elements on the page fully loaded and rendered w/ applied styles?

This event should be fired after:

all markup has been placed on the page
all stylesheets have been loaded
all images have loaded
all iframes have fully loaded

jQuery

$(window).load(function() {
    // page is fully rendered
})

Web API

window.addEventListener('load', function() {
    // page is fully rendered
});

When has all static markup been placed on the page?

This event should fire after all markup has been placed on the page.

jQuery

$(document).ready(function() {
    // markup is on the page
});

Note that you can also achieve the same thing in jQuery this way:

$(function() {
    // markup is on the page
});

Web API

document.addEventListener('DOMContentLoaded', function() {
    // markup is on the page
});

Note that you will likely want to ensure your script that registers the DOMContentLoaded event handler is placed before any stylesheet <link> tags, since loading these stylsheets will block any script execution and prolong the DOMContentLoaded event until the defined stylesheets have loaded.

When has a particular element on the page fully loaded?

In addition to window, load events are associated with a number of elements, such as <img>, <link>, and <script>. The most common use of this event outside of window is to determine when a specific image has loaded.

jQuery

$('img').load(function() {
    // image has successfully loaded
});

You can also determine if the image has failed to load:

$('img').error(function() {
    // image has failed to load
});

Web API

img.addEventListener('load', function() {
    // image has successfully loaded
});

And if the image should fail to load?

img.addEventListener('error', function() {
    // image has failed to load
});

As we’ve seen many times before, the syntax between jQuery and the Web API here for modern browsers is strikingly similar.

Ancient Browser Support

This is where I talk about a time when jQuery was indeed a required library for web applications. Back when it was common to support IE8 or something even older. Back then, the Web/DOM API was a bit of a mess in some instances. This was especially true when dealing with events. Below, I’m going to briefly discuss some of the ways you can deal with events using vanilla JavaScript in older browsers. I’m going to limit this to IE7 and IE8. IE6 is mostly dead at this point anyway. Though many, if not all, of these examples should apply to IE6 as well.

Listening For Events

someElement.attachEvent('onclick', function() {
    // TODO event handler logic
});

You’ll notice two distinct differences between this and the modern browser approach.

We must rely on attachEvent instead of addEventListener.
The event name must include a prefix of “on”.

Maybe you’re wondering how you can easily and programmatically use the correct event handling method, based on the browser’s capabilities. For most of us developing apps exclusively for modern browsers, this isn’t a concern. But if, for some reason, you must target ancient browsers, such as IE8 (or older), you can use the following code to register for an event in any browser:

function registerHandler(target, type, callback) {
    var listenerMethod = target.addEventListener || target.attachEvent,
        eventName = target.addEventListener ? type : 'on' + type;

    listenerMethod(eventName, callback);
}

// example use
registerHandler(someElement, 'click', function() {
    // TODO event handler logic
});

One more thing: if you want to remove an event handler in IE8 and older, you must use detachEvent instead of removeEventListener. So, a cross-browser way to remove an event listener may look like this:

function unregisterHandler(target, type, callback) {
    var removeMethod = target.removeEventListener || target.detachEvent,
        eventName = target.removeEventListener ? type : 'on' + type;

    removeMethod(eventName, callback);
}

// example use
unregisterHandler(someElement, 'click', someEventHandlerFunction);

Form Field Change Events

Older versions of IE have some serious change-event deficiencies. Here are the two big ones that come to mind:

Change events do not bubble.
Checkboxes and radio buttons may not trigger a change event at all.

It’s important to know that the 2nd issue above was also reproducible when using jQuery with IE7/8 for quite a long time. As far as I can tell, current versions of jQuery (~1.10+) do properly address this issue though.

To solve issue #1, you must attach a change handler directly to any form field that you’d like to monitor. Event delegation is not possible. For issue #2, you’re best bet may be to attach a click handler to radio/checkbox fields instead of relying on the change event.

The Event Object

Some properties of the Event object instance are a bit different in older browsers. For example, while the target of the event in modern browsers can be found by checking the target property of the Event instance, IE8 and older contain a different property for this element, named srcElement. So, now your cross-browser event handler looks like this:

function myEventHandler(event) {
    var target = event.target || event.srcElement

    // handle event & target
}

In terms of controlling your events, the stopPropagation method is not available on an Event object instance in IE8 and older. If you want to stop an event from bubbling, you must instead set the cancelBubble property on the event. A cross-browser solution would look like this:

function myEventHandler(event) {
    if (event.stopPropgation) {
        event.stopPropagation();
    }
    else {
        event.cancelBubble = true;
    }
}

IE8 and older also do not have a stopImmediatePropagation method. There isn’t much to be done about this. I don’t see lack of this method as a big loss, as use of stopImmediatePropagation seems like a code smell to me since the behavior of this call is completely dependent on the order that multiple event handlers are attached to the element in question.

Browser Load Events

While load events on the window seem to function fairly well in ancient browsers, the DOMContentLoaded event was not supported by Internet Explorer until version 9. For older versions, the solution is a bit of a kludge. If DOMContentLoaded is really very important to you, and you must support IE8 and older, consider pulling in the tiny contentloaded.js script.

Mozilla Developer Network provides a great explanation of the logic required to mimic the behavior of the DOMContentLoaded event in ancient browsers:

Internet Explorer 8 supports the readystatechange event, which can be used to detect when the DOM is ready. In earlier versions of Internet Explorer, this state can be detected by repeatedly trying to execute document.documentElement.doScroll(“left”);, as this snippet will throw an error until the DOM is ready.

Of course, there are other gotchas in the context of event handling when dealing with ancient browsers. I’ve decided to outline a few of the more common ones above. If I forgot to mention something earth-shattering, please let me know in the comments.

Libraries to Consider

You likely don’t need a library to help you deal with events in modern browsers. But, if you really want some bells & whistles:

Consider using bean for dealing with various event-related tasks. Bean was written by one of the original developers of Bootstrap.
Mousetrap is a nifty little library that makes it simple and fun to handle various keyboard shortcuts.
PubSubJS is a small library that, as the readme states, focuses on topic-based publish/subscribe support.

For me: I’ll talk about various utility functions and tasks that are commonly needed when developing most web applications. This will be more of a (but not entirely) JavaScript-as-a-language focus. By contrast, most of my previous posts have focused almost exclusively on the Web/DOM API.

For you: if I’ve left out any important event-related topics, please let me know in the comments so I can update this post.

Ajax Requests

Sun, 14 Dec 2014 00:00:00 +0000

Many developers who learned web development through a jQuery lens probably think that jQuery is doing something magical when you invoke the $.ajax method. That couldn’t be further from the truth. All of the heavy lifting is done by the browser via the XMLHttpRequest object. jQuery’s ajax is just a wrapper around XMLHttpRequest. Using the browser’s built-in support for ajax requests isn’t very difficult, as you’ll see in a moment. Even cross-origin requests are simple.

GETting
POSTing
URL Encoding
JSON
Uploading
CORS
JSONP
Libraries to Consider
Next in this Series

GETting

Let’s start with a simple but common request. We need to ask the server for the name of a person, given that person’s unique ID. The unique ID string should be included as a query parameter in the URI, with an empty payload, as is common for GET requests. Invoke an alert with the user’s name, or an error if the request fails.

jQuery

There are a couple ways to initiate a GET ajax request using jQuery’s API. One involves the get method, which is shorthand for ajax with a type of ‘get’. We’ll just use the ajax method going forward for consistency.

$.ajax('myservice/username', {
    data: {
        id: 'some-unique-id'
    }
})
.then(
    function success(name) {
        alert('User\'s name is ' + name);
    },

    function fail(data, status) {
        alert('Request failed.  Returned status of ' + status);
    }
);

Native XMLHttpRequest Object

var xhr = new XMLHttpRequest();
xhr.open('GET', 'myservice/username?id=some-unique-id');
xhr.onload = function() {
    if (xhr.status === 200) {
        alert('User\'s name is ' + xhr.responseText);
    }
    else {
        alert('Request failed.  Returned status of ' + xhr.status);
    }
};
xhr.send();

The above native JS example will work in IE7 and up. Even IE6 is trivial to support, just by swapping out new XMLHttpRequest() with new ActiveXObject("MSXML2.XMLHTTP.3.0"). Our native example seems easy to follow and fairly intuitive to write. So, why use jQuery here? What is gained?

POSTing

Let’s extend our last example a bit. Now that we have the user’s full name, let’s go ahead and change it. We will again address this user by ID. We’ll need to POST a message to our server for that particular user, and include the user’s new name inside the request body as a URL encoded string. The server will return the updated name in its response, so we should check that to make sure all is well.

The correct method to use for this case is actually PATCH, but there are some issues with PATCH and other non-traditional methods in older browsers (such as IE8), So, we’ll just use POST here, but the code is identical in either case, with the exception of the differing method name.

Also note that the following approach is pretty much the same, regardless of the request method.

jQuery

var newName = 'John Smith';

$.ajax('myservice/username?' + $.param({id: 'some-unique-id'}), {
    method: 'POST',
    data: {
        name: newName
    }
})
.then(
    function success(name) {
        if (name !== newName) {
            alert('Something went wrong.  Name is now ' + name);
        }
    },

    function fail(data, status) {
        alert('Request failed.  Returned status of ' + status);
    }
);

Native XMLHttpRequest Object

var newName = 'John Smith',
    xhr = new XMLHttpRequest();

xhr.open('POST', 'myservice/username?id=some-unique-id');
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.onload = function() {
    if (xhr.status === 200 && xhr.responseText !== newName) {
        alert('Something went wrong.  Name is now ' + xhr.responseText);
    }
    else if (xhr.status !== 200) {
        alert('Request failed.  Returned status of ' + xhr.status);
    }
};
xhr.send(encodeURI('name=' + newName));

It seems pretty clear here that the jQuery way to send this request is much more elegant. It does a portion of the work for you. But, is this elegance worth pulling in the dependency? If you are comfortable enough with the relatively simple XMLHttpRequest object, the answer is probably “no”.

URL Encoding

jQuery provides a function that takes an object and turns it into a URL encoded string:

$.param({
    key1: 'some value',
    'key 2': 'another value'
});

This is nice, but we can do something similar with a little elbow grease, sans jQuery. The Web API provides two functions that URL encode strings: encodeURI and encodeURIComponent. A function that builds on this native support to mirror the functionality of $.param isn’t terribly difficult:

function param(object) {
    var encodedString = '';
    for (var prop in object) {
        if (object.hasOwnProperty(prop)) {
            if (encodedString.length > 0) {
                encodedString += '&';
            }
            encodedString += encodeURI(prop + '=' + object[prop]);
        }
    }
    return encodedString;
}

Yes, of course, the jQuery method here is much more elegant. But this is, in my humble opinion, one of the few instances where jQuery noticably improves your code. You’re certainly not going to pull in jQuery just for the $.param method, are you?

Sending and Receiving JSON

We now need to communicate with an API that expects JSON, and returns it in the response. Say we need to update some information for a specific user. Once the server processes our update, it will echo all current information (after the update) about that user in the response. The proper method for this request is PUT, so let’s use that.

jQuery

$.ajax('myservice/user/1234', {
    method: 'PUT',
    contentType: 'application/json',
    processData: false,
    data: JSON.stringify({
        name: 'John Smith',
        age: 34
    })
})
.then(
    function success(userInfo) {
        // userInfo will be a JavaScript object containing properties such as
        // name, age, address, etc
    }
);

The above code is actually pretty awful. jQuery is broken in the ajax department on a number of levels. It’s actually quite confusing to send anything other than a trivial ajax request using jQuery, in my experience. jQuery’s ajax module is targeted at application/x-www-form-urlencoded requests. Any other encoding type will require you to do a bit more work.

First we need to tell jQuery to leave the data alone (i.e. don’t URL encode it). Then, we must turn the JavaScript object into JSON ourself. Why can’t jQuery do this for us based on the contentType? I’m not sure.

If the server returns an appropriate Content-Type in the response, the success handler should be passed a JavaScript object representing the JSON returned by the server.

Web API

var xhr = new XMLHttpRequest();
xhr.open('PUT', 'myservice/user/1234');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onload = function() {
    if (xhr.status === 200) {
        var userInfo = JSON.parse(xhr.responseText);
    }
};
xhr.send(JSON.stringify({
    name: 'John Smith',
    age: 34
}));

The above code will work in IE8 and up. But maybe you work at an awful company that requires support for ancient browsers. In that case, just drop in json.js to fill in for the lack of JSON support in IE7 and older.

Uploading Files

For starters, you should know that the only way to upload files in IE9 and older is by submitting a <form> that contains an <input type="file">. jQuery isn’t going to help you out much with that, and frankly neither is the Web API.

So let’s talk about uploading files in modern browsers. This is made possible by the File API. As you will see shortly, jQuery doesn’t help you out at all when it comes to uploading files. If anything, uploading files is more confusing with $.ajax.

With the aid of the File API, you can upload files two ways. The first involves sending the file as part of a multipart encoded request. The request sent here is identical to the one sent by the browser when a <form enctype="multipart/form-data"> is submitted. The second involves sending a request with a body that consists entirely of the file data. In each case, you must have access to the underlying File or Blob, as this is the entity you must send to the server.

Given the following markup:

<input type="file" id="test-input">

jQuery

First, we’ll upload a file as part of a multipart encoded request:

var file = $('#test-input')[0].files[0],
    formData = new FormData();

formData.append('file', file);

$.ajax('myserver/uploads', {
    method: 'POST',
    contentType: false,
    processData: false,
    data: formData
});

How non-intuitive is that? contentType: false? What does that even mean? Well, this is required to ensure that jQuery doesn’t insert its own Content-Type header, since the browser MUST specify the Content-Type for you as it includes a calculated multipart boundary ID used by the server to parse the request.

Now, let’s send a POST where the entire payload of the request consists of the file data:

var file = $('#test-input')[0].files[0];

$.ajax('myserver/uploads', {
    method: 'POST',
    contentType: file.type,
    processData: false,
    data: file
});

That’s a bit better, but we still need to include the non-sensical processData: false option to prevent jQuery from attempting to URL-encode the payload.

XMLHttpRequest

First, multipart encoded:

var formData = new FormData(),
    file = document.getElementById('test-input').files[0],
    xhr = new XMLHttpRequest();

formData.append('file', file);
xhr.open('POST', 'myserver/uploads');
xhr.send(formData);

And now, let’s send the file as the payload of the request:

var file = document.getElementById('test-input').files[0],
    xhr = new XMLHttpRequest();

xhr.open('POST', 'myserver/uploads');
xhr.setRequestHeader('Content-Type', file.type);
xhr.send(file);

Hey, that was really easy. All the power in uploading files comes from the File API and XMLHttpRequest. jQuery just gets in the way.

CORS

CORS, or Cross Origin Resource Sharing (sending cross-domain ajax requests) is actually a fairly complex topic, and there is much to discuss here. But, we’re really not concerned with all the details here. This assumes you already understand CORS and the Same Origin Policy. If you don’t, MDN has a great explanation. Maybe I’ll even take some time to write more on the topic.

Anyway, sending a cross-origin ajax request via JavaScript is pretty straightforward in modern browsers. The process is a bit hairy in IE8 and IE9 though. In either case, jQuery offers zero assistance.

For modern browsers, all of the work is delegated to the server. The browser does everything else for you. Your code for a cross-origin ajax request in a modern browser is identical to a same-origin ajax request. So, I won’t bother showing that in jQuery or native JavaScript.

It’s important to know that cookies are not sent by default with cross-origin ajax requests. You must set the withCredentials flag on the XMLHttpRequest transport. Let’s take a look.

jQuery

$.ajax('http://someotherdomain.com', {
    method: 'POST',
    contentType: 'text/plain',
    data: 'sometext',
    beforeSend: function(xmlHttpRequest) {
        xmlHttpRequest.withCredentials = true;
    }
});

XMLHttpRequest

var xhr = new XMLHttpRequest();
xhr.open('POST', 'http://someotherdomain.com');
xhr.withCredentials = true;
xhr.setRequestHeader('Content-Type', 'text/plain');
xhr.send('sometext');

Clearly no benefit from jQuery here.

jQuery actually becomes a headache to deal with when we need to send a cross-domain ajax request in IE8 or IE9. If you’re using jQuery for this purpose, you are truly trying to fit a square peg into a round hole.

To understand why jQuery is a poor fit for cross-origin requests in IE9 and IE8, it’s important to understand a couple low-level points:

Cross-origin ajax requests in IE8 and IE9 can only be sent using the IE-proprietary XDomainRequest transport. I’ll save the rant for why this was such a huge mistake by the IE development team for another blog post. Regardless, XDomainRequest is a stripped down version of XMLHttpReqest, and it must be used when making cross-origin ajax requests in IE8 and IE9. To read more about the (significant) restrictions imposed on this transport, read Eric Law’s MSDN post on the subject.
jQuery’s ajax method (and all associated aliases) are just wrappers for XMLHttpRequest. It has a hard dependency on XMLHttpRequest.

So, you need to use XDomainRequest to send the cross-origin request in IE8/9, but jQuery.ajax is hard-coded to use XMLHttpRequest. That’s a problem, and resolving it in the context of jQuery is not going to be pleasant. In fact, it’s so unpleasant that no one in their right mind would do it. Luckily, for those dead-set on using jQuery for this type of call, there are a few plug-ins that will “fix” jQuery in this regard. Essentially, the plug-ins must override jQuery’s ajax request sending/handling logic via the $.ajaxTransport method.

But, sending ajax requests in IE8/9 is pretty simple without jQuery. In fact, even if you’re a die-hard jQuery fan, you should do it this way:

// For cross-origin requests, some simple logic
// to determine if XDomainReqeust is needed.
if (new XMLHttpRequest().withCredentials === undefined) {
    var xdr = new XDomainRequest();
    xdr.open('POST', 'http://someotherdomain.com');
    xdr.send('sometext');
}

Note that you cannot set any request headers when using XDomainRequest. If you can avoid making cross-origin ajax requests in IE8/9, you should. But if you must, become familiar with its limitations.

JSONP

I’ll begin here by suggesting you avoid using JSONP, as it’s proven to be a potential security issue. Also, in modern browsers, CORS is a much better route.

If you’re not familiar with JSONP, the name may be a bit misleading. There is actually no JSON involved here at all. It’s a very common misconception that JSON must be returned from the server when the client initiates a JSONP call, but that’s simply not true. Instead, the server returns a function invocation, which is not valid JSON.

JSONP stands for JavaScript Object Notation with Padding. It’s essentially just an ugly hack that exploits the fact that <script> tags that load content from a server are not bound by the same-origin policy. There needs to be cooperation and an understanding of the convention by both client and server for this to work properly. You simply need to point the src attribute of a <script> tag at a JSONP-aware endpoint, including the name of an exisitng global function as a query parameter. The server will then construct a string representation that, when executed by the browser, will invoke the global function, passing in the requested data.

jQuery

$.ajax('http://jsonp-aware-endpoint.com/user', {
    jsonp: 'callback',
    dataType: 'jsonp',
    data: {
        id: 123
    }
}).then(function(response) {
    // handle requested data from server
});

jQuery has entirely abstracted away the awfulness of JSONP. +1 for jQuery here. But, we can still accomplish all of this without jQuery, and it’s not as complicated as it might seem:

Without jQuery

window.myJsonpCallback = function(data) {
    // handle requested data from server
};

var scriptEl = document.createElement('script');
scriptEl.setAttribute('src',
    'http://jsonp-aware-endpoint.com/user?callback=myJsonpCallback&id=123');
document.body.appendChild(scriptEl);

Libraries to Consider

I beleive that the examples I provided above show that any ajax related code can be done fairly easily without pulling in any dependencies. But, if you’re not convinced and don’t want to pull in jQuery just for some ajax help, there are a few focused libraries you can check out.

fetch: a polyfill for the emerging fetch standard, which aims to make native ajax code more intuitive and modern.
xdomain: A library that makes cross-origin requests in all browsers, back to IE8, really easy. It makes use of the Web Messaging API, and includes some of its own conventions to make this work. The server buy-in is must simpler than the requirements for CORS as well due to some clever workarounds in this library.
Lightweight-JSONP: As the name suggests, this is a small library that aims to make JSONP a breeze in the browser.

For me: I’ll talk about dealing with events (both DOM/native and custom).

For you: if I’ve left out any important ajax-related topics, let me know in the comments so I can update the post.

DOM Manipulation

Sat, 22 Nov 2014 00:00:00 +0000

We previously learned how to easily select elements without relying on jQuery. but what about changing elements? What about creating new elements? How about relocating elements elsewhere on the page? You may be glad to know that all of this, and more, is also possible without pulling in jQuery. The Web API provides us with all of the tools we need, once again.

You will see that some DOM manipulation is trivial without the aid of jQuery or any other library. However, others may be a bit tricky. This is the time to stress (again) that I am not trying to bash jQuery, nor will I assert that jQuery is useless or completely unnecessary. The intent of these posts is to inform you how to work with the browser without jQuery, if you so choose. You may find that, in many cases, a large library like jQuery goes mostly unused, and can be omitted.

Creating Elements
Inserting Elements Before & After
Inserting Elements As Children
Moving Elements
Removing Elements
Adding & Removing CSS Classes
Adding/Removing/Changing Attributes
Adding & Changing Text Content
Adding/Updating Element Styles
Micro-libraries For More Help
Next

Creating Elements

jQuery

$('<div></div>');

DOM API

// IE 5.5+
document.createElement('div');

Wow, that was pretty easy. jQuery saved us a few keystrokes, but that’s hardly worth the bytes.

Inserting Elements Before & After

Let’s create an element and insert it after another specific element.

So, we start with:

<div id="1"></div>
<div id="2"></div>
<div id="3"></div>

… and we’d like to create a new element with an ID of ‘1.1’ and insert it between the first two DIVs, giving us this:

<div id="1"></div>
<div id="1.1"></div>
<div id="2"></div>
<div id="3"></div>

jQuery

$('#1').after('<div id="1.1"></div>');

DOM API

// IE 4+
document.getElementById('1')
    .insertAdjacentHTML('afterend', '<div id="1.1"></div>');

Ha! Take THAT jQuery! Pretty easy in every browser just relying on the tools built into the browser.

Ok, what if we want to insert a new element BEFORE the first div, giving us this:

<div id="0.9"></div>
<div id="1"></div>
<div id="2"></div>
<div id="3"></div>

jQuery

$('#1').before('<div id="0.9"></div>');

DOM API

// IE 4+
document.getElementById('1')
    .insertAdjacentHTML('beforebegin', '<div id="0.9"></div>');

Pretty much the same as the last, with the exception of a different method call for jQuery and a different parameter for the plain ‘ole JavaScript approach.

Inserting Elements As Children

Let’s say we have this:

<div id="parent">
    <div id="oldChild"></div>
</div>

…and we want to create a new element and make it the first child of the parent, like so:

<div id="parent">
    <div id="newChild"></div>
    <div id="oldChild"></div>
</div>

jQuery

$('#parent').prepend('<div id="newChild"></div>');

DOM API

// IE 4+
document.getElementById('parent')
    .insertAdjacentHTML('afterbegin', '<div id="newChild"></div>');

…or create a new element and make it the last child of #parent:

<div id="parent">
    <div id="oldChild"></div>
    <div id="newChild"></div>
</div>

jQuery

$('#parent').append('<div id="newChild"></div>');

DOM API

// IE 4+
document.getElementById('parent')
    .insertAdjacentHTML('beforeend', '<div id="newChild"></div>');

All of this looks a lot like the previous section that dealt with insertion of new elements. Again, it’s pretty simple to do all of this, cross-browser, without any help from jQuery (or any other library).

Moving Elements

Consider the following markup:

<div id="parent">
    <div id="c1"></div>
    <div id="c2"></div>
    <div id="c3"></div>
</div>
<div id="orphan"></div>

What if we want to relocate the #orphan as the last child of the #parent?
That would give us this:

<div id="parent">
    <div id="c1"></div>
    <div id="c2"></div>
    <div id="c3"></div>
    <div id="orphan"></div>
</div>

jQuery

$('#parent').append($('#orphan'));

DOM API

// IE 5.5+
document.getElementById('parent')
    .appendChild(document.getElementById('orphan'));

Simple enough without jQuery. But what if we want to make #orphan the first child of #parent, giving us this:

<div id="parent">
    <div id="orphan"></div>
    <div id="c1"></div>
    <div id="c2"></div>
    <div id="c3"></div>
</div>

jQuery

$('#parent').prepend($('#orphan'));

DOM API

// IE 5.5+
document.getElementById('parent')
    .insertBefore(document.getElementById('orphan'), document.getElementById('c1'));

We can still complete this in one line, but it’s a bit less intuitive & verbose without jQuery. Still, not too bad.

Removing Elements

How can we remove an element from the DOM? Let’s say we know an element with an ID of ‘foobar’ exists. Let’s kill it!

jQuery

$('#foobar').remove();

DOM API

// IE 5.5+
document.getElementById('foobar').parentNode
    .removeChild(document.getElementById('foobar'));

The DOM API approach is certainly a bit verbose and ugly, but it works! Note that we don’t have to be directly aware of the parent element, which is nice.

Adding & Removing CSS Classes

We have a simple element:

<div id="foo"></div>

…let’s add a CSS class of “bold” to this element, giving us:

<div id="foo" class="bold"></div>

jQuery

$('#foo').addClass('bold');

DOM API

// All modern browsers, with the exception of IE9
document.getElementById('foo').classList.add('bold');

// All browsers
document.getElementById('foo').className += 'bold';

Let’s remove that class now:

jQuery

$('#foo').removeClass('bold');

DOM API

// All modern browsers, with the exception of IE9
document.getElementById('foo').classList.remove('bold');


// All browsers
document.getElementById('foo').className = 
    document.getElementById('foo').className.replace(/^bold$/, '');

For IE 10 and up, the API is pretty much the same between jQuery and the Web API.

Adding/Removing/Changing Attributes

Let’s start out with a simple element, like this:

<div id="foo"></div>

Now, let’s say this <div> actually functions as a button. We should attach the approriate role attribute to make this element more accessible.

jQuery

$('#foo').attr('role', 'button');

DOM API

// IE 5.5+
document.getElementById('foo').setAttribute('role', 'button');

In both cases, a new attribute can be created, or an existing attribute can be updated using the same code.

What if the behavior of our <div> changes, and it no longer functions as a button. In fact, it’s just a plain ‘ole <div> now with some trivial text or markup. Let’s remove that role…

jQuery

$('#foo').removeAttr('role');

DOM API

// IE 5.5+
document.getElementById('foo').removeAttribute('role');

Adding & Changing Text Content

Now, we have the following markup:

<div id="foo">Hi there!</div>

…but we want to update the text to say “Goodbye!”.

jQuery

$('#foo').text('Goodbye!');

Note that you can also easily retrieve the current text of the element by calling text with no parameters.

DOM API

// IE 5.5+
document.getElementById('foo').innerHTML = 'Goodbye!';

// IE 5.5+ but NOT Firefox
document.getElementById('foo').innerText = 'GoodBye!';

// IE 9+
document.getElementById('foo').textContent = 'Goodbye!';

Both properties above will return the current element’s HTML/text as well.

The advantage to using innerText or textContent is that any HTML is escaped, which is a great feature if the content is user-supplied and you only ever want to include text as content for the selected element.

Adding/Updating Element Styles

Generally, adding styles inline or with JavaScript is a “code smell”, but it may be needed in some unique instances. For those cases, I’ll show you how that can be done with jQuery and the DOM API.

Given a simple element with some text:

<span id="note">Attention!</span>

…we’d like to make it stand out a bit more, so let’s make it appear bold.

jQuery

$('#note').css('fontWeight', 'bold');

DOM API

// IE 5.5+
document.getElementById('note').style.fontWeight = 'bold';

I actually prefer the way the DOM API approach looks in this case. It seems much more intuitive than jQuery’s css method.

Micro-Libraries For More Help

So, guess what? You don’t really need jQuery for cross-browser DOM manipulation either! I realize that jQuery may make some more complex manipulation a bit easier, bit if you’re only really concerned with complex DOM manipulation tasks, then consider pulling in a smaller library that focuses mostly on this. A couple choices are jBone and dom.js. There’s nothing wrong with “rolling your own” library either. DOM manipulation isn’t as difficult as you may think.

For me: I’ll talk about making ajax requests.

For you: if I’ve left out any important DOM manipulation examples, let me know in the comments so I can update the post.

Selecting Elements

Thu, 06 Nov 2014 00:00:00 +0000

How many times have you seen a web app or library that uses jQuery simply to perform trivial element selection? How many times have you written this: $(#myElement')? Or this: $('.myElement')? Psst… you don’t need jQuery to select elements! It’s pretty easy with the plain ‘ole DOM API.

IDs
CSS Classes
Tag Names
Attributes
Pseudo-classes
Children
Descendants
Exclusion Selectors
Multiple Selectors
See a Pattern?
Filling in the Gaps
Next in this Series

By ID

jQuery

// returns a jQuery obj w/ 0-1 elements
$('#myElement');

DOM API

// IE 5.5+
document.getElementById('myElement');

…or…

// IE 8+
document.querySelector('#myElement');

Both methods return a single Element. Note that getElementById is more efficient than using querySelector.

Does jQuery’s syntax provide any advantage here? I don’t see one. Do you?

By CSS Class

jQuery

// returns a jQuery obj w/ all matching elements
$('.myElement');

DOM API

// IE 9+
document.getElementsByClassName('myElement');

…or…

// IE 8+
document.querySelectorAll('.myElement');

The first method returns an HTMLCollection and is the most efficient of the two choices. querySelectorAll always returns a NodeList.

Again, really simple stuff here. Why bother with jQuery?

By Tag Name

For example, to select all <div> elements on a page:

jQuery

$('div');

DOM API

// IE 5.5+
document.getElementsByTagName('div');

…or…

// IE 8+
document.querySelectorAll('div');

As expected, querySelectorAll (which returns a NodeList) is less efficient than getElementsByTagName (which returns an HTMLCollection).

By Attribute

Select all elements with a “data-foo-bar” attribute that contains a value of “someval”:

jQuery

$('[data-foo-bar="someval"]');

DOM API

// IE 8+
document.querySelectorAll('[data-foo-bar="someval"]');

Again, the DOM API and jQuery syntax is very similar.

By Pseudo-class

Select all fields in a specific form that are currently invalid. Let’s assume our form has an ID of “myForm”.

jQuery

$('#myForm :invalid');

DOM API

// IE 10+
document.querySelectorAll('#myForm :invalid');

Children

Select all children of a specific element. Let’s assume our specific has an ID of “myParent”.

jQuery

$('#myParent').children();

DOM API

// IE 5.5+
// NOTE: This will include comment and text nodes as well.
document.getElementById('myParent').childNodes;

…or…

// IE 9+ (ignores comment & text nodes).
document.getElementById('myParent').children;

But what if we want to only find specific children? Say, only children with an attribute of “ng-click”?

jQuery

$('#myParent').children('[ng-click]');

…or…

$('#myParent > [ng-click]');

DOM API

// IE 8+
document.querySelector('#myParent > [ng-click]');

Descendants

Find all anchor elements under #myParent.

jQuery

$('#myParent A');

DOM API

// IE 8+
document.querySelectorAll('#myParent A');

Excluding Elements

Select all <div> elements, except those with a CSS class of “ignore”.

jQuery

$('DIV').not('.ignore');

…or…

$('DIV:not(.ignore)');

DOM API

// IE 9+
document.querySelectorAll('DIV:not(.ignore)');

Multiple Selectors

Select all <div>, <a> and <script> elements.

jQuery

$('DIV, A, SCRIPT');

DOM API

// IE 8+
document.querySelectorAll('DIV, A, SCRIPT');

See a Pattern?

If we focus exclusively on selector support, and don’t need to handle anything older than IE8, seems like we could get pretty far simply by replacing jQuery with this:

window.$ = function(selector) {
    var selectorType = 'querySelectorAll';

    if (selector.indexOf('#') === 0) {
        selectorType = 'getElementById';
        selector = selector.substr(1, selector.length);
    }

    return document[selectorType](selector);
};

But I Want More!

For the vast majority of projects, the selectors support baked into the Web API is sufficient. But what if you are unfortunate enough to require IE7 support? In that case, you’ll probably need a little help from some third party code.

Sure, you could just pull in jQuery, but why use such a large codebase when you only need advanced selector support for now? Instead, try a micro-library that focuses exclusively on element selection. Consider Sizzle, which happens to be the selector library that jQuery uses. Selectivizr is another very small selector library that brings CSS3 selector support to very old browsers.

For me: I’ll talk about manipulating DOM elements in the next post.

For you: if I’ve left out any important selectors, let me know in the comments so I can update the post.

You Don't Need jQuery (anymore)

Sun, 02 Nov 2014 00:00:00 +0000

A lot of web developers rely on jQuery. In many circles, jQuery and JavaScript are one in the same it seems. So, why shouldn’t you use it? Why should you stop using it? Don’t you just need it?

jQuery makes everything easier. You can’t develop a solid web app without it. It’s far too difficult to ensure your app will work properly in all browsers without jQuery - the Web API implementation varies wildly between browsers. All the good plug-ins I need depend on jQuery anyway.

I bought into the excuses above, for most of my career. And some of them were even good excuses, at one time. When I took over maintenance and development of a large cross-browser file upload library in 2012, my first instinct was to rewrite it all using jQuery, because that would make my life easier, I thought. The existing user community was against bringing any 3rd-party dependencies into the library, so I was forced to deal with the native browser API instead. You know what? It was a lot easier to toss jQuery to the side than I imagined. I didn’t need jQuery, and neither do you.

The Trap

A while back, when I entered the world of web development, the first library I used was jQuery. In fact, I didn’t even bother to learn proper JavaScript. I didn’t have a clue what the Web API looked like, or how to deal with the DOM directly. jQuery did everything for me. This huge gap in my knowledge caught up with me when I ended up on a project without my jQuery crutch. I was forced to learn proper web development, and I never looked back.

I fell into a trap, and this is a trap that many new, occasional, and hobbyist web developers fall into. Had I taken the time to understand JavaScript and the API provided by the browser first, I would have saved myself a lot of trouble. The proper sequence of events is:

Learn JavaScript
Learn the Web API
Learn jQuery (or any other framework/library that you may need across projects)

Many start with #3, and #1 & #2 come much later (or never). If you don’t understand what jQuery is actually doing for you, there will be many frustrating days ahead as the leaky abstractions come out of the woodwork, or if you are unable to use jQuery in a future project. This is a trap you must avoid if you want to effectively grow as a web developer.

Cross-Browser Support

One of the most touted reasons for pulling in jQuery is to fix the “broken DOM API”. This is a valid point, but only if you are working with IE7 or older. It’s now 2014, and IE7 support is rare. The DOM API isn’t really as bad as many people make it out to be. Basic traversal, manipulation, and creation of elements is straightforward and consistently supported in all modern browsers.

The Web API as a whole is, more or less, quite advanced and capable since IE8. Of course, there are gaps in pre-IE10 browsers and some very old Safari/WebKit implementations, but these gaps can be filled in, as needed, with small, directed libraries. In many cases, such as with cross-browser file upload support, MutationObserver support, or Web Component support, you’ll need to pull in libraries other than jQuery. The point is, jQuery isn’t a silver bullet, and there’s a good chance that you will only ever really need a very small portion of what jQuery provides.

JavaScript

Another common reason to pull in jQuery is to make up for perceived shortcomings in the underlying language itself (JavaScript). This is one of the most frivolous excuses. It’s a bit much to pull in a 3rd-party dependency like jQuery simply for a marginally better way to loop over object properties and array elements. In fact, this is completely unnecessary with the existence of forEach and Object.keys() (both available in IE9+). Or perhaps you think $.inArray() is useful? Not since IE9, where Array.prototype.indexOf was made available as part of ES5. There are many more examples, but I’ll save those for a future post.

Ok, but do I really need to ditch jQuery?

No, of course not. If you feel comfortable with jQuery, and you are familiar enough with how jQuery works its magic, then, by all means, keep using it. This series of blog posts is all about empowering you to make use of the Web API and (when needed) directed libraries to solve problems in your web apps without pulling in large monolithic multi-purpose libraries that go mostly unused.

Ok, but should I really ditch jQuery?

That’s entirely up to you. This series is all about revealing the Web API and vanilla JavaScript. If you have to consistently support ancient browsers and jQuery makes your life easier, then maybe not. But, if you have reasonable browser support and/or get satisfaction from writing your own code, by all means, ditch it!

Coming Up Next

Selecting elements without jQuery.

You Don't Need jQuery!

Beyond jQuery

Utilities

Is this an Object, Array, or a Function?

jQuery

vanilla JavaScript

Combine and copy objects

jQuery

vanilla JavaScript

Iterate over object properties

jQuery

vanilla JavaScript

Iterate over array elements

jQuery

vanilla JavaScript

Find an element in an array

jQuery

vanilla JavaScript

Turn a pseudo-array into a real array

jQuery

vanilla JavaScript

Modify a function

1 - Change a function’s context

jQuery

vanilla JavaScript

2 - Create a new function with some pre-determined arguments

jQuery

vanilla JavaScript

Trim a string

jQuery

vanilla JavaScript

Associate data with an HTML element

jQuery

vanilla JavaScript

Next

Events

Sending Native (DOM) Events

jQuery

Web API

Sending Custom Events

jQuery

Web API

Listening For Events

jQuery

Web API

Removing Event Handlers

jQuery

Web API

Modifying Events

Preventing the event from bubbling further up the DOM

jQuery

Web API

Preventing the event from hitting any additional handlers attached to the current element

jQuery

Web API

Preventing the event from triggering an action defined by the browser

jQuery

Web API

Event Delegation

jQuery

Web API

Keyboard Events

jQuery

Web API

jQuery

Web API

Mouse Events

jQuery’s hover event

Browser Load Events

When have all elements on the page fully loaded and rendered w/ applied styles?

jQuery

Web API

When has all static markup been placed on the page?

jQuery

Web API

When has a particular element on the page fully loaded?

jQuery

Web API

Ancient Browser Support

Listening For Events

jQuery’s `hover` event