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.
> timing is incredibly poor, and is coming when many people are just learning the framework
For a successful project, timing will always be "incredibly poor", for a popular project always attracts new developers, often at an accelerating rate.
If you only plan to make serious changes when very few new developers pick your project, it might be belated because your project is already dying.
When the docs are still in such bad shape and the number of books doesn't even come close to other niches of our industry, it's really bad timing.
They need to solidify what they have and make sure they're the stable choice.
With the latest announcements, I'm tempted to check out React and just fall back to jQuery because the learning curve is too steep. I even run the Learning AngularJS newsletter and I'm saying this! :(
I had a lot of issues, from a conceptual standpoint that pushed me away from using angular... parts I really liked or wanted to like, but others were just cumbersome to use/implement. I'm using flux/react currently, but in 2-3 years that may change to Angular 2.
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.
Yeah I agree it's an oversimplification. It's tough when writing a piece like this where a deep level of language knowledge is required to make a clear explanation. I tried to lead people toward the cause without getting bogged down in too many details.