Patterns For Large-Scale JavaScript Application Architecture
addyosmani.com
addyosmani.com
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...
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 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.
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.
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.
Strong performance anti-patterns can be found in any example listed in your article.
http://stackoverflow.com/questions/12973706/javascript-colle...
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)?
Also, it answers the question wrong. :-b (Arrays are objects in JS, with a bit of extra magic.)
* 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?