Nonsense

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
dpjs [2015/06/04 04:16]
flynn
dpjs [2015/06/05 13:36] (current)
flynn reference to Norvig's presentation
Line 3: Line 3:
 ====== Design Patterns in JavaScript ====== ====== 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, [[http://​addyosmani.com/​resources/​essentialjsdesignpatterns/​book/​|Addy Osmani'​s ​"​Learning JavaScript Design Patterns"​]] and the problem with it is that it is largely //​dangerous//​ and largely //wrong//.+...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 ​[[http://​addyosmani.com/​resources/​essentialjsdesignpatterns/​book/​|"​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 [[dpjs:​osmani|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.+I'll write up a more thorough description of [[dpjs:​osmani|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 [[http://​www.norvig.com/​design-patterns/​design-patterns.pdf|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. ((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))
  
 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. 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.