4 ms·

Unfortunately, that issue isn't limited to angular: it falls under the general category of "If you haven't gotten burned by the problems a pattern is trying to

Unfortunately, that issue isn't limited to angular: it falls under the general category of "If you haven't gotten burned by the problems a pattern is trying to solve, a pattern looks like unnecessary complexity." I'm reminded of when I had to learn COM back in the day; as a developer who had cut their teeth on programming on Macintosh followed by Debian, it seemed like needless complexity until I grasped the zen of the problem it tried to solve: providing a common protocol for different binaries compiled by different C++ compilers to share data structures and do inter-process communication in an object-oriented fashion without sharing source code. COM seemed way too complex to me because (a) in the Mac world, there was only one compiler that mattered (at least by the time I got into it), so binary incompatibility was essentially a non-issue, and (b) in the Linux world, if you needed two modules to inter-operate, you could meld their source code together. Similarly, if you haven't tried for 100% test coverage, dependency injection seems needlessly complicated, and if you haven't had to nest dozens of HTML templates written by different developers using different patterns, directives seem way over-engineered.

ep103 12y ago
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.
- fixermark 12y ago
  To pull it back a bit from the deep end: another possibility besides intentional vendor lock-in is that AngularJs dates back to an initial public launch of 2009 (and was likely older than that in the bowels of Google's infrastructure), while the frameworks that have been mentioned in this thread are younger (react: 2013, boostrap: 2011). It's quite possible that angular is simply over-engineered to solve the problems it's targeted to solve and other, younger frameworks have second-mover advantage on architecture and design (while angular has first-mover advantages of "Older, therefore more well-understood" and "wide adoption base"). COM wasn't the last word on binary cross-communication either; for various reasons I see that sort of thing done a lot more often these days via building a RESTful HTTP service, even when the intent is localhost-only communication.

ep103 12y ago

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.

fixermark 12y ago
To pull it back a bit from the deep end: another possibility besides intentional vendor lock-in is that AngularJs dates back to an initial public launch of 2009 (and was likely older than that in the bowels of Google's infrastructure), while the frameworks that have been mentioned in this thread are younger (react: 2013, boostrap: 2011). It's quite possible that angular is simply over-engineered to solve the problems it's targeted to solve and other, younger frameworks have second-mover advantage on architecture and design (while angular has first-mover advantages of "Older, therefore more well-understood" and "wide adoption base"). COM wasn't the last word on binary cross-communication either; for various reasons I see that sort of thing done a lot more often these days via building a RESTful HTTP service, even when the intent is localhost-only communication.