Design patterns are solutions to programming problems you find again and again in real-world application development. The design involves a description or a solution template for solving a problem that can be applied in different scenarios. Patterns are formalized best practices that developers can use in their own applications.

The GoF patterns are generally considered the foundation for all other patterns. They were published in 1995 in a seminal book called "Design Patterns, Elements of Reusable Object-Oriented Software". Four authors were involved -- Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides –hence the name Gang-of-Four, or GoF for short. This publication was instrumental in introducing the concept of Design Patterns to the field of software engineering.

Actually, the notion of design patterns originated in a different discipline, namely architecture. Christopher Alexander, a well-known architect first developed the concept of a pattern language in which he categorized architectural design elements that are both beautiful and practical. His design elements include exact methods for constructing practical, safe, and attractive designs at any scale (from individual rooms to city blocks). The Gang of Four borrowed this concept of reusable design elements and applied it to world of software design.

So, design patterns are solutions to common software design problems. Let's review the benefits of using patterns:

1. Patterns are proven solutions. Patterns are solutions proposed by seasoned developers that have run into similar design challenges. If you encounter a scenario that can be solved by implementing a design patterns, then why re-invent the wheel? Not using it only increases the risk of you taking a wrong turn, while a good solution already exists.
2. Patterns are reusable. Patterns make you more effective and productive as a developer. Once you have experienced the power of patterns and best practices in your own work it is hard to imagine working without them. Furthermore, in subsequent projects you will immediately recognize similar situations and instantly know how to solve the problem at hand. Patterns are reusable allowing you to build better apps in less time.
3. Patterns provide a common vocabulary. This is an often overlooked benefit. Each pattern has a name which makes it much easier to discuss complex application designs. If a team member explains how the HTML talks to data objects that are managed by something in between, you may be puzzled. However, if they state 'we use MVP', then anyone who's familiar with patterns will immediately recognize their chosen architecture.
4. Patterns build confidence. When a group of seasoned developers discusses design and architectural topics they may use terms like Factory, LazyLoad, Façade, MVC, and Module. As a senior web app developer or architect you are expected to be familiar with the lingo and the details of these patterns. Having experience with patterns allows you to confidently participate in these deliberations as well as their subsequent implementation.

Perhaps you are wondering, when does a particular software design solution qualify as a pattern? This is not always an easy question to answer. The GoF state that design patterns are "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context". Essentially it is a solution to a problem in a context, that is, each pattern focuses on a general, but scoped problem area or issue. This is the classical view on patterns. As you learn more about JavaScript patterns you will see that the JavaScript community has a more pragmatic perspective towards design patterns.

Even so, there are always four essential elements to a pattern:

1. A pattern name – each pattern should have a descriptive name
2. A problem – a design challenge or context in which to apply the pattern
3. A solution -- describes the pattern elements and their arrangements
4. Consequences – tradeoffs and side-effects of applying the pattern

These elements, together with the GoF pattern definition, provide a reasonable starting point of what constitutes a design pattern. The diagram below depicts this graphically. The pre-pattern stage represents the problem and its context which is messy and unstructured. The post-pattern stage shows the pattern solution which is clean and well structured. The design has a name and there are consequences associated with using this pattern.

In their book, the GoF are very detailed in their pattern definitions. They use a formal 12-point system that categorizes and describes each pattern; this includes: Name, Intent, Motivation, Applicability, Participants, Structure, Consequences, Implementation, Known Uses, and several more. This certainly was useful and relevant at that time because patterns were a new concept and it added clarity and structure to each of the 23 patterns they listed.

However, today you will not find a single pattern author that follows this system. One reason is that the concept of a design pattern has become more fluid and is used in broader contexts. Also, it is sometimes hard to pinpoint a single pattern author because patterns evolve in online communities with many participants. A new design pattern is rarely nailed in a single design session in which each of the 12 points can be defined.

In fact, the JavaScript community is a great example of how pattern development has evolved. It started off as a rather formal discipline in which a 'software authority' (mostly book authors) put their stamp of approval on a series of patterns. Today, the pattern movement takes a far more agile and pragmatic approach in which numerous community members participate resulting in highly practical software design solutions that are of immediate use to the practicing web app developer. The nature of Design Patterns in JavaScript is discussed next.