Design Patterns for Javascript [duplicate]

From a practical standpoint, take a good look at AngularJS and KnockoutJS. These frameworks solve real problems that you encounter when building JS heavy applications. Angular is a more "all inclusive" solution with many advanced freatures, whereas Knockout only tackles the problem of realtime UI updating. Both are very nice, and when used correctly can help structure your application in an MVC style while actually being productive. There are a plethora of other "JavaScript MVC libraries" out there, but frankly, most of them just try to shoehorn an MVC pattern without actually solving any real world problems.

As commented, JavaScript Patterns is a very useful book that takes a lower level look at what patterns are actually useful in the language.

There are some recently added new articles that focus on implementing JavaScript Design Patterns and some of the Gang-of-Four Design Patterns using JavaScript:

1. JavaScript Design Patterns: Chain of Responsibility (Last updated February 20, 2012) - Although this article obviously focuses on Chain of Responsibility, it has links to many of the other GoF patterns implemented in JavaScript.
2. Essential JavaScript & jQuery Design Patterns (Last updated April 30, 2012)

This link describes, better than I could, a sane way to architecture a medium-to-large Javascript application. Among other things, this involves:

• Splitting code into modules, using the module pattern
• Letting the modules declare their dependencies and load them asynchronously via a tool like RequireJS
• Namespacing the global objects you define
• Abstracting away the DOM manipulation library (this only makes sense for large enough projects)
• Following (some variation of) the MVC pattern, leaving to models the role of data persistence and AJAX calls, to controller the role of managing events and to views the role of DOM and style manipulations
• Minimizing the communication through independent modules, by means of some core that dispatches messages
• Designing a mechanism that restarts module as soon as they throw an exception. As a consequence, designing modules so that their restart does not have unexpected consequences (like drawing some UI element twice)
• Combine reusable parts of the UI into widgets

Using jQuery is a great start. JavaScript in a browser augments the frontend, there isn't a MVC "pattern" or anything to follow. There are some "best practices" that help keep the code clean.

• Separate functions for separate things. Bindings in one, actions in another. Make use of this as well as classes for actions.
• Remember that JavaScript allows a great deal of flexibility, passing closures around as they are created can help simplify your bindings and lighten the code.
• Shield from the global scope, only expose what is necessary.
• Use JSLint to keep your code up to standards.

For server side / non-browser JavaScript (like Node.js) there are several great frameworks for building off of. It might be worth while browsing through the source to see if you pick up on any thing.

I moved this to a more in-depth entry for the interested.

I'd recommend using namespacing and then a file structure that mirrors the namespace. For example, using Brad's answer, I'd have Truck.js, Car.js and Vehicle.js. This should give you a codebase that is easier to maintain, organise and unit test. However, you should have some kind of build process which concatenates and minfies your multiple JS files ready for production.

With an organised codebase of prototypal objects you should be in a position to implement most design patterns. There are also some good books on this subject. This presentation by Nicholas Zackas is also useful to get some insight in how to build good Javascript apps.

Also, in Javascript, I think its also important to distinguish between patterns and techniques. You need to be familiar with various commonly used techniques which JS natively lacks, such as namespacing. But these are techniques not patterns; techniques which make it easier to build patterns such as those defined by the Gang of Four.

Sorry this such a brief summary. But I'd strongly recommend the resources I mentioned to get greater insight.

some people don't realize that JS is fully object oriented. You can create something that works just like a class:

function Car() {
    this.publicField = "bad";
    var privateField = "good";
    var self = this;

    this.publicMethod = function() {
        alert("I can access " + this.publicField + " and " + privateField);
    }

    function privateMethod() {
        alert("I can access " + self.publicField + " and " + privateField);
    }
}

you can instantiate those classes:

var car = new Car();

and it supports inheritance:

function Vehicle() { /* define class */ }

function Truck() { /* define class */ }
Truck.prototype = new Vehicle();

and can even add methods to existing classes:

Array.prototype.remove = function() {
}

If you'd like to learn more about JavaScript's OO support, I highly recommend the Rhino book.

Namespacing: Don't forget to use objects as a pseudo-package (most frameworks do this, you should also):

var YourCompany = {};

YourCompany.util = {};

YourCompany.util.myFunction = function() { /* ...  */ }

You don't necessarily need to set it up that way, and use whatever naming conventions you prefer, but the namespacing will help you out a lot (makes it easier on refactoring search-and-replace too, when you decide to move something).