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.
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.
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.
Most fameworks deal only with the view (wether it is databiding , components , reactive programming ect... ) routing and the ajax stuff.
The problem is that architecturing a large scale js client is not that different from a Java one or a C++ one.
If one needs undo/redos you still need to know how to implement a memento and a command system. Does working with JSON blobs in Angular really help in that case ? or do you still need some kind of model with methods ? "But angular does data-binding why should I need a model class?..." that's the trap.
A few years ago ExtJS was seen as "THE" framework needed to develop large scale js clients.Now dev say it's AngularJS ,Ember or Backbone, tomorrow it will be something else. I feel for people migrating from ExtJS to AngularJS for instance , it basically means rewriting all the code.
The lesson I learned is not to use anything bloated or to use it to target a specific issue,while keeping the core of my codebase totally decoupled from framework X or Z. That's what devs do on the server ,right?, they dont write huge controllers but delegate most of the job to services that are framework independent,so they can have the same business logic for a website, a console app or an api.
That's why I think this article is good, as it doesnt target framework X or Y, but talks about a more generic approach to js application architecturing.
>The lesson I learned is not to use anything bloated or to use it to target a specific issue,while keeping the core of my codebase totally decoupled from framework X or Z
That's a bad lesson. JavaScript, on it's own, does not give you enough to write proper large-scale applications. You will have to commit to some framework, whether one your wrote yourself or one you got from somewhere else. And this isn't just a JavaScript issue. Even better designed languages (Java, C++, C#) will require some sort of framework to augment their language constructs, in specific cases and when working with code of a certain size. Packages and classes are just not enough sometimes.
>I feel for people migrating from ExtJS to AngularJS for instance , it basically means rewriting all the code.
Then don't do it. There's nothing wrong with having a code-base in ExtJS in a world in which Angular is popular. If ExtJS is doing its job and your software is doing what it's supposed to, why would you migrate to Angular? Why would you rewrite anything? Because Angular is more popular? So what?! You may have 100k lines of working, battle-tested code, 3 developers have been working on for several years. No sane person would just throw that away with a rewrite.
The framework is a modern blessing/curse. Since you mentioned other languages, I've written plenty of revenue generating software with just libraries. I'm about to write a fairly large REST back end in golang and I have high confidence that I won't need a framework to pull that off.
From an architecture perspective, the article is a great read. However, the systemic damage in JS applications comes from profound general delusions concerning the JS language itself.
Strong performance anti-patterns can be found in any example listed in your article.
This SO post is really good, but some of the points made in the post are not very clear. For example, why is arr['key'] = 5; consider bad? I've read the post and the code, but it's still not clear from the example.
When does using Object.prototype.hasOwnProperty lead to bugs?
Any benchmarks on case statements being slow?
Any additional reading on this type of thing (books, etc)?
As usual, it's best not to sacrifice readability for performance until you have proof of a bottleneck. Most of the code you write isn't performance-critical. And (thanks to existing performance optimizations in everything ranging from the JS VM, to the OS, to the CPU itself) it's very, very easy to be wrong about where your performance problems are. Note the comments under the SO article; most of the micro-"optimizations" are actually slower than normal code.
Also, it answers the question wrong. :-b (Arrays are objects in JS, with a bit of extra magic.)
I wonder what's the author view on current state of client-side MVC and what's best to use in large scale apps javascript apps in his opinion. Nowadays, we have so many libraries designed to help with composing large apps from smaller parts (using bindings, components, etc.) that it is hard to pick the right one from the start. What would fit the modular approach best? React? Angular? something else?
For future convenience, here's a reusable design pattern for these articles:
* Part 1: Have you considered <thing that is unlikely to be relevant>? You should, and BDUF will save you from it!
* Part 2: What if <totally foundational thing> needed to be swapped out? Add a jillion lines of boilerplate and indirection, JUST IN CASE!
* Part 3: Could somebody new come into your codebase with a general understanding of the tools & libraries you're using and immediately be productive? Fk that, make up your own custom APIs to hide anything familiar!
* Part 4: FAST TESTING FAST TESTING FAST TESTING FAST TESTING
* Part 5: Reuse is very important. For the content in this section, find a chunk of prose about reuse from a '90s C++ book and paste it in. See how easy that was?
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/WebInspe...
[2] https://git.gnome.org/browse/gnome-shell/tree/js/ui