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. 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.

The second point is one of the tired pieces of non-sense that seems to never go away. Their was NOTHING wrong with the Angular 1.x approach to web development, because it started some time before the initial release in 2009.

A proper warning for anyone learning AngularJS should be a warning for any frontend framework:

* 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 (In the same way that learning Rails is not learning Ruby).

* All client-side frameworks take somewhat different approaches, and often use new terminology to explain that approach. This does not necessarily translate from one framework to another, but can.

* 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. However, Angular 2 is a modern-browser only framework, and the 1.x will be developed for the foreseeable future.

> 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 disagree. There are abstractions whose knowledge is easily transferable (e.g. promises, looping through a list of DOM elements), and abstractions that are not (e.g. directives/transclusion/$compile/etc). Angular is notorious (and has received a lot of flak) for having a lot of the latter, so I think the non-portability/magic warnings are warranted.

When have you ever picked up code that was written as an integral part of an application using a framework (not just a library) and dropped it into another completely different one without a fair amount of re-work?

Code and knowledge are two different things.

Unless you're using highly well-established APIs (such as promises), then of course, you'll have to rewrite things to match the new expected syntax.

Portability of knowledge is a different beast. For example, the vast majority of ng-repeat related concepts is completely non-portable (think `ng-repeat-start`, `track by`, `(x, y) in foo`, `$index`, etc). You learn that `ng-repeat="x in foo | filter: bar"` is equivalent to a for loop that displays only some items, but you can't really apply that knowledge anywhere outside of Angular.

You can't reuse your basic knowledge of for loops and if statements coming into Angular, and you can't use your knowledge about the pipe syntax anywhere else when you leave Angular.

In contrast, a framework that employs `.map` and `.filter` might teach you a bit about FP, and this is something you can use in Angular, Ember, React, and even vanilla js.

You are moving goal posts.

You are arguing that syntax equals mobility which is incorrect. .map and .filter can have different syntax depending on the language, just as ng-repeat (the equivalent to a for loop) has a different syntax than a for loop in Perl.

Knowledge and syntax are two different things as well.

> You are arguing that syntax equals mobility which is incorrect

No, I'm saying that the knowledge of the concepts of map and filter (as an example) is easily transferable even if syntax isn't. Once you understand those concepts, you can go look up the Ruby/Haskell/whatever syntax and you can reuse your new knowledge of higher order functions, and maybe learn about transducers, or maybe you can go look into point-free style, and the testability benefits of pure functions vs procedural style, etc, etc, etc. Not to mention that by knowing `.map`, you already know a great deal about the template languages for React, Mithril and Mercury.

In contrast, say I've learned about pipe operator precedence in ng-repeat expression clauses. Now I know I can write `x in (foo = (bar | filter: baz))` to memoize a filtered list for use later in that template. But only in Angular template expressions. But not in Javascript. Or Ruby. Or Haskell. And it's a terrible idiom to use in Angular anyways because [insert long rant about a bunch of unrelated topics].

Aside from the knowledge that operators can be recursively composed into god-awful expressions, what part of all that is useful if I migrate to Ember?

Or, say I learn about directives, and transclusion and the ngModel attribute micro language, and $compile and priority and the ngModelController API and ...

These are most certainly not syntax-related concepts. What does learning that get me?

That is a fairly edge/small point - using something like `.map` and `.filter` to generate the DOM itself is pretty ugly, and those functions quickly become useful in other contexts.

Check out Mithril: http://lhorie.github.io/mithril/ Using the regular syntax isn't actually that bad. It's unusual, certainly, but compared to HTML (when you actually think about it, rather than just say, "It's different and I don't like it"), it's alright.

Also, as a framework, it's got a lot less magic than Angular, and lets you write javascript code that's much more like normal JS code than angular does. (IMHO).

Also, the articles by the Mithril main author about JS & development philosophy are really good. I really like his style and approach to front-end development.

I'm curious... Any major websites using Mithril in production?

Guild wars 2 uses it for its marketplace interface.

lichess.org is another relatively large project that uses it (I mention this one because it's also open source)

Short answer - more often, than I could do it with angular code :) This is personal anecdote of course.

What's the long answer? I think it's laughable to say that you can take a part of a monolithic framework and drop it in as a replacement in a different framework.

Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?

very short answer - backbone.

longer answer - there is rarely drop in replacement, but when framework uses other well designed technologies, instead of reinventing the wheel, knowledge about these technologies way more useful, than knowing details and gotchas of $digest loop.

