I think most people here know and understand the patterns involved here: Factory and Provider Model. From this knowledge, I guess the post is easily recognizable as exaggerated. This does not invalidate the gist of his argument. What the post author complains about (and I agree with him) is:
1. These patterns add complexity from the get-go of an app. He ridicularizes, and picks both an extreme example and an extreme Angular solution, but the message is sound.
2. These patterns have failed us in the past. Anyone who has worked on large enterprise projects has dealt with the immense complexity and, surprisingly, with the lack of configurability in the end result (a failure of the pattern objective).
I'd add a last point, not explicitely stated:
3. Last, but definitely not least, Javascript does not need these! Javascript is not a classic object oriented language.
Let me try my hand at supporting my last point. Imagine you want your database connection to be globally configured. You also want code needing a connection to be decoupled from the exact implementation. Just refer to a mythical DBConnection object in the DB client code:
connection = DBConnection.singleton()
And have it so that the DBConnection object instance exists prior to being called (instantiate it in the configuration stage of the app):
DBConnection = { prototype: new PgsqlConnection(...) }
Javascript being classless[1] and supporting prototype based object inheritance invalidates many of the assumptions behind patterns in use in classical OO languages. This is even more relevant when we are talking about flawed patterns.
[1] Yes, ECMAScript 2 and beyond have classes. It's an error, never got traction in the real world, and I hope it never does.
> Javascript does not need these! Javascript is not a classic object oriented language.
No language needs these. To me the GOF patterns have always been wisdom as opposed to a solution. When you are dealing with the interaction between complex systems you can refer to the knowledge that GOF patterns provide.
GOF patterns basically say "this is one way to solve problem X." It is my belief that they never say "this is the actual way to solve problem X." In fact I've found that they are often bad solutions within the context of the problems I solve. Exact copies of them only work in rare academic scenarios.
TLDR; You'll find lots of GOF inspiration in my code, however, you'll never find a text-book GOF implementation in my code.
The message is: we cannot just take "design patterns" from one language and shove them into another. All a "design pattern" is, is standard way to mitigate a lack of abstraction. If the language itself had a way to, say, create singletons (for instance, by having a singleton keyword), the need for that particular pattern would disappear.
Likewise, design patterns for javascript should be based around the points where the abstraction is lacking. Therefore, they'll be likely very different.
1. These patterns add complexity from the get-go of an app. He ridicularizes, and picks both an extreme example and an extreme Angular solution, but the message is sound.
2. These patterns have failed us in the past. Anyone who has worked on large enterprise projects has dealt with the immense complexity and, surprisingly, with the lack of configurability in the end result (a failure of the pattern objective).
I'd add a last point, not explicitely stated:
3. Last, but definitely not least, Javascript does not need these! Javascript is not a classic object oriented language.
Let me try my hand at supporting my last point. Imagine you want your database connection to be globally configured. You also want code needing a connection to be decoupled from the exact implementation. Just refer to a mythical DBConnection object in the DB client code:
And have it so that the DBConnection object instance exists prior to being called (instantiate it in the configuration stage of the app): Javascript being classless[1] and supporting prototype based object inheritance invalidates many of the assumptions behind patterns in use in classical OO languages. This is even more relevant when we are talking about flawed patterns.[1] Yes, ECMAScript 2 and beyond have classes. It's an error, never got traction in the real world, and I hope it never does.