A couple months ago I created an Angular app just to try it out for myself (only NYCers will find it useful: http://summerstagelove.com) and it was the first Javascript-using website, since having learned jQuery 5+ years ago, that I've made that doesn't include jQuery...I tried for awhile to get jquery.isotope.js to work but didn't know enough about the order of callbacks and such in directives, so just left it out entirely.
I've developed enough Rails apps to think architecture-first...but thinking back in my jQuery only days, the OP's question seems like it'd be a very common one among jQuery-only-front-end developers...and the top-answer is excellent: if you don't include jQuery, then you're forced to think about the architecture, and you'll be better off for it as a developer.
Isotope is a jQuery plugin, so it stands to reason that you'll need it. Angular will use jQuery over jqlite as long as you include it first.
I use isotope with angular and have written directives to support it. I haven't written it up, but If you're interested, I can share some of that with you.
I'm very glad to see that this answer hasn't been closed as not constructive! It seems like most popular questions like this are, even though they're incredibly useful and insightful.
I was leaning toward learning Ember, but this post makes me really curious about Angular. In particular, the ease of testing has my interest piqued. Is testing as simple/easy with Ember? I know that unlike Angular, Ember doesn't have DI as a core feature. Either way, I should probably just flip a coin and start learning!
I was disappointed that it hadn't been closed. The first answer is a backhanded dig at non-angular developers saying that angular is about architecture and implying that the others aren't.
I like angular but "angular architect" rolls off the tongue too easily.
You're disappointed that a really informative answer has not been closed because of some subtext you've read into it that may or may not actually be there? That doesn't seem like a very productive attitude to me.
Actually, no, the person who wrote the so-called "answer" which is more like an essay (and therefore not a proper Stack Overflow response) isn't a google employee. I didn't mean to imply that.
OK, then I'm unclear on why you brought up my employer. Did it have something to do with my support of the answer in your mind? Like is Angular a Google project? Or was it just some random thing you could attack?
How is the framework having unit tests ( and please, don't say TDD, when you mean unit tests) say anything about how testable code written using the framework is?
How well do screen readers for the blind and AngularJS play together?
I thought that JavaScript-based frameworks are often not very compatible with screen reading technologies, but have not investigated what advances have been made for the blind in this area.
I was about to come back here and yell at you for making a post about accessibility unaccessible to the hard-of-hearing (and those of us who browse with SOs sleeping right next to us that we never, ever, ever want to wake.) Then I saw the transcript below the fold.
We've built a large AngularJS application and one of the requirements was screen reader usage and keyboard accessibility. It took some effort, but it works very well.
It shouldn't. AngularJS should work great in most situations, even for simpler pages. I'm a big fan of MVVM pattern as it lends itself to a hard separation between the nitty-gritty view details (e.g. effects, transitions, styles, etc.) and the rest of your business logic. Create your view, declare how it should behave based on view-model values and then hook it up to your core business logic that is now completely agnostic to your view details. jQuery, on the other hand, forces you down the path where your business logic needs to care about how the view should render the content, and those ugly view details are sprinkled all over the place.
Angular is pretty cool, but it's hardly the only neat way of seperating and offloading view detail work.
And jQuery is just a (much) nicer-than-native DOM/browser API. It doesn't provide an application architecture or data bound view handling layer because that's not what it's for, and it no more forces an application style than your text editor does.
This isn't to say that Angular isn't nice for projects short of Gmail's scale (I would/am considering it for some small scale stuff), it just doesn't make much sense to say jQuery forces people a direction by not providing features that aren't really part of its purpose.
You can write maintainable code in any language, but certain languages, frameworks, and libraries lend themselves to certain patterns. It's very easy to do the wrong thing with jQuery.
I consider Separation of Concerns, Dependency Injection, and TDD to be basic software engineering principles. Sure if you have a mostly static page with a few dynamic components jQuery will work fine, but with a larger project that you really need to consider a more maintainable architecture.
Absolutely. Honestly it seems to fly really far with the node youngsters who want to code all night for some reason. What you're talking about is event delegation. It's a one liner practically, but shh, we're talking about "architecture" now.
AngularJS is an MVVM framework. It's fairly new to JS and front end web development, but not that new for UI development in general (it's been around since 2005 in WPF and used in Silverlight and Flex applications, and possibly others). It isn't just 'event delegation'.
Indeed. Rich Hickey's 2-part presentation on "Clojure for Java Programmers" was a really slick presentation of a Lisp. (Focusing on the 'code is data' aspect from the beginning (at least once he starts talking about the language specifics themselves, he does spend a while motivating dynamic languages) rather than talking a lot about just higher order functions and macros and so on. He goes over the evaluation model and its difference from a Java/C++ model, he shows how to interop with Java... It's just a great talk.)
I was lucky enough to read this when I first got started with angular. Huge help shifting your mindset to angular and seeing the advantages it provides.
I'd also recommend http://egghead.io for some in depth walk throughs.
So far I've spent several weeks of my spare time forensically decomposing the documentation, nearly line by line. It's been very slow going.
The main thing I've learnt is that Angular is elaborate. Each time I get my head around something, I realise that my previous understanding was utterly wrong.
The docs are sufficiently vague that I spend a lot of time looking for secondary sources or just reading the code directly. Sometimes the code is self-documenting. And sometimes it's neutron-star dense.
But what I'm seeing, I really like. I think that directives are a big part of the magic -- building the HTML you wish existed and then writing your app in that domain-specific HTML.
They're meant to make particular kinds of complex application easier. I think Angular's problems is that docs are frankly dreadful. They tell people to fork it and improve it, but go look at their github pull requests. There are hundreds.
Maybe it's because of my background with Backbone.js but Angular really doesn't feel right. Any way I look at it, it feels like HTML and JS is being miished mashed together all over again and I thought we were past this way of doing things.
Neither way (Angular or Backbone) is "right" or "wrong"...just different ways to solve the same problems.
Angular reduces the amount of boilerplate code you need to build nice applications immensely, but to get to that point (and beyond two way binding hello world demos) there's a nearly vertical learning curve.
Once you near the top of that curve though, apps just kind of come together like magic. It's really neat.
IMO, it makes writing javascript-only applications (like all the internal tools for my company) much easier. It bugged me to look at a given view and not know what happened when something was clicked, or what the class name for an element needed to be to get the right behavior. Angular apps feel like writing a desktop app, which is great.
The cool thing about Angular is that it introduces a pretty unique way of building applications. What people don't seem to get is that it isn't mutually exclusive with jQuery. You can use Angular and still pull in the full jQuery library for your directives. What you'll find, however, is that you don't really need much more than the jqLite library that ships with Angular. The "Angular Way" alleviates the need for the more involved DOM functions in jQuery.
I'm curious if anyone could point me to a really simple application that shows how to use AngularJS and Firebase together?
I'm thinking it makes sense to do my next project in those technologies since that way I can avoid setting up a hosting platform entirely and not even pay for hosting? Does that seem like a good idea? (It's going to be a way people can pay bitcoins to other people to read books)
I actually do exactly this for a site I'm building. I use Firebase and Angular together and I host the site for next to nothing using Amazon's S3 static hosting option (costs me like $2 a month). I wrote a more robust angular firebase module than angular-fire, the one the Firebase guys wrote, and I also created a tiny framework/script-runner similar to Yeoman that automates a bunch of stuff including deploying to S3.
I'll message you when I make it all publicly available.
Would love to see your angular-firebase module (if you're willing to share it) - it would be great to integrate some of it back into the original module!
I've developed enough Rails apps to think architecture-first...but thinking back in my jQuery only days, the OP's question seems like it'd be a very common one among jQuery-only-front-end developers...and the top-answer is excellent: if you don't include jQuery, then you're forced to think about the architecture, and you'll be better off for it as a developer.