4 ms·

If you follow those patterns you might end up rewritting most of the code when ECMAScript 6 and Web Components will be ready. The standard way of writing reusab

If you follow those patterns you might end up rewritting most of the code when ECMAScript 6 and Web Components will be ready. The standard way of writing reusable code units in ES6 are classes and modules which look nothing like the module pattern described in the article (I wouldn't even call this hack a module). The standard way of handling events in DOM and other browser APIs is observer pattern (i.e. addEventListener), not mediator pattern. MVC frameworks are overhyped, you don't need them to write maintainable large projects. Check e.g. WebKit Inspector [1] or Gnome Shell [2] source code, those are great examples of how large JS application should be written. [1] https://github.com/WebKit/webkit/tree/master/Source/WebInspectorUI/UserInterface https://github.com/WebKit/webkit/tree/master/Source/WebInspe... [2] https://git.gnome.org/browse/gnome-shell/tree/js/ui https://git.gnome.org/browse/gnome-shell/tree/js/ui

edwinnathaniel 13y ago
Where's the unit-tests?
kackontent 13y ago
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 13y ago
  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.

edwinnathaniel 13y ago

Where's the unit-tests?

kackontent 13y ago

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 13y ago
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.