[kackontent]

Well, you could do a better job at criticizing richly-sourced article than just write opinions in a matter-o-factly way.

First of all, the article doesn't say much (anything?) about MVC frameworks.

Then, mediator and observer are very similar patterns and you can easily implement the former with the latter.

Modules described in the article are working very much the same as the ones that come with ECMAScript6. Check how TypeScript - which follows the ES6 way - implements those. Not much rewriting to be done there.

Further more, all of the stuff described in the article is not particularly new - those are patterns well known for a while, field-tested in the huge, existing projects.

[jarek-foksa]

The article doesn't cover MVC itself, but there are several links to MVC resources (most notably the "Essential JavaScript Design Patterns" book) and the author of the blog is a well known advocate of the "MVC everywhere" approach.

The article references a talk by Zakas who says that all modules should be completely decoupled and communication should be done via a global messaging bus ("the sandbox"). In most cases this approach is an overkill, it will lead to awkward situations where module fires events telling the mediator what should happen rather than what has happened.

I agree there should be as little coupling between modules as possible, but if there is some coupling needed, it should be explicit and clearly stated with direct function calls rather than hidden behind the mediator.

The "module with facade" pattern might make sense in code generated by a compiler, but I would never use this ugly hack in code that is going to be read by other developers. Instead of trying to hide stuff by misusing the return statement and closures I would just use underscore notation.