How Angular Does MVVM

---

• What you need to do MVVM, in a nutshell:
  • A bespoke model for each view, with 2-way databinding being the sole link between the "view" and this "view-model".


• This pattern was primarily devised by Microsoft to fix inherent problems in how their desktop apps were designed and built, but it can be used for web apps as well.

How Angular Does MVVM, Cont.

---

• Angular officially supports MVW.

  a.k.a. "Model-View-Whatever"



• The basic AngularJS application structure is
  • Standard HTML (View).
  • A scope object databound to the view, decorated with a "controller" class (consider this the ViewModel).
  • And "services" (either core Angular services or ones you wrote) which are injected into the controller class constructor by the Angular DI mechanism. (this maps to the Model).

How Angular Does Databinding

---

• Databinding in the world of modern Javascript apps is more or less uniform in terms of features, the differences between various frameworks comes down to syntax and the mechanism used under the covers.




• Databinding is core to how AngularJS works, as you'd expect, but again its primary purpose is to be an SPA framework, so if you just want databinding, it's probably more than you need.



• Super-simple databinding example with a computed property


• Another databinding example with routing.

How Angular Does Databinding, Cont.

---

• Angular does not use change listeners or "observable properties" like Silverlight or Knockout in an effort to avoid the overhead those techniques bring with them.


• It also uses your POJOs directly, no special calls, inheritance or other setup.


• Instead it uses "dirty checking."

Ridin' Dirty

---

To contrast dirty-checking (AngularJS) vs change listeners (KnockoutJS and Backbone.js):

While dirty-checking may seem simple, and even inefficient (I will address that later), it turns out that it is semantically correct all the time, while change listeners have lots of weird corner cases [e.g. change coalescence and change listener synchonization] and need things like dependency tracking to make it more semantically correct.

KnockoutJS dependency tracking is a clever feature for a problem which AngularJS does not have.

--Misko Hevery

They See Me Checkin', They Hatin'

---

• So this dirty checking technique seems like it'd be slow, right?


• In reality, it's really fast. Turns out most browsers from IE8 on up are really good at executing Javascript quickly.


• 10,00 listeners on a single page: 6ms on a recent browser, 40ms on IE8.
  Anything under 50ms is pretty much instantaneous from a human perspective.
  • Angular vs Ember vs React Perf Test
  • Angular vs Knockout vs Ember vs Mithril Perf Test
  • ..and there are lots more on jsperf.com


• Benchmarks should be taken with a grain of salt, but it's pretty clear that dirty checking can be as fast (or actually faster) than other methods.

Angular and ASP.Net

---

• ASP.Net isn't built for single page applications. The top hit for SPA development on http://www.asp.net/ uses AngularJS and WebAPI.


• For that and other reasons, ASP.Net isn't currently very popular in the webapp world these days.


• Microsoft is radically retooling ASP.Net right now in an attempt to keep up, as well as adding first-party support for Angular and other JS tools to Visual Studio.


• You can use Angular with ASP.Net MVC, but it's a bit redundant and silly since you have 2 frameworks with overlapping functionality.

Angular and ASP.Net, Cont.

---

• Using Angular for the client and .Net serverside logic via a WebAPI or WCF RESTful API is a very nice solution on the other hand.


• This leverages the best of both worlds, will Just Work, and is miles away from the fragile, boilerplate-laden stuff you used to need to use web APIs in clientside Windows apps.

Future Shock: Angular 2.0

---

• Angular 2.0 is the next version of Angular, it's about 2 years away at this point.


• It will address and simplify a lot of the more arcane aspects of Angular, like directives, while improving performance, nuking the jQLite dependecy and DOM wrappers in general, and being coded in an ES6-based superset of Typescript.


• It will also break compatibility with 1.x, which will continue to get security and bugfixes.



"Once we have an initial version of Angular 2, we'll start to work on a migration path for Angular 1 apps."

--AngularJS Team Blog

Future Shock: Angular 2.0

---

• Takeaway: 1.x is great and 2.0 will be even better. If you're building something now use 1.x, if you're building something 3-4 years from now wait for 2.0.