Essential JavaScript Design Patterns For Beginners

Says who?

I'm guessing about 90% of the reason most people start using a library like jQuery is because it lets you find almost any DOM element in a single step with a familiar syntax. And about 9% of the rest is probably to make AJAX less painful. Does your unspecified ES5 shim provide these features?

If not, a lot of people are going to be using a library like jQuery anyway, and you're advocating using an extra (unspecified) library to get portable utility functions that also work in older browsers. What happened to DRY? ;-)

This isn't to say that polyfilling doesn't have its place or isn't useful. I just challenge your claim about what is best practice, because I think the argument is far from compelling in the common case that a developer is already using another library with similar utility functions (which many, many general purpose JS libraries have, because the language itself was so slow to provide them; it's like strings in C++ all over again).

jQuery is the de-facto DOM library (whether it should be or not), failure to see this is ignorance.

Could you expand on this a little bit, particularly the "other things that are commonplace in modern JavaScript code"? As someone who's just getting into heavy client-side JS, it still feels like the whole world is very jQuery-centric. In particular, material targeted at beginners (such as this article) tends to lean heavily on jQuery for anything more complex than really basic core language stuff. I'd be very interested in alternatives, if only to broaden my horizons.

I defer to him who made a plea, for consultants' reports to become poetry: https://www.youtube.com/watch?v=GUSLEJB9_LU

Perhaps, as _why's Poignant Guide, the poet goes too far: and then we lose too much substance. But 150 pages? Au revoir: there must be a cleaner, deeper essence. For I delight in the everyday code, which is fun, dramatic, sweeping, and wry, and manufactured examples of jQuery's road are nowhere as cool as an eval/apply.

The worst part is, he knows not what he does. For I opened him up to a random page, and saw what he said -- and I don't mean to fuss, but I can't help but feeling a little rage:

The Iterator Pattern is a design pattern where iterators (objects that allow us to traverse through all the elements of a collection) access the elements of an aggregate object sequentially without needing to expose its underlying form.

Iterators encapsulate the internal structure of how that particular iteration occurs - in the case of jQuery's $(el).each() iterator, you are actually able to use the underlying code behind $.each() to iterate through a collection, without needing to see or understand the code working behind the scenes that's providing this capability. This is a pattern similar to the facade, except it deals explicitly with iteration.

No, my good sir, ten times no. The iterator pattern as was discussed (in Design Patterns, and such and so), has nothing to do with that construct. Iterators speak polymorphism out loud, freeing us from finities and the rest of the crowd. Let me illustrate with a simple collection of rational numbers -- in Cantor's bijection:

    function gcd(lo, hi) {
        return lo > hi ? gcd(hi, lo) : lo === 0 ? hi : gcd(hi % lo, lo);
    }
    function rational_iterator() {
        var num = 0, denom = 1;
        return {
            hasNext: function () {
                return true;
            },
            next: function recurse() {
                var rat = [num, denom];
                if (denom === 1) {
                    denom = num + 1;
                    num = 1;
                } else {
                    denom -= 1;
                    num += 1;
                }
                return gcd(rat[0], rat[1]) === 1 ? rat : recurse();
            }
        };
    }

    function map(seq, fn) {
        var i = 0;
        return {
            hasNext: function () {
                return seq.hasNext();
            },
            next: function () {
                return fn(seq.next(), i++);
            }
        };
    }
    var rationals_as_strings = map(rational_iterator(), function (x) { return x.join("/"); });

Because, you know, the pattern is not the solution, but the sum of problem + context + solution.

I had the sudden realization that using and recognizing design patterns was exactly what I was missing to get over the beginner-intermediate hump in the learning curve. I'd heard of design patterns before, but they'd come across as a rather lofty concept.

After a second and third look, I realized its immediately practical boilerplate stuff that one can copy/paste (and even more importantly, recognize in 3rd-party plugins and frameworks). Design patterns should follow after reading a 'cookbook'. Its just a name for techniques beyond your basic for/while loops (which could be thought of as the simplest of design patterns).

Pub/Sub can be viewed as a simple form of the observer pattern, and MVC is a more elaborate form (notice that in the article's TOC, MVC comes right after Observer). I've lost a lot of time banging my head on MVC too soon. For some reason, the introductory articles on MVC I was finding made scant mention of design patterns. Great to see more material discussing the concepts together lately.