To tell the truth, this isn't a subject that I particularly like. But I do feel there's a need for this to be written about. Right now, when the subject of…

Design Patterns in JavaScript

…comes out, there's only one reference people immediately turn to. And when they point to something else it ends up being someone's rendition of that same reference. The reference is, of course, Addy Osmani's "Learning JavaScript Design Patterns" and the problem with it is that it is largely dangerous and largely wrong.

I'll write up a more thorough description of why I think so, but for now let's just say that the book is doing more harm than good to people who read it without a lot of caution. An interesting reference to notice in this regard could be Page 10 of this presentation by Peter Norvig in which he presents the result of a study of the classic GoF Design Patterns book's applicability to a dynamic language such as Lisp or Dylan. His study concludes:

16 of 23 patterns are either invisible or simpler

Now, not all the reasons may apply equally to JavaScript. In particular, JavaScript does not have some of the facilities Lisp or Dylan have, such as macros, for example. But a fair number of those patterns also turn to be non-patterns in JavaScript. Trying to force foreign patterns over the native facilities of the language does turn such non-patterns into anti-patterns. The task is then double: Not only should I have the goal to present real patterns but also expose these non-patterns and anti-patterns as such. 1)

So, it is this that compels me to try to write about the subject. And I think it will also be this one of the guiding basis for writing: Trying to avoid doing harm. It is for this reason that I can't really, truly, sincerely promise I will actually get to the task, at least in a prompt manner. This will take thought. It will also surely need help from others, which I don't know if I'll be able to get.

In any case, I do hope that this turns out to be, at least, a good place for conversation with those interested in actually having a reference that can actually be regarded as more correct than not.

Who this is for

This will be focused on design patterns and general principles. There is no intention to study or cover any detail of any particular code-base. While it may happen that some concrete code found in the wild could be pointed as an example implementation, this will be just as example.

It should also be clear that a good understanding of the language is assumed in all cases. We won't bother explaining the details of basic, general JavaScript. Sometimes it can also happen that, in order to aid understanding, in-depth knowledge of a particular feature of the language will be required. I will try to either point to some relevant explanation elsewhere. If not possible, then the explanation will be written explicitly here, but it will be kept separate and live somewhere else in the wiki, to avoid diluting the focus of this effort.

I would say that, in general, this will be oriented towards people with an intermediate to advanced proficiency with JavaScript and a solid basis in general programming. People who want to learn and help others learning to advance one further step in that proficiency.

In this regard, I, flynn here, do not consider myself to be particularly knowledgeable or well suited to the task and this will probably be as much a learning experience for me as for anyone else. But at least I will try to get to the goal.

Content so far

  • Design Patterns: A brief introduction/definition of what we're talking about.
  • a page to share proposals on patterns to analyse and discuss about their merits.
  • First basic draft on the command non-pattern.
I would prefer focusing on the harder task of presenting real design patterns, but I'm aware it is as important and also easier to debunk non-patterns and anti-patterns