If you don't know anything about client-side frameworks and consider Angular as your first one, keep in mind following:
* This is Angular 1.x course. Angular 2, which is in the development right now, totally different.
* 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 (not necessarily in a good way)
* A lot of "magic" will prevent you from understanding what is really going on behind scene.
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?
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 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.
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?
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.
> 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.
> 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.
The definition of a framework is abstraction. That's not hyperbole, that's fact. Frankly abstraction is programming since all programming languages are is an abstraction of machine code.
I'm not going to bother responding to you point to point, since I made valid counterpoints that you are hardly qualified to dictate as "not valid". The OP's post was opinionated half-truths designed to be pissy about Angular because that's what the Cool Kids(TM) do these days. It's gotten boring...
But hey, it won't be but a moment before more boring people have more boring complaints about React. Naivety has no end.
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.
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.
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)
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.
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.
Don't bother. Spend time with a JavaScript framework that will actually reward your time spent. AngularJS 1.x has a steep learning curve due to over-engineering, a terrible templating system, and is completely incompatible with the upcoming AngularJS 2.x series.
If you're looking for your very first single-page application library, try MithrilJS. It's small and easy to pick up quickly: https://lhorie.github.io/mithril/
That's an odd conclusion to reach: what drew me into Angular in the first place was it's extremely shallow learning curve. Going from nothing to prototype is extremely fast, and if you mock your data correctly, can be leveraged into production code.
What eventually pushed me away from Angular is the performance of the scope digest cycle (which you won't even notice until you've built a large enough app to have a problem) and the odd state management issues that arise as a result of two way data binding.
It is all about where you draw a line. For example in my day job most projects require some form of dynamic loading parts of applications, which is VERY hard to do in proper way with angular. So if you need to make prototype with some fields auto updating some values somewhere - angular learning curve is probably fine. If you need to build complex and large UI - learning curve will be extremely painful.
Sadly that library misses the point: MVVM. With angular I get to tie my user interface to my model in a declarative way, my model doesn't really have to be anything but a simple javascript object, I can use straight html to design the interface and when something changes I don't have to think about it.
If you haven't ever worked with MVVM, do so. It is a treat.
`ng-model` is actually one of the "magic" things that @hippich is warning against. Having used Angular (and built Mithril based on lessons learned from using it for a few years), I agree bindings are handy in a lot of cases. That is, until you need to work around them (maybe because your inputs are laggy, or you've hit the infamous 2000-binding-ceiling, or whatever). Then, they're not such a treat anymore.
With Mithril (and fwiw, other virtual dom libraries as well), you can choose to add the convenience of bindings where you find appropriate.
The points about POJOs and HTML syntax are, similarly, aspects that you have control over.
Is there an actual reason to use AngularJS that's not just hype? It seems incredibly over-engineered to me, compared to something like React. I realize it's the newest, coolest thing, but...why?
I feel like I'm taking crazy pills, what does React do exactly - what does it replace? I read the landing page a couple of times and I don't quite understand what it's supposed to solve.
React allows you to build stateful javascript components in a nice manner. Think change propagation. You have a visual tree of a parent component and many child components. React makes it really nice, easy, and fast to propagate changes up and down your visual tree. Very MVVM-like, to me. You change some state, and React takes care of updating the appropriate visual components.
This is achieved with some custom syntax and also a fake/virtual DOM that you work with. The gain from all this is speed. It's impressively fast, in fact.
From the official website of both technologies:
React: "A JavaScript library for building user interfaces"
AngularJS: "AngularJS is a structural framework for dynamic web apps".
So, aren't they two different things? (Honest question since I haven't play with React yet).
Yes, they are. React deals with more of the templating side of things (many people use it as the V in MVC, or in some cases as the V & C). But along with React, Facebook also released their Flux architecture which isn't a framework but a new approach to the MV* pattern which many people are using with React. Part of the Flux architecture is a concept called "Dispatcher" which handles the flow of data throughout the app. Facebook did release their code for their implementation of a Dispatcher but not much else. So React + Flux can act as a complete framework, but React alone does not.
The combination of React with a data/state management pattern such as Flux (https://facebook.github.io/flux/) is fairly analogous. You can also just use something like Backbone models (for example) with React if you want to use a more 'traditional' JS MVC pattern.
React even say themselves they're just the V in MVC. Angular is full stack. What you need and which is best is probably up to yourself to answer. I personally found it nice that angular is a working framework, instead of having to piece together a framework myself using react++
AngularJS empowers your HTML. Done right, your JavaScript files are concerned only with retrieving/manipulating data, and your UI code fits snugly into your UI description.
Compared to managing the DOM in both your HTML and your JavaScript files, AngularJS seems so much better organized.
I spent the majority of last year working on an Angular project, and I have 3+ years as a Rails dev.
One thing that's surprised me is I get nearly as much attention from recruiters for Angular work as for Rails. I think this is mostly due to the .NET world embracing it, they tend to be enterprisey gigs.
Give it a few years, and Angular 1.x is going to be like COBOL in the early 90s. Lotsa code out there to maintain...
Company where I currently work, feels pretty happy about using AngularJS 1.x.
We aware of Angular 2 and very glad to see changes (especially Rendering Architecture).
We know there will be migration path, but it's not so important - projects, which works good with 1.x, will remain on 1.x branch, and this branch will be supported long time enough.
When Angular 2 will be released, we are going to try it in new apps. We are playing with ng2 in sandboxes like https://github.com/pkozlowski-opensource/ng2-play and changes are not as dramatic as most people thinks. Well, maybe forms and 2-way binding, but everything else just got more modern API mostly.
A lot of time was spent training people on angular. Angular being so big meant more training. I'm guessing our Tech Leads are more comfortable with React because it isn't a framework.
The main issue stemmed from research, development, and training costs from what I understand.
I recommend Backbone as a first JS framework. As mentioned above, it contains less "magic" (and far less code) than any other framework of its popularity. You can read the source for Backbone in an hour and will likely learn something about good Javascript practices, and self-documenting code, in doing so.
Moreover, Backbone is a great example of MVC, the understanding of which is useful and highly transferrable to other (even non-JS) frameworks.
As many people are echoing in the comments, I'd go with React just because it's so easy to get started with. Once you get into it, the Flux pattern is pretty sweet although it's being morphed to use Relay/Graphql which are pretty creative.
Also, React Native is the new way they're proposing to build native mobile apps; definitely new but worth it to learn React in case this works out.
I would definitely push people towards learning Meteor. I know it's a full stack framework instead of just a front end framework but for rapid prototyping, it's fantastic. The community for Meteor is a bit hit or miss because it's so "magical" but it's worth a look too.
Disclaimer: I've only ever done about a week of Angular so I cannot compare features.
Angular really needs ui-router, lodash/ramda, and jquery (for more than just AJAX).
React doesn't need a router for many uses (extending existing sites), but does need lodash/ramda and an AJAX library. ImmutableJS is useful for both angular and react (as is rxjs/baconjs). For a beginner, I would simply say React, Reflux, Ramda, and jQuery will do 90% of the things. Learning all four of these libraries (they probably already know jQuery) will take less time than Angular and be more flexible if they want to swap one out later.
Finally, adding these is much easier with commonJS than the angular dependency injection (often on top of commonJS).
I like all the libraries that you end up having to use with React (and I end up using Lodash with everything anyway). I also think React is a better solution most of the time, but it requires knowledge of the JavaScript ecosystem to grab all the libraries you need whereas Angular does not. As a newbie it can be hard to identify not only what libraries you need but also what is the best of breed.
I've also heard good things about Knockout, but I haven't reviewed it. Ember is also popular; I've used it and prefer React.
Some people will say that it's unfair comparison because React does so much less than Ember and Angular. To that I can only say: Yes, and that's part of why it's better.
The reality is that Angular 2 is probably going to be the dominant framework, so if you don't want to learn Angular 1 then it's probably best just to wait six months to learn Angular 2.
To be honest, I started learning VueJS first (vuejs.org) and that got me into the line of thinking of MVC/MVVM. After I finished my project prototype with VueJS, I ended up going through an Ember tutorial or two and rewrote that VueJS app using EmberJS. I highly recommend EmberJS because of its painless upgrade process, strong conventions, and awesome community. Once it clicks, you'll be amazed by how fast you start shipping out features and building complex UIs.
Every time a new framework appears, it feels like this is it. But as time passes you start seeing people's feedback and experiences. I see same pattern for AngularJS, Backbone.js and the recent one React.
So, the point is, don't believe the hype, try yourself and then decide if it is for you or not.
It ought to mention this somewhere, no? Otherwise I suspect some people might feel they'd wasted 5 hours learning a possibly-soon-to-be-outdated technology. (This would be less important for Rails, say, where the changes between 4 and the next major release - or even between 3 and 4 - would be less drastic.)
You're right, we probably ought to mention that in the description, regardless of how long the Angular team will be supporting 1.x. Sending that feedback to the content team.
ETA: http://www.codecademy.com/learn/learn-angularjs
"Learn how to build web apps using AngularJS 1.x. By the end of the course, you'll be able to use AngularJS to create powerful apps of your own."
The Angular team has said a few times that they're committed to supporting 1.x for a long time[1] since they use 1.x a ton. Also the design for 2.0 hasn't been completed yet, so it'd be a bit premature to cover it in a codeacademy course
I agree there shouldn't be a course covering Angular 2.0 yet. But I would also say that any course that you can start today which covers Angular 1.x probably should mention (in big text!) that there's a big new version of Angular coming out in the not-too-distant future and that it is fundamentally very different from the current version of Angular.
I feel less bad about companies being screwed over by this sort of massive change - any tech manager/architect/lead who is researching what JavaScript stacks to choose for future projects should either already know about Angular 2.0 or have the available means to find out about it (and if they either don't or can't, they're basically just bad at the job they're being paid to do) - but for students, in any sense of the word, it's a different matter.
when will the angular 2 release?
i just (10 minutes ago) complete the first course on codeschool. but since there's this big change i'll wait before taking the next one.
I believe it's to be released later this year. If you're learning front end frameworks thought 1.x still isn't a bad bet. Angular2 is going to be dramatically different, and because of that, they are going to maintain 1.x for quite some time after 2 is released.
Also, the job market for Angular developers is high, and a lot of those companies wont be migrating instantly. If you're looking to get into the field 1.x isn't a bad bet.
You'll have to learn Angular2 someday, but then again, the life of a front end developer is constantly learning new frameworks / technologies.
Learn angular, we need moare minions to overcome the world with insanity.
Anarchy!
Angular has been created by the illuminatis to drive people crazy, help them, help the chaos spread the world.
Mouhahahahah
(Yes I can do angular, and yes it is insanely complex and shitty with a lot of Java desgin patterns like IoC from the GoF that are very suitable for java, but totally useless in javascript...
Someone still must think we are in the 90's and that the java in javascript means they are related)
* This is Angular 1.x course. Angular 2, which is in the development right now, totally different.
* 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 (not necessarily in a good way)
* A lot of "magic" will prevent you from understanding what is really going on behind scene.