> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I'm goin

> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I'm going to wager you haven't used, or are even aware of, "literally every frontend framework ever created," so we can agree you're being hyperbolic. There are plenty of front end frameworks that utilize JS, HTML, and little else, without introducing "magic" or vocabulary that isn't applicable. I agree with the OP that Angular, in particular, has a great deal of vocabulary to learn and a lot of things that are only applicable in the Angular world. This is one of the main reasons that I, and many other folks, have not spent much time with it. > The third point, in particular, is fundamentally what a framework does... it does some "magic" in the background to prevent you from HAVING to understand what's going on in the background. Just because you don't take the time to understand what's going on the background, doesn't mean the framework is "preventing" you from you having to understand what's going on in the background. Au contraire, we hear stories over and over about how the "magic" introduced by a framework caused issues that actually required knowledge of what's going on in the background. This isn't the fault of the framework, or the goal of the framework, it's a fundamental part of software development. For what it's worth, you're contradicting yourself by saying that "literally every framework ever created" applies to the OP's points, yet concede in your own point that "This does not necessarily translate from one framework to another, but can." Frameworks get in your way only as much as you let them. The underlying technologies are still there. > In the same way that learning Rails is not learning Ruby Learning Rails is a perfectly fine way to be introduced to Ruby. You're learning syntax, constructs, philosophies, and you can break out of Rails and do things with Ruby at any time. I mean, what do you think you're writing Rails code in? When learning to counter an argument, its best if you don't reiterate all of the points they made in some other way. You basically repeated all of their points, but I don't know if you're aware of it. OP: > This is Angular 1.x course. Angular 2, which is in the development right now, totally different. Your point: > Angular 2, an in-development long-term replacement for Angular 1 uses a very different approach to development, and will not translate well from 1.x to 2.x OP: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS Your point: > Knowledge you learn from using Angular is unlikely to be applicable to any other client-side framework, as original creators invented many new terminology as well as their approach to many things is unique OP: > A lot of "magic" will prevent you from understanding what is really going on behind scene. Your point: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS I'd be interested to hear some valid counterpoints to the OP, since I tend to agree with them, but these don't appear to be them.