Examples:

* handlebars templates used in many frameworks. Quite often you can literally copy templates over into new project.

* usage of real promises allows you to use chai async tests without looking back at framework, instead of relying on right timing of firing $apply() (and making sure to not call it twice!)

* not relying on dirty-checking, and instead use setters/getters quite often forces you to think and isolate model code from glue.

* describing state via html (as it is proposed with ui.router - very popular component) can not be easily migrated at all, since most of frameworks define state in code and/or configs. This is paradigm shift.

While I agree, the bigger framework, harder it gets to write portable code, but angular in practice tends to make it even harder in my experience.

So basically, your problem is you like to pick and choose modular pieces from non monolithic frameworks and "Angular sucks" because it doesn't do what you like.

There's nothing wrong with Backbone, particularly when you like to replace parts with other parts. But Angular is not bad simply because modularity wasn't a design goal.

It's notable that your arguments aren't arguments against Angular persay but against every single non-modular framework ever made.

I don't mind people disliking Angular. I mind it when people pretend their preconceived notions about software design are "right" and software that doesn't align with their notions are "wrong".

I don't like when I can't replace broken part of framework. And this is often the case with angular. Mostly because of foundation it is built on - dirty checking and it's own dependency injection mechanism. Because of these two there are a lot of things backwards. dirty checking is major cause of whole $digest loop, as well as every async function being mirrored via $-equivalent and non working promises. This cruft accumulates over time and wastes a lot of human resources.

The only reason you might not dislike angular is if you never had to deal with issues above OR you never had different experience, sorry.

Like I said, that's a ton of opinion based entirely on YOUR desire to replace parts YOU don't like. Dirty checking isn't perfect (by any stretch) but it's not the worst thing to happen since the cold war either.

The bottom line seems to be that your bad experience is relevant while all good experiences are irrelevant because they weren't your bad experience.

That tells me you simply don't know how to use it, sorry.

A number of times: but the code was heavy on business logic, which was factored into a domain model. The UI code was simple, it was broadly mapping domain concepts (states etc) to UI concepts (colors, visibility of various elements).

There are different "level" frameworks are out there. Ember/Knockout/Angular gives you a lot of magic. Backbone - not so much.

Most concepts in Angular came from Spring Java (server-side, one request at a time,) which is absolutely unique to client-side frameworks world at this time. Reason behind this is very likely that Misko himself was server-side engineer at Sun before coming up with Angular, and he invented framework without working with other client-side frameworks, so he could not learn from their mistakes. So these specifics are not transferable to other client-side framework. Moreover - this knowledge likely will not be transferable to Angular 2.x too.

You are completely wrong on your assumption when you are linking AngularJS's origin to Server-Side Java.

Most of concepts in AngularJS directly came from Silverlight and WPF. Before even Angular came into existence, I used to use the same pattern for building Windows/Browser centric client side apps on WPF/Silverlight. When AngularJS announced in 2009, it took me 30 minutes to get my head around everything & there has not been much changes since then.

The only thing AngularJS invented was Dependency Injection for JS.

If memory serve me well, WPF and Silverlight were brought around 2007-2008 by microsoft. Angular was released around 2009. Spring Framework in 2002. Misko was Sun employee and worked with Spring a lot and mentioned it a lot. I did not find any reference to silverlight and or wpf in his talks/posts so far.

Next - I am not saying that idea of applying server-side mvc patterns as-is is unique, it is certainly not - your example of wpf and silverlight are good examples. Also, probably, reason why these did not stick well outside corporate environment, where decisions are made by managers and not people actually having to deal with it.

If you have solid source explaining origin of angular - i will be happy to be corrected, but from everything i read so far to understand better motivation behind sometimes very questionable decisions I always find similarities between sun/java/spring.

In the process of learning Backbone using Addy Osmani's excellent guide (http://addyosmani.github.io/backbone-fundamentals/) as well as reading the heavily annotated Backbone source code (http://backbonejs.org/docs/backbone.html), I've learned a lot about javascript, the problems SPA frameworks have to solve, common patterns for solving those problems, and how they can be implemented. Before backbone, I tried my hand at angular and stopped when I realized the only understanding I was going to gain by learning Angular was how to use Angular. It's a very different kind of beast.

I previously had no interest in Backbone but those are absolutely amazing learning resources.

> 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.

