mckinnsb

I honestly think this article does a massive disservice to the discussion by ignoring that independent contractors are required to pay their own taxes and some of the savings that a company receives by electing to hire independent contractors over employees come directly from not having to match the employee's FICA contribution. I love Uber and Homejoy as a service, but honestly if they are the people setting the rates any "middle ground" established by the government should require them to pay that FICA contribution, and any relevant self-employment taxes ( like we have here in NYC ). It's only fair.

I was just having a conversation with a friend of mine regarding if we should spend more effort in learning Angular.

While I can understand making breaking changes, and sometimes very big ones, I feel like this timing is incredibly poor, and is coming when many people are just learning the framework. At this point in time I do not want to invest any more time in the framework or its changes: the stable version I use will soon be obsolete; I can't learn the "new" version or use the "new" version now; and I don't know when the point will come when the AngularJS core team - and Google - are happy with the decisions they have made, if the point EVER comes ( especially re: Google ).

I also feel that while they addressed many of the concerns that the community had, the decisions they made were not strictly speaking "necessary". For example, removing all the ng-* stuff "looks" nicer, but it is now less clear which code is repsonsible for handling that declarative behavior. I would have preferred a mechanism which allows you to specify other "included" directives in a directive definition in a clear and concise manner ( without hacking on compile or link functions ).

I think I'm going to try Ember or something else. I liked Angular for what it showed me - that a data binding approach could really ease the pain of radical design changes, for example - but I'm not going to be sticking with it after this project. Time to move on.

I tend to do it by application domain, not necessarily feature or type. Domain usually encapsulates the things that need to work together and provides clear lines for SOC.

Hey - #8 regarding "consulting the prototype chain if the value is an object" is something of an oversimplification, and slightly incorrect. The prototype chain is more or less always consulted because that is the only way to evaluate the property on a child scope.

What is happening in the first example is that the ng-bind directive is creating a new entry on the child scope, called "user", which overwrites the reference to the property defined in the parent scope. When you ng-bind an attribute of an object, your child scope is not changing the reference to the original object, so both scopes will show updates.

Example fiddle: http://jsfiddle.net/02f4o7u9/1/