I strongly disagree. The idea of a directive isn't unnecessarily complex because it isn't needed. And yes, there should be a pattern to force their use, for e

I strongly disagree. The idea of a directive isn't unnecessarily complex because it isn't needed. And yes, there should be a pattern to force their use, for exactly the reasons you specified. The claim that's being lobbied against Angular, however, is that they were schizophrenic in their choice of implementations for all of their patterns, or to state it another way, that the same advantages could have been gained with much, much simpler patterns. Instead of building a nice clean framework, they built an auto-magical framework, and declared you must learn every workaround in the "Angular Way" to use it. There are plenty of js frameworks now, many of which have analogous components to directives and controllers and views, etc. But while most, if not all of them, allow for the same advantages you've mentioned, few of them do so in such a complicated, boilerplate, and arbitrary manner. And this is scary, because it looks like they're continuing this trend with a completely new "Angular 2.0 Way". I'm going to go off the deep end here for a moment, but, back when I was in college, I took some marketing class where they discussed in depth the idea of user interface as a method of product lockin. The idea was if you built a product simple enough, but then obfuscated the correct method of usage correctly, you could make a product that was simple enough that new comers would be drawn to your product, but complicated enough that it would take so much time to master, that most who did so would actively desire never to leave as they were now the local experts. SharePoint really is a poster-child for this sort of dark design. And I think of this every single time I use angular, not because the ideas are wrong, but because of what simple things were implemented in a complicated manner, and what others were made auto-magical.