It is funny how you bring up another "Cool Kids" tech aka react.js, which is not even comparable to angular's scope in the first place. React at best is abstraction on view layer. And over engineered one, btw. If you want to have separate view layer with little binding boilerplate I personally recommend checking ractive.js (this is only view part! not a full framework, so don't try to compare it to angular)

Also it is not "Cool Kids" thing, it is personal observation how backwards some angular solutions are from working for a year on large team and large angular project and reading ALOT on all possible best practices.

You miss the point. The Cool Kids comments was about how it's become fashionable to talk down about every new framework, UI library or whatever that becomes "big" because something 12 people use is OBVIOUSLY so much better.

To me much of this "this is better because this" is a lack of understanding your tool and/or personal bias leaking into the design decision for a piece of software.

I like Angular for what it is and using it on a year long project with a large team on a large project suggests that your decision makers did virtually NO research on what Angular excels at.

The problem (judging based on your small comment history on this thread) suggests that Angular isn't a problem, it's that EVERYTHING is over-engineered if it's not modular. And while I appreciate the modular approach having many benefits over non-modular frameworks, pretending that it's "The Only Way" is just as silly as pretending Angular is the answer for everything.

As i mentioned in other reply, you are wrong about reasons I dislike angular and why I can not recommend it to newcomers. Reason is - incorrect foundation of the whole framework, the rest is just consequences of it. Angular 2.x might change whole picture, but, again, it will be totally different beast. To the point that I am not sure it is reasonable to call it angular anymore, except for marketing purposes.

In fact if you spend a bit of time to see where from creator came, you understand why he did what he did. Also, if you had experience with server-side mvc frameworks you find all these concept very familiar. Also, if you built any type of complex client-side application, you will find, that server-side MVC concepts, based on single request = single response are not appropriate for long living client-side apps.

Sorry, there is just lack of perspective on your side and there is not much we can argue about.

> "The definition of a framework is abstraction."

It's actually "a basic structure". Which seems to work much better. Your definition would make this:

  trait Storage {
    def put(path: String)(bytes: TraversableOnce[Byte]): Unit

    def get(path: String): TraversableOnce[Byte]

    def rm(path: String): Unit
  }

A Framework. Which is obviously wrong.

Reusing a basic structure to short circuit some engineering tasks and hopefully accelerate the development of others. That's a Framework.

Regarding you first point, it was the community's perception after last year's ngEurope, but not so much after this year's ngConf.

With the current focus on component-based design in Angular 1.x, the meat of your app would be fairly easy to move to angular 2. Much of the job involves removing code and I believe it can, and will be automated in due time (with some shortcomings, to be sure).

Moreover, the core team has put a focus on making 1.x modules compatible with 2.0 and 2.0 modules compatible with 1.x so that you can migrate progressively.

Unlike with React, you don't start off with a clean slate and that's a major shortcoming, but I think right now Angular is still a solid choice of client-side framework, mainly because of its enormous community and iteration speed.

The main trouble is, you need to be following the latest developments and best practices, otherwise you'll probably end up Doing It Wrong™.

This is Angular 1.x course because Angular 2 is nowhere near stability. It also won't be for another few years - that's how long it takes to build an ecosystem of packages around anything. I'd say apart from people wanting to contribute to Angular 2, or maintaining packages that may need to be ported to Angular 2, nobody should learn it right now.

The other two arguments are actually not in favor of the point you are trying to make. For beginner wanting to just have something awesome working, Angular is a perfect way of getting hooked. Sure, for senior JS developers learning Angular is perhaps not the best move - it is very isolated, built on assumptions suited mostly for small websites and, as you said it, "magic". Those are the reasons why Angular 2 is so different.

Not to rain on your parade but, would you call Google Cloud Platform's client-side a small site?

What are your arguments for claiming that?

https://www.youtube.com/watch?v=cVTN8msr5DE&list=PLOETEcp3Dk...

Is there place to look at actual product, without being paid client? I am looking right now at Console and it is indeed very simple app. I am desperately looking for indeed large projects made with angular 1.x because company I work for is in the middle of pretty large project where we stumble upon many angular shortcomings which I have no idea if even worth trying to search for solution.

Have you watched the video I posted? In there they explain the magnitude of the site.

And yes, it looks _simple_ that's the point. You don't want a bloated client, you architect a solution to only load what needs to be load. If your app is 25 MB you don't want to send ALL that to your client in one go. Watch the video please.

I watched video, it is just overview. We currently solving same problems and a bit more (we do heavy localization.) And unfortunately level of details provided in this video are not enough to see how specifically they e.g. load module, how they load module dynamically with angular, how they update routes and trigger these again, how they update dependencies in run time for already loaded and registered modules.

