Shared publicly  - 
MVC vs MVVM vs MVP. What a controversial topic that many developers can spend hours and hours debating and arguing about.

For several years +AngularJS was closer to MVC (or rather one of its client-side variants), but over time and thanks to many refactorings and api improvements, it's now closer to MVVM – the $scope object could be considered the ViewModel that is being decorated by a function that we call a Controller.

Being able to categorize a framework and put it into one of the MV* buckets has some advantages. It can help developers get more comfortable with its apis by making it easier to create a mental model that represents the application that is being built with the framework. It can also help to establish terminology that is used by developers.

Having said, I'd rather see developers build kick-ass apps that are well-designed and follow separation of concerns, than see them waste time arguing about MV* nonsense. And for this reason, I hereby declare AngularJS to be MVW framework - Model-View-Whatever. Where Whatever stands for "whatever works for you".

Angular gives you a lot of flexibility to nicely separate presentation logic from business logic and presentation state. Please use it fuel your productivity and application maintainability rather than heated discussions about things that at the end of the day don't matter that much.

#AngularJS   #MVW
Jason Politis's profile photoAli Jamal's profile photoFilipe Oliveira's profile photoKyle Pennell's profile photo
What a way to avoid any conflict in the first place!

Agreed. Let's focus on simplifying the JS now that the HTML is pretty basic (declarative). :)
haha. MVW. I love it :) Keep up the awesome work!
I'm using this new design pattern acronym in a presentation. Thanks and keep up the good work!
Coming from Backbone, where one has "too much freedom", I am really enjoying building stuff with Angular!

However, at this point, I am feeling again that focusing on just building quickly "awesome stuff", without going deeper into the structure, leads to slowly growing mess, making any further movement harder and harder. Having enjoyed the more conventions and less freedom Angular gives over Backbone, I am now getting slowed down by Angular's flexibility!

Specifically, in my view, Angular gives too much freedom on deciding what logic goes into Controllers vs Services. E.g. there are way too many articles and tutorials with examples of Angular Controllers making $http requests! However, this encourages a bad practice - such request is a job of Service, not Controller! The code looks nice and neat in the article as long as it is small but quickly grows into mess.

It might actually be good, in my opinion, to see Angular restricting some its flexibility by enforcing some best practices, still leaving the door for older 'hacks', but just not making them so encouraging.

I agree that philosophical discussions on MWWs' can lead nowhere, but
people still look for some guidance, exactly because there is a flexibility in Angular that leaves too wide window for breaking best practices and writing a messy code.

Another example - is placing $rootScope inside a Service a bad practice? Is its use to broadcast an event down to Controller a bad one? Or should I use a two-way-binding instead whenever possible?

What about .run vs .config blocks? Is .run block to be avoided to make the code more testable? I am saving state in Local Storage and restoring it upon load - where this logic should go?

It would really help to have more articles with real but simple examples showing good Angular code structure and following best practices.
Let me define "simple". A simple example should be dedicated to one and only one purpose. For instance, if this purpose is to demonstrate Services, everything else should be cut down to minimum! No routes! No fancy CSS just to make it pretty! No excessive HTML markup. Just one thing. Please.
Add a comment...