This proved to be more complicated than it should have been and I am looking to see real app in action to view code and learn from it. Paying (or becoming trial user) is not part of what I want to do to learn from that :)) That's why I was asking where actual app I can touch resides, if it is possible to try it without submitting my credit card details :)

Then the problem has nothing to do with AngularJS per se, but how you package and deliver a web app in general.

You need to learn about asset management. Take a look at webpack for example: http://webpack.github.io/

In the video they explain the strat behind how they managed to make a big app load only the necessary parts. With that, and some researching on your part should be enough to get you on the right track.

In any case, your argument doesn't hold. It isn't only for small apps. ;)

Believe me, this is problem with AngularJS (mostly because they invented modules/dependencies and decided to stick with it despite obvious deficiencies instead of teaming up with other open source projects and using something like require.js

Strategy is easy part, as this stuff done many times already. The devil is in details about how to actually get into guts of angular's dependency and routing systems.

I would say 'magic' argument is controversial. On one hand you want people get easy start, on the other hand, you might not... Don't know :)

As for very-angular specifics - it was right there is course outline - directives/services/etc. This knowledge is unique to Angular 1.x (i.e. most of it will be irrelevant even for Angular 2.x)

> Knowledge you learn from using Angular is unlikely to be applicable to any other client-side framework

Can you suggest any other JS framework (for a beginner) which fits above criteria?

This is tricky question. When I started there were framework like YUI, Ext.js, SproutCore which were... well... complicated and locking you up.

After that I found Backbone.js and it just clicked. Most of the code produced for it is pretty portable, as there not much of framework given to begin with. So it was very easy to start hacking with.

Small size of Backbone.js comes at its own costs, like lack of memory-management. But with small apps memory management should not be a problem, and by the time it become a problem, you probably will understand issues at hands well enough, as well as will be aware of Marionette.js.

Backbone.js/Marionette.js (and similar size frameworks like Mithril.js) still requires quite a lot of boilerplate code, that what react.js and higher level frameworks try to solve, each in their own way. So by that time you either find one to fit how your brain works, or find your own combination of lower level components which essentially will form your own framework, which you will understand very well by that time.

That is my vision. Why I tried to warn about angular - while most of the terminology/architecture choices you learn from most client-side frameworks are very transferable to others, angular's - does not. Therefore knowing angular is important if you day job is UI engineer, since it is very popular choice, especially in corporate environment lately, I would not recommend it as very first and, especially, the only one, framework to learn. Hope this make sense :)

Definitely Mithril.js – classical MVC that takes care of the view layer (and more!), with everything else pure JS. No "model" wrappers, no event publishing/subscribing, no made-up module system. The better you get with Mithril, the better developer you'll be overall.

Yes it is Angular 1.x and as we all know the world is not static. It's fair to say that learning Angular 1.x is still probably a valuable skill. I do think that abstracting away nuances of JS is actually important in facilitating learning, but I could see how that might hamper your ability to apply this learning to the real world.

Do you think that the concealing of complexity is harmful in the long run? I certainly don't. I think there will be some shock when you try to go straight from codeacademy to the real world, but it's probably less of a shock than going from 0 to real world coding.

In the long run, I can easily see codeacademy building a suite of courses that get progressively less and less "magical" until there are no longer any training wheels. That's going to be quite compelling if they can make it work.

Full disclosure: Terminal powers codeacademy's production and staging workloads.

"Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke [1]

Not having taken the time to understand how something works doesn't give you an excuse to decry it as "magic" and move on. Clearly, Angular is constrained by computability as every other computer program also is. There's no magic involved, just dirty checking, which is a well-established pattern.

As engineers, designers, developers, whatever, we ought to know better than to claim anything as magic. It obscures the real problems and breeds a culture that says it's okay to do so.

[1] http://en.wikipedia.org/wiki/Clarke%27s_three_laws

Don't get me wrong, by now I more or less versatile inside angular's guts. But the way stuff 'magically' appears in the html template might serve not so well to newcomers. The way it hurt - is when you stuck with some issue due design choices (dirty-checking loop) and have no clue how to proceed, nor there any really good sources to get answers, while reading angular code is plain painful.

Compare this to small scope of Backbone.js, whose source code can be read easily, and you might see why i am against angular's magic for newcomers.

Not to beat a dead horse here, but as others have said, Angular invents a ton of new terminology for no apparent reason.