I've been learning and using AngularJS for the past couple of months and the journey has been a little bit of an emotional roller coaster.
In the end, I am extremely happy with our decision to go with AngularJS; and, I'm very grateful to Jamie Krug for not backing down with his suggestion. I can't wait for this project to be done so I have some more time to talk about all of the things that I've learned.
One thing that is great is that the Google Group for AngularJS is very active; and, the core team members actually respond to almost all of the messages posted. It's pretty amazing!
There's definitely a bit of a learning curve, especially if you come from a heavy jQuery background (like I do) - you have to start to think differently about how you interact with the DOM. But, it's very powerful.
Ben, since I'm still teetering on where to go with my JavaScript framework knowledge quest, do you think it's worthwhile to learn Backbone then AngularJS or just go to AngularJS and look at Backbone when Angular doesn't make sense?
To be fair, I don't really have much experience with Backbone, outside of what I've read. This project was the first that I've had any real framework on; and, when we were planning the architecture, we were deciding between BackboneJS and AngularJS. We ended up going with Angular and I'm pretty pleased with that.
That said, I can't tell you too much about Backbone - I can only tell you that AngularJS is pretty darn powerful.
Moving parts of an jQuery based application into AngularJS has been painful at times. For existing jQuery code that updates the Angular scope I found this bit of useful integration trigger code: http://www.telkoth.net/blog/?p=377
Thanks for the input Ben. We're (and me personally) struggling with "we need to do more front-end/JavaScript development but where do we start. Doing simple jQuery type things is ok, but we need to get into technology agnostic front-ends, i.e., I'm not building the app in CF or ASP.NET, etc., and the front-end is separate from the back-end.
@Claus I found that doing anything half-angular was a recipe for pain and frustration. The library calls in my code are now about 98% Angular and 2% JQuery. (The JQuery UI datepicker is just too useful. Incidentally, don't miss AngularUI: input type="text" ng-model="action.STARTDATE" ng-change="getMatchCount()" ui-date="{changeMonth: true, changeYear: true}" ui-date-format="yy-mm-dd" )
One mentality that I found really helpful was to make sure (as best I could) that Directives only dealt with user events (mouse clicks, moves, key events, etc); and, that everything that wasn't user-event related was handled in the Controller. It was a tricky - at times painful - mental transition... but I think it helped the separation a lot.
It was definitely cool. One of the problems we had, early-on, is that the way AngularJS manages the DOM is somewhat at odds with the way people are used to building CSS and "widgets". AngularJS does a lot of DOM *re-structuring* where as a lot of widgets do a lot DOM *hiding*.
This caused a number of problems with things like Twitter Bootstrap which has a lot of "content" DIVs with "active" classes on them to indicate show/hide. The problem was, we have AngularJS actually ripping those things out of the DOM with ngSwitch so the concept of "active" becomes irrelevant at the CSS level and only relevant at the DOM level.
Once we cleared that up, though, it was good times :)
Ben, this is really encouraging. AngularJS was high on my New Year's Resolutions, and seeing ColdFusion's poster boy endorse it sure adds some steam to the sauna. Most posts on Angular please!
Ha! That chart is perfect. It pretty much sums up my experience with all the things! Any framework or library, no matter how awesome people say it is, will always have pitfalls and drawbacks specific to each user.
The most important aspect of any open-source package, IMHO, is the community. A strong base of support provides the necessary resources to get past roadblocks and move forward. Angular has a great user community, and it's backed by Google, which never hurts.
Oh, and don't forget about http://plnkr.co/ it's like JSFiddle, but built with Angular, has live social programming, chat, and lots of great AngularJS forks already existing.
On the AngularJS site, there's a guide for "Directives". Directives are, without a doubt, the hardest aspect of AngularJS to wrap you head around. That's the part of the application that handles all the "traditional" jQuery stuff. I still find myself going back to the Directives tutorial.
That said, I started off with all white-page, stand-alone testing. Looking at little features and then slowly adding on and Googling when I hit roadblocks.
@Ben It's worth mentioning that the Directive's guide on AngularJS.org reads more easily backwards... if you read it forwards it starts off with low level compiling and everything and then at the very end it shows you a simple example!
Good point - really wrapping your head around Directives is critical. There's still aspects of it that I don't really understand - and, other aspects that I've not touched at all.
One good stepping stone, that I've found, was trying to replace the ngShow/ngHide directive with things like:
* ng-slide-show * ng-fade-show
... that use jQuery's slideDown() and fadeIn() methods instead of simply toggling display status. It's a nice directive to write because it gets you to think about watching model values and interacting with the DOM and worrying about "default" state.
an even more fun exercise is to make ng-slide-show and ng-fade-show without using jQuery at all. Bonus points for using CSS3 animations. AngularUI has a nice example of this.
Anytime you use jQuery within a directive, you are adding a jQuery dependency to your directive. Some people like Zepto or foregoing jQuery at all so I try to avoid writing using jQuery in directives unless I REALLY need to. I find that once I mastered directives I never use jQuery anymore... never really need to.
99% of the time
angular.element('.yo-dawg')
will do the same thing as
$('.yo-dawg')
using angular's built in jq implementation.
If you're in a link function (in a directive) you can do
It's funny you mention that; at the same time, we also started using Twitter Bootstrap (or rather, the front-end guy put it in place), including the LESS CSS framework. This is the first time I've ever used LESS; but, using the Bootstrap mixins has also made it easy to use transitions for the first time:
.transition( "left 1s ease" )
I've started to use that much more; though, I've not used it for the slide/fade show - would be an interested experiment.
Definitely, I'll try to use transitions a lot more since it's already backward-compatible with older browsers (becomes simply hide/show).
Doing a lot of Angular now. I thought it was funny that some people criticized Angular as being "ColdFusion-like" (because the views extend HTML sort of like CF does.) But honestly, it makes so much more sense to me to see the HTML <ul> with an "ng-repeat", than to see a bunch of jQuery code traversing the Dom to pull out the element and then building everything out of sight. I could look at an element in the HTML and have no clue what jQuery would do to it.
I also benefitted from not being a huge jQuery developer. I'm just as happy using Angular to manipulate things. But Directives have kept me up late at night more than once.
The AngularJS IRC room on freenode is always hopping. The Angular gang is pretty active on Google+, so I recommend following them there too, as well as joining the official G+ AngularJS community. And for the old school gang, there is the email list (which, if you've googled anything Angular, you've probably already seen.)
Last bit of advice: Get comfortable with JSfiddle and/or Plunker. It is the best way to communicate a problem to the community and get almost instant feedback on it.
Ben, I've been looking into Backbone as a solution. I wanted to know how AngularJS addresses SEO. In case of Backbone the data returned from a service is compiled against the client side template (using underscore, mustache etc,.) and then rendered into a container. This affects SEO. Does Angular help in someway or is better than using client side templating engines?
Having the inline syntax for templating is definitely awesome! It's nice to have your "static" HTML and your "dynamic" HTML all mixed together rather than distributed around your file system.
Good question. I can't speak much to SEO since I don't know much about how AJAX-style pages and spiders interact these days. With AngularJS, there is a lot of runtime compiling and DOM generation; so, if a search engine spider cannot handle that, I suppose AngularJS would be rather poor for SEO.
To be fair, I'm not sure I would use this for a site that is "content-heavy". For sites where SEO is a real concern, I'd still fallback to using a server-side rendering / page request model.
I really think the Angular team could revamp the documentation. I believe that would improve the learning curve. I stopped at the 3rd down in the new system our company is working on and gave up on Angular.
I know what you mean. In my first few "dips", I ranted to the team about how backwards some of the stuff was and why things were more difficult than it needed to be. In the end, however, I'm pretty pleased with our decision to muscle through.
Blog post suggestion. Looping through a cfquery with ng-repeat.
You inspired me to try to learn AngularJS but for the the obvious first thing to try was outputting a query and I'm already struck lol. No prob with jQuery but Angular and no i=1 has me stumped.
I sent you an email with a simple example that I tried but failed miserably.
Good question. First, some context - I've been returning data as array-of-structs JSON, which is much easier to loop over than the default JSON serialization that ColdFusion applies to queries (which I think is struct-of-arrays).
Once you are dealing with a query represented as an array, it becomes much easier. Furthermore, in an ng-repeat scope, you have access to the following utility values:
* $index * $first * $last
You can then do something like this:
<div ng-repeat="friend in friends">
{{ $index }}. {{ friend.name }}
<!-- Hide hrule for last item. -->
<hr ng-hide="$last" />
</div>
Ben, maybe you ran into something similar with Twitter, with handling event handlers triggered by things like setTimeout or XHR.
My understanding is that these fall outside of AngularJS. I imagine they provision for those with what, $apply? I think my conundrum would come in with third party APIs that provide their own callbacks, which may or may not alternate between synch/asynch (FB comes to mind). I'm curious - someone will or already has run into this, and I'd love to know how to wrap those, as this is nifty stuff.
One of my chief fuddy-duddy complaints about JavaScript has always been the lack of type safety or the loose object definition. I've been playing with TypeScript to satisfy those, and thus far have been pretty excited about the possible combination of that along with AngularJS, at least so it passes muster with a cabal of guys that still sneer at JavaScript for "grown up work."
The "No" vs. "false" thing is probably happening on the ColdFusion side, not the AngularJS side. When ColdFusion goes to serialize the data into JSON, it will convert "boolean" values (ie. Yes/No/True/False) to JavaScript-safe boolean values (ie. true/false).
When-to and when-NOT-to call $apply() is a fun journey in AngularJS directives. This can be affected by many things, including the capabilities of the browser.
For example, some events in jQuery plugins are triggered by CSS transition completion. In browsers that support CSS transitions, this event happens asynchronously; however, in browsers (like IE) that do not support CSS transitions, this event happens synchronously. In the former context, $apply() is needed; in the latter context, $apply() is NOT needed since you are already in the middle of a $digest.
Most of the time, you can figure out, consistently, when it makes sense. However, in cases like CSS transitions where you can't really know for sure if an event will happen asynchronously, you can always use AngularJS' $timeout() function. This is basically a setTimeout() wrapper that uses Angular's error handling and (by default) will invoke $apply() after the timer has completed:
$timeout( myEventCallback );
The $timeout() will make sure that the $apply() is called during the next non-digest tick.
If you are getting into the world of promises (as callback response values), that can get tricky since you don't know if a promise is resolved synchronously or asynchronously. In those cases, you may just need to resort to the $timeout() hack to be safe.
There are already a lot of comments, so not sure if you're going to read mine.
Do you think you didn't find AngularJS good at the beginning because of lack of documentation? Did you know knockoutjs before or did you just know jQuery? If you know knockoutjs, could you please put your opinions about them?
Hi Ben, I really love Angularjs too. I have been using it at work with the Taffy REST api and it has been awesome.
My favourite thing is that you can inject a little Angularjs in existing legacy code and go from there instead of rewriting everything. Not having to go the whole hog is great just a bit at a time.
Before doing this, the only real JavaScript libraries I had used were jQuery and RequireJS. This was the first "framework" type library that I have used in JavaScript. So, I can't really compare/contrast any other library.
That said, I think there were a few, specific hurdles that were difficult for me:
# Routing
Out of the box, AngularJS makes routing incredibly easy... if your layout is fairly basic - one level of navigation. In that case, the ngView directive integrates perfectly. However, if you have multiple levels of navigation, ngView is basically useless (from what I can tell). As such, I invested a significant amount of time figuring out to create arbitrary nesting of pages based on routes without unnecessary re-rending of modules that were unaffected by route changes.
This was something that took a good 2 weeks to figure out; I hope to break it out into its own demo as I think it may be really helpful to people... or maybe I am just missing something completely obvious :D
# Transitions
When coming from jQuery, it's quite easy / natural to transition things. Fade in, fade out, slide up, slide down, animate, etc.. In the AngularJS world, there is a complete separation between the DOM and the View Model ($scope object). As such, changes in the view model and transitions applied to the related DOM elements are controlled by two different aspects of the code.
I think this separation is really good as it ends up dividing responsibilities nicely; however, it's definitely a hard thing to wrap your head around, coming from a jQuery background.
# Minimizing $digest Calculations
Unfortunately, in AngularJS, it's rather easy to overload each $digest with many, intense calculations. This leads to noticeable page performance issues. In order to keep the $digest's light-weight, you have to be diligent about recalculating values based on events (such as $resource resolution). This way, as many of the $scope values are simple values and lead to fast, efficient $digests.
# Dealing With Cached Data
For performance reasons, our application tries to use client-side caching. For this I had to decorate the Deferred object so that our resources could return cached + live data:
Obviously, that is tightly bound to our app's requirements; but, dealing with cached data AND live data presented a number of issues.
# Controllers Binding To Non-Controller Events
We ended up needing to bind event listeners in our controllers to certain service objects. This created some problems because it can lead to accidental re-binding of event handlers when controllers are re-instantiated. As such, we had to figure out how to bind, then unbind event handlers in the controllers $destroy event so as not to create leaks.
# General Shift In Thinking
Overall, the largest (after routing) problem was just learning to think in a different way. Prior to this, I was mostly used to a standard page request/response model. Thinking in terms of pages and RESTful data is just a different approach which takes some getting used-to.
The graph is exactly how I felt Ben! Or still do feel.
I thought Angular was amazing, then realised it made life much harder, then realised I just had to adapt the way I was working (how I was using jQuery basically)... and now I've dropped a load of code and practices and replaced then with Angluar JS.
Still got loads to learn, I don't think Angluar JS is particularly easy to learn but I think it's worth it.
Also, I tried using it with jQuery Mobile thanks to this connector: https://github.com/tigbro/jquery-mobile-angular-adapter, which worked pretty well - although I've pretty much now dropped jQuery Mobile and I'm just using jQuery, Angular and CSS animations.
Yeah, definitely a learning curve! And a mind-shift. How are you finding AngularJS with mobile stuff? I've only used it for desktop stuff, to-date. In the Google Group, I see people, from time to time, talking about issues with mobile. I am surprised when I open up our app in my iPhone simulator and it actually works :D But, I do see that something fail to work (ex. sometimes clicks don't register properly or something)... but that may be more of a mark-up issue than an AngularJS issue.
The only issues I've found with mobile are that you basically need to replace the ng-click directive with ng-tap. Ng-tap is a custom directive but there's a few examples out there if you google. the ng-tap listens for touch events and has a workaround for the 300ms delay.
If you want animations between views (ng-view or ng-include) you need to either write get a little custom or use angular-mobile-view on github, but that still has some kinks to work out.
Ah, ng-tap sounds like it would speed things up. Transitions are another tricky thing. I've had to deal with some modal-to-modal transition stuff (ie. removing fade when jumping from one modal to another), and it definitely adds a layer of complexity.
I am not sure how I would even handle the view-to-view transitions. Yikes :)
Of course, every project and team varies, but I think the big plus for AngularJS is that it's looking to the future of browsers and JavaScript. I can't say I've thoroughly compared all frameworks, and I know they all have strengths and weaknesses, but AngularJS is pretty awesome and just feels like it's headed in the best direction.
Thanks a ton for posting that link. I was looking into Google Webmasters tools for Ajax crawling. A headless browser like PhantomJS does come very handy to handle crawler request. I was looking into HTMLUnit to generate a snapshot. Thanks again.
One of my big concerns is routing. In looking at converting a large business webapp (500+ round-trip pages currently) into an "Angularized" app, I'm confused about exactly how much routing and controller code I need to be putting into each page.
I'm not sure if it makes to convert a big app like this (which has multiple sections with different layouts, and a multi-level navigation structure) into a Single Page App, or maintain the round-trip and treat each page independently, at least for now. The latter seems like a more sane approach to me right now, because I can't quite figure out how/if I'm supposed to pre-load tons of JS app logic and routing into my SPA container.
I very quickly understood the core concepts of Angular and could see what it is doing to solve common problems. What I lack is a vision of how it solves the typical "big webapp" problems.
@Matt, I have the same questions when it comes to more complex applications and whether they should be single-page, a collection of single-page apps, etc. That's where I really struggle in all this move to front-end development.
We also wavered on that. At first, we were gonna go the "collection of single-page apps" approach; but, in the end, we ended up going with a single page that allows for different page layouts.
Figuring out the routing was definitely a big hoop to jump through. But, I think we came up with something that works pretty well. I'm actually working on a demo specifically for routing that I'll be able to share. Maybe by the end of the week!
Perhaps this is part of my real hesitation, because I've not yet figured out how to do some things in a SPA.
For example, if you go to a url you may get back one of 10 different screens depending on your user role, security, time of day, the state of some data, etc. I do not want to load all of those factors into a JS model and have a JS controller evaluate them to decide what view to show. That seems insane to me. I want to keep real hard-core business and application logic on the server side, where it belongs. Not susceptible to quirks in users' browsers that may make the wrong thing appear, nor do I want my business logic exposed to users in their source.
What seems reasonable to me is to create mini-SPA's for sections of a larger app. When you leave a logical section, you round-trip. For operations within the section, or navigation within the section, you stay ajaxy and Angularish. Then it becomes quite logical to deliver a single model and controller along with the painting of the section, and maintain it until you leave for somewhere else. At that point, a different model and controller are loaded when the round-trip returns.
Given the power and flexibility of real server-side controllers with config files, security rules, context, etc, I don't see any compelling reason to re-build all of that to run in the client. Especially when it seems like you can get a big benefit from Angular in "Mini-SPA" mode.
Is there a compelling reason to pass over the entire job of a big controller to Angular and force a SPA model?
Just to get the "obvious" out of the way, you always need to have security re-implemented on the server. No matter what kind of logic you have in the client, you can't depend on the client to enforce security. You still need to validate every command / query that gets sent to the server.
But, I'm sure you already know that - it sounds like you're more concerned with having to duplicate fine-grained view-logic on the client. And, to be fair, I don't have too much experience with an application that has that kind of logic; at least not with anything recently.
I built and app a few years ago that had 5 different "roles" of logins that all had completely different views of the systems. Much more so that simply turning on/off different views. When I was building that, each system has its own code base (over simplified). If I were to re-create that as an AngularJS app or SPA, I'd probably do the same thing - I'd have each "role" as its own "app". Something like:
@Ben, I was thinking of this when I had an ahah moment. Would it make sense to have these files living within your app server, so you would link to a .cfm or .php or something that would ensure the current session was authorized to grab it. Your initial page would almost determine does the session exist and if so, what's the role of the user. Thoughts?
The way we have our application set up is that the sub-views are all .htm pages. BUT, the root page - the main index page is a CFM page. And, we do this for a number of reasons. For starters, our application is running ColdFusion and FW/1 and it's easier to get a CFM page to integrate into the view-rendering that FW/1 does. But, secondly, and more importantly than that, we have the main page be a CFM page so that we can pre-authenticate the user *before* they actually render the page.
I've looked at examples where the login system was integrated into the AngularJS app; but, we wanted to forego the complexity that that involved. I'd rather be able to make the assumption that the user in the AngularJS app is already authenticated.
So, we assume the user it authenticated by the time they get to the AngularJS app; but, we also have an HTTP interceptor to make sure that none of the AJAX requests inside the AngularJS app returns a 401 Unauthorized. If it does, the HTTP interceptor bounces the user out of the AngularJS app.
Then, this "config" object can be injected into your AngularJS modules using the core dependency injection features of Angular. This can be a really nice benefit.
One of the biggest hurdles, for me, in AngularJS was figuring out how to most effectively render a page and how to react to route changes ONLY IF I needed to. Here's a further explanation of how I am now doing this:
@Ben, First things first.... Great Blog:) Thank you.
I'm a Visual Studio .NET developer and have just started playing around with AngularJS. I've also had a look at Breeze and this seems to play nicely with Angular, but.....
The company I work for is still using Windows XP and IE8. This is a problem because although Angular plays ok with IE8, Breeze does not:(
I really like the way I can use Breeze LinQ type queries against my .NET Web.Api. Unfortunatly this does not work with IE8.
Sorry for the slow reply, regarding mobile, I'm using it with Phonegap for an iOS app.
Everything I've built and run in Chrome is working well, it's a little slow on my iPhone but to be honest I think that's more to do with jQuery mobile. The more I work on it the more I drop jQM and the app itself seems to be much more responsive now.
I don't think I'm using AngularJS as well as I could be, I'm constantly finding out things as I go along and updating the way I work, but it's definitely changed the way I build apps and I like it.
The short answer - it seems to work well with Phonegap and runs alright on my phone. It's not a very complex app though.
Ben, it'd be great to hear about your experiences.
Especially how you handled (and your thoughts about) server-side data validation - while I feel it necessary, I haven't found any way which doesn't need me to code my validation logic twice; and redisplaying server-side-generated error messages in AngularJS apps is not neat...
That's interesting regarding the jQM performance. I've not done too much in the mobile world yet... and the bit that I have done definitely shows that lack of experience. Glad to know that AngularJS can be a feasible approach, at least for small apps maybe.
The app I'm working on right now doesn't have a whole lot of "input" type data collection. Mostly, we have a lot of interactions that don't really require too much client-side validation. As such, most of the validation we have to do on the server is more like, "Does user X have the right to do action Y. Is entity Z in the right state for action Y," ... and less like, "Is that a valid email address."
That said, we do have some forms and we keep the client-side validation very minimal - mostly checking lengths.
AngularJS does have some sort of validation framework built into its Form stuff using CSS; but, I have not really looked at it at all.
You can create custom validation, according to the docs. So, hopefully they've created it in such a way where you don't have to re-create your rules in two places so much as re-defining them???
I'm at about low point #2. I'm not really thrilled with it but it seems to be getting some good reviews so I'm taking some time to build apps with it so at least I know what I'm talking about. The thing that strikes me as completely contradictory to everything I've been taught especially with regard to the past 5 years, is that with angular, there seems to be a lack of separation of concerns. Nobody seems to be talking about it either. Take this example:
The difference, IMO, is that in the Angular approach, at least the save() method is part of a container of functionality which has clear boundaries and can be independently tested. It is calling specific functionality of a controller object, rather than a random global function with potentially unknown dependencies.
We're using Angular to build webapps. I don't think we should shy away from living in the HTML/web world. Trying to de-couple everything to the extreme leads to a system that is harder to understand and maintain.
It's the Matt Kruse! lol. You were who web designers turned to before jQuery came along... Years ago I used a lot of your stuff and I'm forever grateful for what I've learned from you.
With that out of the way, I would definitely prefer the angular way but it just feels dirty. For years I've trained myself to avoid inline event handling and now I just prefer it that way. I think it's cleaner and easier to debug, unit test, etc and it keeps my HTML clean. On the other hand, I really like the ability to create custom directives in angular, so it might actually be possible to wrap some of the event handling via a custom directive:
<button form-save>Save</button>
Which in theory if I'm able to do this, will give me the separation I prefer. But I'm still very new at this so it might not be the best way to go about it.
That's a really good question. Like you, I've been doing everything I can (I the past some-odd years) to get JavaScript out of the DOM and into my JavaScript modules. But, I think what Misko Hevery (AngularJS creator) and @Matt are saying is that it comes down to "context."
When we used to put onclick="" handlers in our DOM, there was no real context, other than the DOM node itself and the window, which had the click handler defined. So, basically there was one context for the entire document.
In AngularJS, the context for all of the "inline features" is the current $scope which binds the View to the Controller. But, rather than having a single context for the entire document (ala "window"), we have many $scope instances that define strict boundaries for granular parts of the DOM. Furthermore, since $scope instances inherit from each other using prototypal inheritance, you can actually define behaviors for a sub-section of the DOM.
In it, I have three separate scopes - three separate contexts - that all have the same method - setWindowTitle(). Yet each of them defines that behavior in a way that is specific to the part of the UI that uses it.
Angular includes a lite version of JQuery in the framework itself. If you include the full version JQuery in your page, Angular will use that instead of the lite version.
There are obviously a ton of extra features that jQuery brings to the table that come at a small cost of added filesize. In general we at RideAmigos include the full jQuery along side Angular.
We still include jquery, but honestly? It's more of a "woobie" now. Just feel safer having it around, even though most of our dom manipulation has moved into directives.
Honestly, I would probably include the jQuery library by default. At some point, you're gonna hit something that jQuery Lite can't do and it's gonna be confusing until you realize its a compatibility problem. If you're used to jQuery, as Sharon is saying, it's nice to know what the features are and not have to double-check your approach.
When going from a jQuery-driven approach to an AngularJS-driven approach, one of the first hurdles that I had to deal with that doing "transitions" IS harder in AngularJS. Things like slide-down and fade-in and the like. Especially when you are dealing with ngRepeat, it's so disorienting that you [may] sort of give up on some transitions that wouldn't normally have used.
That said, ALL that stuff CAN still be used in AngularJS once you get your head wrapped around the rendering and the timing. And, when you do, you're gonna want all the jazz that jQuery brings to the table.
Actually, i'm rather disappointed with the community, specifically their google group. i asked a rather practical question, a few days ago, and got zero replies.
I'm sorry that you've had a different experience than me. It seems that the AngularJS community is growing in size; it's possible that it has hit a tipping point where the main group simply doesn't have enough time to get to everyone's questions (the way they used to).
Hmm, I took a look at your SO post and nothing jumps out at me. Transclusion is still something I'm wrapping my head around a bit. I've played with it some, but I don't fully understand the intricacies of its lifecycle and binding considerations.
From the DOM perspective, I see you are using html( "" ) to clear the element before re-populating it with the various parts of the UI. It's possible that jQuery is actually unbind the event handlers when you do this.
What if, you try using .detach() to remove the pane1/pane2 references, and THEN do the clearing of the html:
scope.pane1 = pane1.detach(); scope.pane2 = pane2.detach(); element.empty() // same as html( "" )
I just tried something similar in a test page and can confirm that the .html("") call WILL unbind the event handlers of the nested elements. Take a look at this quick video I put together:
It's funny really just how well that image describes the way I would imagine most people that go with angular for some project is. I have had a similar roller-coaster ride with it as well, but not quite as extreme since I'm just using it for personal projects
I'm finding a this image hits home with a lot of people :) Hopefully we can all work through the rough patches together!
@Prateek,
AngularJS has error logging built-into it. But all it does it log to the console and make sure the error doesn't break things (as far as I know). You can override the error handling using the "$exceptionHandler". But, I don't know too much about it. The only thing that I do is basically look into the $exceptionHandler and using jQuey AJAX to post JavaScript errors to the server using normal AJAX methods.
I am coming from flex background and that's the reason I am getting confused with the way modules work in Flex and in Angular...can you help me in explaining how can i define multiple modules and each module should have it's own controller, services and directives etc
And my main index.html should not contain all the javascript files for all modules controllers and directives, i need a way in order to have them in separate module related files
@Jamie Krug: Thanks a lot buddy for the link... it will be great if you explain me the communication between two modules using the events with sample application... thanks in advance
One of the hardest parts of AngularJS is wrapping your head around Directives. At first, I found that my directives knew too much about the world - I had too much of my Controller "implementation" leaking into my Directives. What I've found over time is that the best way to create cleanly separated directives is to simply not build them at all! Or, rather, to delay building them for as long as possible:
One thing to realize about modules, though, in AngularJS is that they all live in the same dependency-injection namespace. So, while you can group your code in modules, all your services, directives, value objects, etc. have to be globally-uniquely named within the AngularJS application for the dependency injection to work.
The only thing that I've found it easy to "namespace" was the Controller since it's value is both defined and referenced as a string.
That said, I know nothing about Flex and how it was put together; so, I can really speak to any comparison / contract on that front.
I am trying "expect(element('.tab-content div span').text()).toMatch("hardcode");" for e2e testing using karma, it is fine but I want to match "element('.tab-content div span').text()" with contents in files like xml or text file, I don't want to hardcode this toMatch("hardcode"), is it possible?
Actually i am doing e2e test of angular js of my project but i am not getting one thing that is how to press enter key through the test when my form is filled as i am not using a button but a form. And form is submitted by pressing a enter key.
so what element should be used i tried with jquery
jQuery(ele).trigger({ type : 'keypress', which : 13 });
I had some issues with $digest running on high frequency timed update. I found it very hard or impossible to handle each update manually. No, $digest is a global thing, and I understand why.
But some unnecessary calculations were made, and I'm a performance maniac, so like lightweight and efforts over magic.
I posted a couple of questions on the google group but not really found an answer.
Anyway, you might to have a look at soma.js if you want a framework with injection but with vanilla javascript as actors, it makes everything very reusable.
I also loved the angular workflow with the DOM but sometimes not willing to load 80k of framework, especially on mobile. So I built a template engine, DOM manipulation as angular. It doesn't have a ful parser as angular js but still have a lot of features, it makes the operation very fast. Workflow is very similar as I got the inspiration directly from it.
So for the curious: http://somajs.github.io/somajs/ http://soundstep.github.io/soma-template/
I've also had some problems with the digest stuff, especially in terms of Directives that are being linked in the context of ngRepeat. Having the directive do something can (sometimes) cause a LOT of unnecessary paints / redraws which slows down the rendering very noticably. I've had to get pretty tricky at times, wrapping the body of a Directive in a timer, or grouping a bunch of link-handlers together in a single timer... all stuff to limit redraws and the work that goes into a single or set of $digests.
Definitely there's a learning curve just to thinking about the processing that has to take place... AND when to even care about that overhead.
I just went from "doomed" to "awesome" peak in 12 hours. Your drawing is perfect depiction of angularjs experience :D Imho anybody could sign under it.
Now, after a few month of a very intensive work with Angular, i can say the following:
1. Compared to other JS frameworks, this might be the best of its kind. Sencha (ExtJS) might be better, for those who prefer to build an application that is a bunch of ready-made web-components that just need to be heavily configured. Maybe EmberJS could be better if elegance is not important (i didn't try it).
2. ...Yet i think it has a long way to go, to make me feel JS UI frameworks are mature and beautiful and make me tingly :)
3. About the Dependency Injection mechanism and the module mechanism: until there's smart lazy-loading and smart-unloading, they are redundant and awkward; you could achieve better architecture with simple JS objects and scopes.
4. The data-binding is very nice and very useful.
5. The directive mechanism is also very nice yet it could be improved. i also miss some built-ins to easily access DOM elements from directive's template from the directive's code (and not as a result of an event).
6. JQLite is too light. The replacement of it with JQuery didn't work for me.
7. The digest/apply/eval mechanism etc. can (and i believe will) be improved.
8. Animation support - can be improved.
9. Memory leaks - on IE9 and older (yea, sadly i must be compatible to the piece of crap) - are problematic (ng-include can cause evil leaks, esp. under ng-repeat)
10. Directive inheritance/extension should be improved. It doesn't actually exist really; the way to achieve "overloading"-like ability, currently, is not elegant nor powerful enough (it's by definition a directive with the same name, and playing with the priority field...)
11. Tooling. Grunt/bower/yo support is still immature. i'm sure it will improve in the following year.
12. $location and routing can be improved (i think they did a lot already in 1.2)
I haven't gotten to play with the animation stuff; but, from what I've seen in the videos for 1.2, it looks promising. The one thing that I would think that it still misses is the "Don't animate on initial load... but animate everything else." I've tried to play around with that concept with directives and it's always a bit challenging, primarily with ngRepeat. With a directive that doesn't mess with DOM creation, things are a bit more straightforward.
More robust loading/unloading will also be interesting. I haven't looked into it at all yet - right now, in production, we just compile all our scripts and views together. It would be great to be able to do lazy-loading for the less-used parts of the application. I know there are some articles on RequireJS, but something more native would be awesome sauce.
And jQLite - I just went straight for jQuery. I didn't even bother trying to run things on jQLite - there was too much stuff missing right out of the box.
Overall, it's been really awesome - but, I think it has room and, as you say - will get better.
AngularJS feels just right, i never heard of it till few weeks ago, i was still coding using jQuery solo, i wanted a proper JS unit testing framework, my Google search lead me to experiment with Qunit for 2-3 days, but still i needed more, more search uncovered jstestdriver which integrates nicely with web storm but writing a realistic test for a complex feature took significant time & needless to say the project is no longer supported, till i finally came across AngularJS, i just love how it transforms web development completely, designed from the ground up to be testable with a BDD framework like jasmine, i think i have found the missing piece.
It sounds like you're really on the right track. Testing is something I need to get more into myself. I've started to really dabble in it on the server-side, but have barely scratched the surface on the client-side. So much to learn :( :)
Read your experience about angularjs. M a newbie to the technology, I am stuck at one place and it devours a lot of my time. I am using MVC 4.0 with .NET and Entity Framework.
I am trying to save data to multiple tables on a POST request to the server.
Its easy to save data to the table that is linked to the controller, but how do we save it to another table. I am using a collection because we are trying to pass multiple values for the same feild.
So basically I need to undersatnd the binding between "ICollection<Class_Name>" and angularjs.
Just wanted to write a quick thanks since I've been landing on your site a ton doing searches for different things in Angular and appreciate you taking the time to document your findings as you explore some new tech.
Totally agree on the chart too, Angular is a roller coaster, some things are impossibly easy and some things are seemingly just impossible (not literally, but you catch the drift).
I'm a bit surprised to see that you haven't been spammed here really, are you doing something alternative from the regular captcha to avoid bots?
Also how'd you make the chart (Illustrator, Inkscape, D3JS?)
Even if you don't have time to get back at me appreciate your taking the time to do make these posts.
I always refer to this blog post when I'm explaining AngularJS to people, and I wave my hand in the air to explain your "feelings about angularjs" graph.
I think I've just hit the "OMG That's Awesome!" stage. It's a good day for me and AngularJS, and more specifically directives.
What is really painful is when you get the "Angular is Awesome" stage, then get bumped into another project full of legacy js code with no framework whatsoever. Feels like once was rich but now is poor.
I've started from scratch with Angular, with very little knowledge of backbone, and I must say, I can't hardly understand how could anyone choose any other framework; I'm amazed. And honestly, taking away some little frustrating situation (because of my own limitation), not even once I thought the project was doomed. If it is useful, I'm also totally into Restangular now....great complement.
It will be dead soon. None of the large corporations dont even think in investing in something like angularjs, nor they have people able to learn and/or support anything like that.
@Bob, Plenty of "real world" apps use angular very successfully. Order a sub from JimmyJohn's, you're using Angular. Load up the YouTube app on PlayStation, you're using Angular. And JS is very suitable for development. Paypal recently switched their main account overview page from pure Java to NodeJS, there's a great blog post about it: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
@Richard Angular over backbone for a bit of a productivity boost when you need ease of binding. You can achieve something similar with Backbone + Marrionette. There are a lot of blog posts comparing Backbone to Angular. See this one: http://blog.nebithi.com/backbone-and-angular-demystifying-the-myths/
I don't see how this strange JS mutation can be better than any server-side generated HTML.
Performance? lol, based on my experience receive html generated on the server is not slower, but actually faster than loading and rendering all these JS libraries that depend on each other and then these JS libraries have to render HTML anyway on the client. Besides, you still need server-side code. bit and bytes of additional html tags is nothing these days and doesn't affect performance. However, loading huge JS libraries that don't work properly together and written by some strange people somewhere could be much more dangerous. Besides, in real world try to find a team of developers that know Angular JS, or even jQuery, or even JavaScript. lol Get real.
Not to my knowledge, I am currently looking for a job, 6 months already, in Canada. And I have over 17 years in architecture and development. I have not found a SINGLE job posting where AngularJS is mentioned, not one in 6 months! Actually I have NEVER seen any job postings asking for AngularJS, as well as I havent seen any job postings asking for any kind of JS framework other than jQuery. I assume that there are probably some companies on this planet that indeed try to use it ;) But not in the world I live in.
I was trying to learn it, but the effort is not worth the result. I understood one must dedicate weeks, maybe months, some - years to polish this framework. No companies, to my knowledge, are willing to go through this sacrifice today. Especially government and large corporations.
Client side interactions are important, as is having a site that works well on mobile. Having no JS in place means every interaction requires a round trip to the server try that on a 4G or worse 3G connection and you eat about .5s-1s just connecting to the tower not including transmitting the payload. It's much better to concat and minify your JS then use gzip to make the initial payload as small as possible but contains everything needed aside from extra data payloads you may load separately when needed. (CDN also helps reduce this issue)
Being a Google backed technology and allowing for clean testable front end code makes it ideal for large projects where a test suite is absolutely necessary. It also eliminates all the boilerplate code that teams tend to re-write for allowing some sort of binding and message/event buses, and handle routing, not to mention the ability to write directives which can abstract and greatly simplify the code that the end user developers will write.
It doesn't take that long to learn enough to get a huge benefit out of the framework. I recently posted a video showing how to setup an environment from scratch here: https://www.youtube.com/watch?v=zQNbsCTFrAA
If you aren't familiar with developing in JavaScript check out codeacademy.com, if you have questions about AngularJS itself, Ben's blog comes in handy a lot as well as egghead.io
Anyhow best of luck in your endeavors remember to keep an open mind, technology changes quickly.
5-7 jobs only - for entire country? is this a joke? and all in British Columbia? This is definitely NOT a market for angularjs.
Is it worth spending time learning it? not for me. I am not in a position to spend time learning stuff that has no demand. Maybe for personal amusement, but not for the purpose of finding a job.
Geez, you'd think some guys were being forced to learn this stuff at gunpoint. I didn't get a job because I knew AngularJS, but I KEPT my job because we used it to reduce our code base by 30%.
The guys on my team learned to use AngularJS well enough to start streamlining code in a week. How? We did this awesome thing called "reading a book".
If you are just learning something to get a job and nothing else, I'd say you're in the wrong career. Clock punchers don't make very good developers.
Is it worth spending time learning it? not for me. I am not in a position to spend time learning stuff that has no demand. Maybe for personal amusement, but not for the purpose of finding a job.
For personal amusement - it's ok, not for finding a job.
I am in a position where I interview programmers, and I'd like to inject something that may be helpful.
What is said: "There is no demand for it (that I know of). Why should I learn it?"
What I hear: "I am possibly unimaginative. My value may be limited to rote fulfillment of prescribed tasks."
And from the resume angle, I get dozens across my desk that read JavaScript/JQuery these days. Someone that puts down AngularJS or other emergent (more on AngularJS as emergent in a few) technology kills two birds with one stone: shows a higher degree of initiative than his peers, and importantly, demonstrates a broader skill set. Whether I use his skills or not, he's demonstrated his ability to learn something new.
This is Getting Hired 101 type stuff, however. I won't beat anyone further over the head with that.
As far as "no corporations are using this/there is no demand," I ask rhetorically, what corporation makes a habit of broadcasting specific coding practices that they use?
I would consider AngularJS extremely mature, particularly with regards to its dependency injection. If you work an environment where unit testing is an absolute must, bonus points to the dev team that embraces anything new to the table. SPA is here to stay, and AngularJS is absolutely establishing itself as reliable and well-supported.
I used angular to make web app for google itself. I didn't have other opportunities, fortunately or unfortunately.
Do you realize how much you have to learn in order to test angular components compared to test vanilla code or frameworks closer to vanilla javascript?
While I understand completely the angular attempts, I think it failed in many ways. Writing angular code or writing unit test for angular code for that matter is no way near writing vanilla javascript. It just feels different, almost like another language. It looks like 2 different things, look at the in-html filter syntax, wow. The truth is, you either write angular code or javascript code. Something is telling me that you shouldn't focus on something too proprietary.
See the comments, angular is compared to technologies such ASP or others, while it is only a javascript frameworks. And should only be considered as such.
IMHO, I think angular is nice for developers who have a limited knowledge of how to structure complex problems and how to solve common problems. Please no offense here, there's nothing you can't do without angular. While angular workflow is nice and attractive, there's not much efforts to make to reproduce its most important features, or what you need at least. Angular is for a niche development: single application that runs on desktop.
Angular is a no-go to low-powered device developments in my opinion, where you need every actions to perform amazingly well all the way through, following performance in each single step of the developement, and with small code.
Vanilla javascript or being as close as possible to it is the way for me.
Well-established? I found bugs in the latests version, that have been reported 10 months ago, either not solved or closed while developers are still having them. I think they are just overwhelmed. I can throw pull requests when I have time, I'm happy with that, I'm just overwhelmed too!
The really good thing about angular? it made me learn and think because they are clever people behind it. Now angular might be nice in some cases, in some projects, but really far from being the all-occasion-winner for single-page web app.
Again, it always comes back to the same thing: the right tool for the right job.
I agree with some of your points, not so much with others, but it all sort of misses my point.
Here it is, simpler: a) Dismissing the value of learning this or that framework on the merits of its relevance to job finding is fallacious. b) Dismissing the value of learning this or that framework on the merits of its relevance to corporate use is also fallacious.
You could honestly substitute any framework for the same argument I'm making.
I couldn't disagree with you more strongly on a couple of fundamental points.
1. You aver that AngularJS is a departure from vanilla JS. Perhaps in the scope of the template - it's not particularly intuitive, but it is well-documented, which mitigates the complexity of even what you cite, the in-html filtering. Otherwise, developing services, controllers, etc., looks like any other form of vanilla JS prototyping. It should feel damn familiar to any savvy JS developer, because it is.
2. Testing AngularJS work is no more or less exasperating than any other framework. Further, scads of folks, including myself, have taken the time to helpfully document, nay, hand-hold folks through unit and E2E testing using Node.JS, Jasmine, and Karma, or Protractor. If you can test vanilla JS, the skills are transferable to AngularJS. Period. To state otherwise is utter poppycock.
3. Bug fix turnaround is no indicator of establishment. Adobe has bugs reported early on in CF 10's release that still sit untouched, or have been declared moot. I keep tabs on AngularJS's issue tracker, and it enjoys the fluidity of any well-tended project.
I fundamentally agree with you, there is nothing that cannot be accomplished without vanilla JS, but that's never the point of a framework like this. I would argue that it's one of the best offerings for people with a real focus on testing driven development, that it's mature, that it's relatively stable, and it's worth even a casual skimming of the surface.
Do you know Prolog? Do you anyone who knows Prolog? I know Prolog, and I know Lisp,and ... lol Cobol.
The reason I am asking is related to your comment:
"And from the resume angle, I get dozens across my desk that read JavaScript/JQuery these days. Someone that puts down AngularJS or other emergent (more on AngularJS as emergent in a few) technology kills two birds with one stone: shows a higher degree of initiative than his peers, and importantly, demonstrates a broader skill set."
LOL, I can put whatever I want in my resume, assembler, lisp, prolog, cobol, name it... Doesnt mean shit... pardon my cobol.
99% of people LIE in their resumes to some extend. The same way employers LIE about their promises to use these technologies. The whole world is built on LIES these days.
Or they have learned the word $scope, and they put in the resume "AngularJS" :))
Having said that, why not give a preference to all those people who have Prolog in their resume?
But wait... who the hell needs Prolog in real world? Who needs AngularJs (in real world) and not in imaginary universe created by some bloggers copying stuff from one another?
You know how many blog posts I have read? Hundreds.. I guess. and 90% of them is a clear copy-paste from other blog posts (no thinking applied).
"a) Dismissing the value of learning this or that framework on the merits of its relevance to job finding is fallacious. b) Dismissing the value of learning this or that framework on the merits of its relevance to corporate use is also fallacious."
huge mistake imho. Why not learn Cobol, or Lisp, or Prolog, or Algol? Why not? That would be ... fallacious.
Do you mind I rephrase you with these light changes:
a) Dismissing the value of learning this or that framework (Cobol, Lisp, Prolog or Algol) on the merits of its relevance to job finding is fallacious. b) Dismissing the value of learning this or that framework (Cobol, Lisp, Prolog or Algol) on the merits of its relevance to corporate use is also fallacious.
Ok angular is good , Ember is Nice , Knockout is cute , backbone is wonderfull , SPA application are the future My opinion all of these are juste like flash or Silverlight or javaApplets ; ephemere
No one told about resources , memory management ? real world app are obese app not just phone app or todo app !! Example Angularjs : memory leaks are straights $http release resources so late ng-repeat creates more scopes then DOM elements scope are gnarled and heavy weight scope and its properties name are so longue making IE strive .
when i'll build my app with that angular all users must have 32GB RAM and 4GHZ CPU ?
:). Ofcourse, I worked on a medium scale application. It is completely an angular app. There is no doubt angular is amazing but, we ran into huge memory losses where, after using app for some time it started crashing. we used bindonce for ng-repeat, removed jquery dependency completely and implemented drag and drop, sortable like things in angular js. And sorry if I am wrong. I am still a learner. After struggling a lot with those memory issues, I thought that way.
And also, I am planning to write a cross platform application any body interested to join me?
It is a web application. It will have user hierarchy. Users can create content. They can create playlists with images, videos, html content. They can set the start date and end date. Those playlists can be assigned to the devices. Those playlist will be played on the digital signage boards. Locally user can also preview( SMIL Player ). It also has many other functions. I think, I shouldn't discuss much or my company will sue me ;).
This talk from Google's DoubleClick team, at ng-conf, may provide some ideas for you: "Writing a Massive Angular App at Google" - http://youtu.be/62RvRQuMVyg
There's a good chance much larger apps than yours have been built with AngularJS, but you may have reached some use cases that require a more complex solution to meet the scale (as may be the case regardless of JS libraries/frameworks employed in your app).
"Everything Should Be Made as Simple as Possible, But Not Simpler"
The feeling with Angular is that things are NOT as simple as possible but a lot more complicated that how they should be. Complexity diminishes understanding and make the developer more prone to put bugs in the code.
The simplicity of the first example at http://angularjs.org/ is quickly lost in any real world situation. Even the "Create Components" has more code than you would write in pure Javascript with some jQuery.
Most of the jQuery Plugins out there cannot be used anymore out of the box in AngularJs. You need to wrap them in directives and sometimes it is not even possible.
Sometimes the errors are cryptical and sometimes you do not have any error at all but things do not work as expected. You need to go under the hood and look at how the magic is working and unless you are a wizard in AngularJS internals, it is going to slow you down.
Using AngularJS require to go through a considerable steep learning curve. If you have a team that does not know Angular they need all to learn it. If you need to hire new developer they all need to go through the same learning curve and if you want to hire somebody proficient with Angular, you have a a lot smaller pool.
You should use a new technology if its pros offset the cons. My opinion is that this is not the case in Angular.JS.
Like you I'm a jQuery guy, but even beyond that I love using plain old JS when I can.
Using custom tags and attributes doesnt sit well with me, and beyond two way data binding I don't see how Angular is doing a better job at Javascripting than jQuery. You could for all intents and purposes structure your jQuery in a way to mimic some of the patterns in Angular without it being too black magicky, afterall this is all just Javascript. You can do the same thing a dozen ways in JS, and you can do it without breaking the intent of HTML spec, even for a web app.
You could write a general plugin to handle two way databinding and statefulness and use it as a base plugin for any interactive components, that way you don't even have to think about it beyond sending data to a function endpoint. One day I hope to write a tiny jQuery framework for this that has a bit of an opinionated structure, is super lightweight, follows standards, and makes sense to everyone.
<rant> I hate hate hate how Angular developers need to Javascript all of the things, even things that plain ol HTML/CSS can handle on its own. You dont need a dang directive for every element!
Angular encourages anti patterns and seems to only be a hit with people who never 'got' front end development, or any of the good principles that have been created over time. Web apps doesnt blow HTML standards out of the water. Sorry about it.
</rant>
Anyway, curious about your thoughts, since your blog is always a goto for me for Javascripty stuff.
I agree wholeheartedly. I really despise some of the poor practice that Angular is encouraging and you're right on target in that JS should be super simple!
I like the 'Our project is doomed' part:))) I was really enjoyed the process when it came to some very hacky project, previously written (horribly by me:) ) using Backbone, it took about three complete days to made all things done with angular.
The only thing I find confusing a little bit is animation. Of course because of IE. What if I need a carousel on my site? Then I need fallbacks cause of this and that... TweenLite/JQuery as dependencies? Ben, what do you think?
Hi Ben, Thanks for sharing this, it made my day and gives me hope, because I see that I am not the only one with this exact feeling!
By the way, I came here because I feel frustrated about the ng-if creating its own scope. If you put a set of buttons inside a ng-if, it's really easy to end up with something that doesn't work and doesn't cause any exception!
The quality of software tools is not only measured by the success of software products created with them. I would like to see a graph of the cumulative damage done to your body by fluctuating cortisol levels over the same time period.
AngularJS gets things done and people dead (a couple of years sooner, at the very least).
I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Reader Comments
We're about to be heading down the same journey. Now I'm really looking forward to it but also really NOT looking forward to it!
@Joe,
One thing that is great is that the Google Group for AngularJS is very active; and, the core team members actually respond to almost all of the messages posted. It's pretty amazing!
There's definitely a bit of a learning curve, especially if you come from a heavy jQuery background (like I do) - you have to start to think differently about how you interact with the DOM. But, it's very powerful.
@Ben,
Good to know about the Google Group. I'm actually starting the new project with it later today so I'll definitely be looking for answers.
Ben, since I'm still teetering on where to go with my JavaScript framework knowledge quest, do you think it's worthwhile to learn Backbone then AngularJS or just go to AngularJS and look at Backbone when Angular doesn't make sense?
@Phil,
To be fair, I don't really have much experience with Backbone, outside of what I've read. This project was the first that I've had any real framework on; and, when we were planning the architecture, we were deciding between BackboneJS and AngularJS. We ended up going with Angular and I'm pretty pleased with that.
That said, I can't tell you too much about Backbone - I can only tell you that AngularJS is pretty darn powerful.
@Ben,
Love the drawing - exactly my sentiments.
Moving parts of an jQuery based application into AngularJS has been painful at times. For existing jQuery code that updates the Angular scope I found this bit of useful integration trigger code: http://www.telkoth.net/blog/?p=377
Thanks for the input Ben. We're (and me personally) struggling with "we need to do more front-end/JavaScript development but where do we start. Doing simple jQuery type things is ok, but we need to get into technology agnostic front-ends, i.e., I'm not building the app in CF or ASP.NET, etc., and the front-end is separate from the back-end.
@Claus I found that doing anything half-angular was a recipe for pain and frustration. The library calls in my code are now about 98% Angular and 2% JQuery. (The JQuery UI datepicker is just too useful. Incidentally, don't miss AngularUI: input type="text" ng-model="action.STARTDATE" ng-change="getMatchCount()" ui-date="{changeMonth: true, changeYear: true}" ui-date-format="yy-mm-dd" )
AngularJS is exceptionally wonderful. It's the only framework where I feel like my efforts are an investment in our future codebase.
My money is on more Angular-like frameworks once the web components part of the HTML spec is implemented.
PS: Pardon the plug, but I'm hiring freelancers/contractors for some projects using Angular... bit.ly/XLolWn
@Claus, @Daryl,
One mentality that I found really helpful was to make sure (as best I could) that Directives only dealt with user events (mouse clicks, moves, key events, etc); and, that everything that wasn't user-event related was handled in the Controller. It was a tricky - at times painful - mental transition... but I think it helped the separation a lot.
@Ben D,
It was definitely cool. One of the problems we had, early-on, is that the way AngularJS manages the DOM is somewhat at odds with the way people are used to building CSS and "widgets". AngularJS does a lot of DOM *re-structuring* where as a lot of widgets do a lot DOM *hiding*.
This caused a number of problems with things like Twitter Bootstrap which has a lot of "content" DIVs with "active" classes on them to indicate show/hide. The problem was, we have AngularJS actually ripping those things out of the DOM with ngSwitch so the concept of "active" becomes irrelevant at the CSS level and only relevant at the DOM level.
Once we cleared that up, though, it was good times :)
Ben, this is really encouraging. AngularJS was high on my New Year's Resolutions, and seeing ColdFusion's poster boy endorse it sure adds some steam to the sauna. Most posts on Angular please!
@David,
"adds some steam to the sauna"
... ha ha, I've never heard that before :)
I'll definitely be doing more AngularJS posting starting in the next few weeks.
Ha! That chart is perfect. It pretty much sums up my experience with all the things! Any framework or library, no matter how awesome people say it is, will always have pitfalls and drawbacks specific to each user.
The most important aspect of any open-source package, IMHO, is the community. A strong base of support provides the necessary resources to get past roadblocks and move forward. Angular has a great user community, and it's backed by Google, which never hurts.
I just started to mess around with it. It's nice. Real nice.
Any particular tutorials one should start with that will help get a noob up to speed or comfortable?
We're pretty active on IRC as well! On freenode in angularjs.
The one thing I'll say about learning AngularJS... don't resist the Directives. You must learn to write directives, when to write directives, and why.
The jist of it is, pretty much anytime you want to manipulate or interact with the DOM, you must make a directive.
My best advice is to get rid of jQuery for awhile.. not forever, but just until you've got the hang of Angular.
What's nice is what you end up with simple re-usable tags, attributes, etc. to do all your heavy lifting!
Oh, and don't forget about http://plnkr.co/ it's like JSFiddle, but built with Angular, has live social programming, chat, and lots of great AngularJS forks already existing.
@Eric,
Agreed - AngularJS seems to have an awesome community!
@Phil,
On the AngularJS site, there's a guide for "Directives". Directives are, without a doubt, the hardest aspect of AngularJS to wrap you head around. That's the part of the application that handles all the "traditional" jQuery stuff. I still find myself going back to the Directives tutorial.
That said, I started off with all white-page, stand-alone testing. Looking at little features and then slowly adding on and Googling when I hit roadblocks.
There are some good YouTube videos as well from John Lindquist - http://johnlindquist.com.
@Ben
It's worth mentioning that the Directive's guide on AngularJS.org reads more easily backwards... if you read it forwards it starts off with low level compiling and everything and then at the very end it shows you a simple example!
@Jonathan,
Good point - really wrapping your head around Directives is critical. There's still aspects of it that I don't really understand - and, other aspects that I've not touched at all.
One good stepping stone, that I've found, was trying to replace the ngShow/ngHide directive with things like:
* ng-slide-show
* ng-fade-show
... that use jQuery's slideDown() and fadeIn() methods instead of simply toggling display status. It's a nice directive to write because it gets you to think about watching model values and interacting with the DOM and worrying about "default" state.
@Jonathan,
I'm not sure there's an "easy" way to read it :D I've read it like 12 times and I still keep going back to it as a reference :D
@Ben
an even more fun exercise is to make ng-slide-show and ng-fade-show without using jQuery at all. Bonus points for using CSS3 animations. AngularUI has a nice example of this.
Anytime you use jQuery within a directive, you are adding a jQuery dependency to your directive. Some people like Zepto or foregoing jQuery at all so I try to avoid writing using jQuery in directives unless I REALLY need to. I find that once I mastered directives I never use jQuery anymore... never really need to.
99% of the time
will do the same thing as
using angular's built in jq implementation.
If you're in a link function (in a directive) you can do
just like you are used to. or
to get your directive's sub elements. Good stuff.
@Jonathan,
It's funny you mention that; at the same time, we also started using Twitter Bootstrap (or rather, the front-end guy put it in place), including the LESS CSS framework. This is the first time I've ever used LESS; but, using the Bootstrap mixins has also made it easy to use transitions for the first time:
I've started to use that much more; though, I've not used it for the slide/fade show - would be an interested experiment.
Definitely, I'll try to use transitions a lot more since it's already backward-compatible with older browsers (becomes simply hide/show).
Doing a lot of Angular now. I thought it was funny that some people criticized Angular as being "ColdFusion-like" (because the views extend HTML sort of like CF does.) But honestly, it makes so much more sense to me to see the HTML <ul> with an "ng-repeat", than to see a bunch of jQuery code traversing the Dom to pull out the element and then building everything out of sight. I could look at an element in the HTML and have no clue what jQuery would do to it.
I also benefitted from not being a huge jQuery developer. I'm just as happy using Angular to manipulate things. But Directives have kept me up late at night more than once.
And for those who are interested, here are some tutorials I've run across:
http://learni.st/users/tilley.brandon/boards/9236-angularjs
http://egghead.io/
http://www.youtube.com/user/angularjs
http://www.youtube.com/watch?v=WuiHuZq_cg4
http://coenraets.org/blog/2012/02/sample-application-with-angular-js/?
The AngularJS IRC room on freenode is always hopping. The Angular gang is pretty active on Google+, so I recommend following them there too, as well as joining the official G+ AngularJS community. And for the old school gang, there is the email list (which, if you've googled anything Angular, you've probably already seen.)
Last bit of advice: Get comfortable with JSfiddle and/or Plunker. It is the best way to communicate a problem to the community and get almost instant feedback on it.
Ben, I've been looking into Backbone as a solution. I wanted to know how AngularJS addresses SEO. In case of Backbone the data returned from a service is compiled against the client side template (using underscore, mustache etc,.) and then rendered into a container. This affects SEO. Does Angular help in someway or is better than using client side templating engines?
@Sharon,
Having the inline syntax for templating is definitely awesome! It's nice to have your "static" HTML and your "dynamic" HTML all mixed together rather than distributed around your file system.
@Sagar,
Good question. I can't speak much to SEO since I don't know much about how AJAX-style pages and spiders interact these days. With AngularJS, there is a lot of runtime compiling and DOM generation; so, if a search engine spider cannot handle that, I suppose AngularJS would be rather poor for SEO.
To be fair, I'm not sure I would use this for a site that is "content-heavy". For sites where SEO is a real concern, I'd still fallback to using a server-side rendering / page request model.
I really think the Angular team could revamp the documentation. I believe that would improve the learning curve. I stopped at the 3rd down in the new system our company is working on and gave up on Angular.
@Mark,
I know what you mean. In my first few "dips", I ranted to the team about how backwards some of the stuff was and why things were more difficult than it needed to be. In the end, however, I'm pretty pleased with our decision to muscle through.
Blog post suggestion. Looping through a cfquery with ng-repeat.
You inspired me to try to learn AngularJS but for the the obvious first thing to try was outputting a query and I'm already struck lol. No prob with jQuery but Angular and no i=1 has me stumped.
I sent you an email with a simple example that I tried but failed miserably.
Thanks for a GREAT blog!
@Lance,
Good question. First, some context - I've been returning data as array-of-structs JSON, which is much easier to loop over than the default JSON serialization that ColdFusion applies to queries (which I think is struct-of-arrays).
Once you are dealing with a query represented as an array, it becomes much easier. Furthermore, in an ng-repeat scope, you have access to the following utility values:
* $index
* $first
* $last
You can then do something like this:
Hope that helps a bit!
@Ben
HOLY CRAP!! You're Brilliant
Borrowed a little code from www.bennadel.com/blog/124-Ask-Ben-Converting-a-Query-to-an-Array.htm and away we go.
<code>
<cfscript>
a = createObject('component','angular');
getIndex = a.getIndex();
indexArray = a.queryToArray(getIndex);
</cfscript>
<script type="text/javascript">
var theQuery = <cfoutput>#serializeJSON(indexArray)#</cfoutput>;
console.log(theQuery);
function dataLooper($scope){
$scope.people = theQuery;
}
</script>
<div ng-controller="dataLooper">
<div ng-repeat="person in people">
{{person.FIRSTNAME}} - {{person.LASTNAME}} - {{person.AGE}}<br>
</div>
</div>
<code>
Works beautifully. Interesting note, One person in my list has the last name of "No" and Agular decided to display it as "false"
Thanks Ben
Ben, maybe you ran into something similar with Twitter, with handling event handlers triggered by things like setTimeout or XHR.
My understanding is that these fall outside of AngularJS. I imagine they provision for those with what, $apply? I think my conundrum would come in with third party APIs that provide their own callbacks, which may or may not alternate between synch/asynch (FB comes to mind). I'm curious - someone will or already has run into this, and I'd love to know how to wrap those, as this is nifty stuff.
One of my chief fuddy-duddy complaints about JavaScript has always been the lack of type safety or the loose object definition. I've been playing with TypeScript to satisfy those, and thus far have been pretty excited about the possible combination of that along with AngularJS, at least so it passes muster with a cabal of guys that still sneer at JavaScript for "grown up work."
@Lance,
The "No" vs. "false" thing is probably happening on the ColdFusion side, not the AngularJS side. When ColdFusion goes to serialize the data into JSON, it will convert "boolean" values (ie. Yes/No/True/False) to JavaScript-safe boolean values (ie. true/false).
@Brian,
When-to and when-NOT-to call $apply() is a fun journey in AngularJS directives. This can be affected by many things, including the capabilities of the browser.
For example, some events in jQuery plugins are triggered by CSS transition completion. In browsers that support CSS transitions, this event happens asynchronously; however, in browsers (like IE) that do not support CSS transitions, this event happens synchronously. In the former context, $apply() is needed; in the latter context, $apply() is NOT needed since you are already in the middle of a $digest.
Most of the time, you can figure out, consistently, when it makes sense. However, in cases like CSS transitions where you can't really know for sure if an event will happen asynchronously, you can always use AngularJS' $timeout() function. This is basically a setTimeout() wrapper that uses Angular's error handling and (by default) will invoke $apply() after the timer has completed:
The $timeout() will make sure that the $apply() is called during the next non-digest tick.
If you are getting into the world of promises (as callback response values), that can get tricky since you don't know if a promise is resolved synchronously or asynchronously. In those cases, you may just need to resort to the $timeout() hack to be safe.
@All,
FYI, here's a simple AngularJS directive example if anyone is curious:
www.bennadel.com/blog/2440-Creating-A-Custom-Show-Hide-Directive-In-AngularJS.htm
I look at creating a custom directive for show/hide using jQuery's slideDown() and slideUp() methods, respectively.
@Ben,
Thanks! This is awesome stuff. Must. Find. Excuse. To use it. Now.
There are already a lot of comments, so not sure if you're going to read mine.
Do you think you didn't find AngularJS good at the beginning because of lack of documentation? Did you know knockoutjs before or did you just know jQuery? If you know knockoutjs, could you please put your opinions about them?
Hi Ben, I really love Angularjs too. I have been using it at work with the Taffy REST api and it has been awesome.
My favourite thing is that you can inject a little Angularjs in existing legacy code and go from there instead of rewriting everything. Not having to go the whole hog is great just a bit at a time.
And the testability is breathtaking.
Cheers
Kevla
@Thai,
Before doing this, the only real JavaScript libraries I had used were jQuery and RequireJS. This was the first "framework" type library that I have used in JavaScript. So, I can't really compare/contrast any other library.
That said, I think there were a few, specific hurdles that were difficult for me:
# Routing
Out of the box, AngularJS makes routing incredibly easy... if your layout is fairly basic - one level of navigation. In that case, the ngView directive integrates perfectly. However, if you have multiple levels of navigation, ngView is basically useless (from what I can tell). As such, I invested a significant amount of time figuring out to create arbitrary nesting of pages based on routes without unnecessary re-rending of modules that were unaffected by route changes.
This was something that took a good 2 weeks to figure out; I hope to break it out into its own demo as I think it may be really helpful to people... or maybe I am just missing something completely obvious :D
# Transitions
When coming from jQuery, it's quite easy / natural to transition things. Fade in, fade out, slide up, slide down, animate, etc.. In the AngularJS world, there is a complete separation between the DOM and the View Model ($scope object). As such, changes in the view model and transitions applied to the related DOM elements are controlled by two different aspects of the code.
I think this separation is really good as it ends up dividing responsibilities nicely; however, it's definitely a hard thing to wrap your head around, coming from a jQuery background.
# Minimizing $digest Calculations
Unfortunately, in AngularJS, it's rather easy to overload each $digest with many, intense calculations. This leads to noticeable page performance issues. In order to keep the $digest's light-weight, you have to be diligent about recalculating values based on events (such as $resource resolution). This way, as many of the $scope values are simple values and lead to fast, efficient $digests.
# Dealing With Cached Data
For performance reasons, our application tries to use client-side caching. For this I had to decorate the Deferred object so that our resources could return cached + live data:
www.bennadel.com/blog/2431-Resolving-An-AngularJS-Deferred-Object-Twice-With-DeferredWithUpdate-js.htm
Obviously, that is tightly bound to our app's requirements; but, dealing with cached data AND live data presented a number of issues.
# Controllers Binding To Non-Controller Events
We ended up needing to bind event listeners in our controllers to certain service objects. This created some problems because it can lead to accidental re-binding of event handlers when controllers are re-instantiated. As such, we had to figure out how to bind, then unbind event handlers in the controllers $destroy event so as not to create leaks.
# General Shift In Thinking
Overall, the largest (after routing) problem was just learning to think in a different way. Prior to this, I was mostly used to a standard page request/response model. Thinking in terms of pages and RESTful data is just a different approach which takes some getting used-to.
@Kevla,
Sadly enough, I haven't looked into the testing too much yet :( Deadlines... life... etc. :( I hear it's awesome, though!
Thanks for the article. I have a bigger JS project upcoming and I'll definitely give AngularJS a try.
Great explanation Ben!
The graph is exactly how I felt Ben! Or still do feel.
I thought Angular was amazing, then realised it made life much harder, then realised I just had to adapt the way I was working (how I was using jQuery basically)... and now I've dropped a load of code and practices and replaced then with Angluar JS.
Still got loads to learn, I don't think Angluar JS is particularly easy to learn but I think it's worth it.
Also, I tried using it with jQuery Mobile thanks to this connector: https://github.com/tigbro/jquery-mobile-angular-adapter, which worked pretty well - although I've pretty much now dropped jQuery Mobile and I'm just using jQuery, Angular and CSS animations.
@Yves,
Awesome! Good luck. I hope to be blogging a good bit about AngularJS, so hopefully I'll be here to bounce ideas off-of if you need it!
@Kodai,
Thank you kind sir!
@Pete,
Yeah, definitely a learning curve! And a mind-shift. How are you finding AngularJS with mobile stuff? I've only used it for desktop stuff, to-date. In the Google Group, I see people, from time to time, talking about issues with mobile. I am surprised when I open up our app in my iPhone simulator and it actually works :D But, I do see that something fail to work (ex. sometimes clicks don't register properly or something)... but that may be more of a mark-up issue than an AngularJS issue.
@Ben
The only issues I've found with mobile are that you basically need to replace the ng-click directive with ng-tap. Ng-tap is a custom directive but there's a few examples out there if you google. the ng-tap listens for touch events and has a workaround for the 300ms delay.
If you want animations between views (ng-view or ng-include) you need to either write get a little custom or use angular-mobile-view on github, but that still has some kinks to work out.
@Jonathan,
Ah, ng-tap sounds like it would speed things up. Transitions are another tricky thing. I've had to deal with some modal-to-modal transition stuff (ie. removing fade when jumping from one modal to another), and it definitely adds a layer of complexity.
I am not sure how I would even handle the view-to-view transitions. Yikes :)
@Sagar, some folks have tackled SEO issues with AngularJS:
http://www.yearofmoo.com/2012/11/angularjs-and-seo.html
https://github.com/yearofmoo/AngularJS-SEO-Article
For folks looking to compare AngularJS with Backbone and other JS MV* frameworks, a few good comparisons and such popped up just recently:
http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-the-better-choice/answer/Patrick-Aljord
http://www.nebithi.com/2012/12/27/backbone-and-angular-demystifying-the-myths/
https://gist.github.com/4454814
Of course, every project and team varies, but I think the big plus for AngularJS is that it's looking to the future of browsers and JavaScript. I can't say I've thoroughly compared all frameworks, and I know they all have strengths and weaknesses, but AngularJS is pretty awesome and just feels like it's headed in the best direction.
@Jamie,
Thanks a ton for posting that link. I was looking into Google Webmasters tools for Ajax crawling. A headless browser like PhantomJS does come very handy to handle crawler request. I was looking into HTMLUnit to generate a snapshot. Thanks again.
@Sagar,
No problem. Good luck!
The comments here are very useful!
One of my big concerns is routing. In looking at converting a large business webapp (500+ round-trip pages currently) into an "Angularized" app, I'm confused about exactly how much routing and controller code I need to be putting into each page.
I'm not sure if it makes to convert a big app like this (which has multiple sections with different layouts, and a multi-level navigation structure) into a Single Page App, or maintain the round-trip and treat each page independently, at least for now. The latter seems like a more sane approach to me right now, because I can't quite figure out how/if I'm supposed to pre-load tons of JS app logic and routing into my SPA container.
I very quickly understood the core concepts of Angular and could see what it is doing to solve common problems. What I lack is a vision of how it solves the typical "big webapp" problems.
@Matt, I have the same questions when it comes to more complex applications and whether they should be single-page, a collection of single-page apps, etc. That's where I really struggle in all this move to front-end development.
@Matt, @Phil,
We also wavered on that. At first, we were gonna go the "collection of single-page apps" approach; but, in the end, we ended up going with a single page that allows for different page layouts.
Figuring out the routing was definitely a big hoop to jump through. But, I think we came up with something that works pretty well. I'm actually working on a demo specifically for routing that I'll be able to share. Maybe by the end of the week!
@Ben,
[I posted this in the Angular Google Group, but since it applies directly to this context too, I copied here. Original: https://groups.google.com/d/msg/angular/ivmwOI0X7t8/isNLKMEUBv8J ]
Perhaps this is part of my real hesitation, because I've not yet figured out how to do some things in a SPA.
For example, if you go to a url you may get back one of 10 different screens depending on your user role, security, time of day, the state of some data, etc.
I do not want to load all of those factors into a JS model and have a JS controller evaluate them to decide what view to show. That seems insane to me.
I want to keep real hard-core business and application logic on the server side, where it belongs. Not susceptible to quirks in users' browsers that may make the wrong thing appear, nor do I want my business logic exposed to users in their source.
What seems reasonable to me is to create mini-SPA's for sections of a larger app. When you leave a logical section, you round-trip. For operations within the section, or navigation within the section, you stay ajaxy and Angularish. Then it becomes quite logical to deliver a single model and controller along with the painting of the section, and maintain it until you leave for somewhere else. At that point, a different model and controller are loaded when the round-trip returns.
Given the power and flexibility of real server-side controllers with config files, security rules, context, etc, I don't see any compelling reason to re-build all of that to run in the client. Especially when it seems like you can get a big benefit from Angular in "Mini-SPA" mode.
Is there a compelling reason to pass over the entire job of a big controller to Angular and force a SPA model?
How proficient one needs to be in JavaScript, before one ventures in AngularJS?
@Matt,
Just to get the "obvious" out of the way, you always need to have security re-implemented on the server. No matter what kind of logic you have in the client, you can't depend on the client to enforce security. You still need to validate every command / query that gets sent to the server.
But, I'm sure you already know that - it sounds like you're more concerned with having to duplicate fine-grained view-logic on the client. And, to be fair, I don't have too much experience with an application that has that kind of logic; at least not with anything recently.
I built and app a few years ago that had 5 different "roles" of logins that all had completely different views of the systems. Much more so that simply turning on/off different views. When I was building that, each system has its own code base (over simplified). If I were to re-create that as an AngularJS app or SPA, I'd probably do the same thing - I'd have each "role" as its own "app". Something like:
/assets/apps/administrators/ ...
/assets/apps/teachers/ ...
/assets/apps/regulators/ ...
Of course, that app was so huge, I may completely forego the SPA and just stick with the request/response model.
But, before I blabber on, are we talking about the same stuff? Or am I misunderstanding what you mean?
@Ben, I was thinking of this when I had an ahah moment. Would it make sense to have these files living within your app server, so you would link to a .cfm or .php or something that would ensure the current session was authorized to grab it. Your initial page would almost determine does the session exist and if so, what's the role of the user. Thoughts?
@Phil,
The way we have our application set up is that the sub-views are all .htm pages. BUT, the root page - the main index page is a CFM page. And, we do this for a number of reasons. For starters, our application is running ColdFusion and FW/1 and it's easier to get a CFM page to integrate into the view-rendering that FW/1 does. But, secondly, and more importantly than that, we have the main page be a CFM page so that we can pre-authenticate the user *before* they actually render the page.
I've looked at examples where the login system was integrated into the AngularJS app; but, we wanted to forego the complexity that that involved. I'd rather be able to make the assumption that the user in the AngularJS app is already authenticated.
So, we assume the user it authenticated by the time they get to the AngularJS app; but, we also have an HTTP interceptor to make sure that none of the AJAX requests inside the AngularJS app returns a 401 Unauthorized. If it does, the HTTP interceptor bounces the user out of the AngularJS app.
@Phil,
Just to clarify, our main index page would be in something like:
/subsystems/desktop/views/main/default.cfm
... and the "AngularJS" files are in something like:
/assets/apps/desktop/....
Another benefit of the main page being a ColdFusion page is that you can inject dynamic data right into the page itself. Something like:
Then, this "config" object can be injected into your AngularJS modules using the core dependency injection features of Angular. This can be a really nice benefit.
@Ben,
Ah, FW/1, also at the top of the list to get my head around.
@Phil,
Yeah, I only know a bit about FW/1 - enough to get some pages rendering. Jamie set up most of the FW/1 boilerplate. It seems pretty cool, though.
@All,
One of the biggest hurdles, for me, in AngularJS was figuring out how to most effectively render a page and how to react to route changes ONLY IF I needed to. Here's a further explanation of how I am now doing this:
www.bennadel.com/blog/2441-Nested-Views-Routing-And-Deep-Linking-With-AngularJS.htm
I find this approach to be very flexible and allow for arbitrarily nested views with low complexity.
@Ben,
First things first.... Great Blog:) Thank you.
I'm a Visual Studio .NET developer and have just started playing around with AngularJS. I've also had a look at Breeze and this seems to play nicely with Angular, but.....
The company I work for is still using Windows XP and IE8. This is a problem because although Angular plays ok with IE8, Breeze does not:(
I really like the way I can use Breeze LinQ type queries against my .NET Web.Api. Unfortunatly this does not work with IE8.
I raised this issue here http://stackoverflow.com/questions/14238134/breeze-and-angular-todo-app-does-not-work-with-ie-8
Any ideas?
Any help appreciated.
Regards, Paul
@Ben,
Sorry for the slow reply, regarding mobile, I'm using it with Phonegap for an iOS app.
Everything I've built and run in Chrome is working well, it's a little slow on my iPhone but to be honest I think that's more to do with jQuery mobile. The more I work on it the more I drop jQM and the app itself seems to be much more responsive now.
I don't think I'm using AngularJS as well as I could be, I'm constantly finding out things as I go along and updating the way I work, but it's definitely changed the way I build apps and I like it.
The short answer - it seems to work well with Phonegap and runs alright on my phone. It's not a very complex app though.
Pete
Ben, it'd be great to hear about your experiences.
Especially how you handled (and your thoughts about) server-side data validation - while I feel it necessary, I haven't found any way which doesn't need me to code my validation logic twice; and redisplaying server-side-generated error messages in AngularJS apps is not neat...
@Paul,
Unfortunately, I don't know much about .NET or Breeze, sorry :(
@Pete W,
That's interesting regarding the jQM performance. I've not done too much in the mobile world yet... and the bit that I have done definitely shows that lack of experience. Glad to know that AngularJS can be a feasible approach, at least for small apps maybe.
@Peter,
The app I'm working on right now doesn't have a whole lot of "input" type data collection. Mostly, we have a lot of interactions that don't really require too much client-side validation. As such, most of the validation we have to do on the server is more like, "Does user X have the right to do action Y. Is entity Z in the right state for action Y," ... and less like, "Is that a valid email address."
That said, we do have some forms and we keep the client-side validation very minimal - mostly checking lengths.
AngularJS does have some sort of validation framework built into its Form stuff using CSS; but, I have not really looked at it at all.
http://docs.angularjs.org/guide/forms
You can create custom validation, according to the docs. So, hopefully they've created it in such a way where you don't have to re-create your rules in two places so much as re-defining them???
I'm at about low point #2. I'm not really thrilled with it but it seems to be getting some good reviews so I'm taking some time to build apps with it so at least I know what I'm talking about. The thing that strikes me as completely contradictory to everything I've been taught especially with regard to the past 5 years, is that with angular, there seems to be a lack of separation of concerns. Nobody seems to be talking about it either. Take this example:
<div ng-controller="MyCtrl">
...
<button ng:click="save()">Save</button>
</div>
What's the difference between that and the old school method:
<div>
...
<button onclick="save()">Save</button>
</div>
Have we not learned anything??
@Colyn,
What would you prefer?
The difference, IMO, is that in the Angular approach, at least the save() method is part of a container of functionality which has clear boundaries and can be independently tested. It is calling specific functionality of a controller object, rather than a random global function with potentially unknown dependencies.
We're using Angular to build webapps. I don't think we should shy away from living in the HTML/web world. Trying to de-couple everything to the extreme leads to a system that is harder to understand and maintain.
@Matt,
It's the Matt Kruse! lol. You were who web designers turned to before jQuery came along... Years ago I used a lot of your stuff and I'm forever grateful for what I've learned from you.
With that out of the way, I would definitely prefer the angular way but it just feels dirty. For years I've trained myself to avoid inline event handling and now I just prefer it that way. I think it's cleaner and easier to debug, unit test, etc and it keeps my HTML clean. On the other hand, I really like the ability to create custom directives in angular, so it might actually be possible to wrap some of the event handling via a custom directive:
<button form-save>Save</button>
Which in theory if I'm able to do this, will give me the separation I prefer. But I'm still very new at this so it might not be the best way to go about it.
@Colyn,
That's a really good question. Like you, I've been doing everything I can (I the past some-odd years) to get JavaScript out of the DOM and into my JavaScript modules. But, I think what Misko Hevery (AngularJS creator) and @Matt are saying is that it comes down to "context."
When we used to put onclick="" handlers in our DOM, there was no real context, other than the DOM node itself and the window, which had the click handler defined. So, basically there was one context for the entire document.
In AngularJS, the context for all of the "inline features" is the current $scope which binds the View to the Controller. But, rather than having a single context for the entire document (ala "window"), we have many $scope instances that define strict boundaries for granular parts of the DOM. Furthermore, since $scope instances inherit from each other using prototypal inheritance, you can actually define behaviors for a sub-section of the DOM.
Try taking a look at this demo:
www.bennadel.com/blog/2425-Decorating-Scope-Methods-In-The-AngularJS-Prototype-Chain.htm
In it, I have three separate scopes - three separate contexts - that all have the same method - setWindowTitle(). Yet each of them defines that behavior in a way that is specific to the part of the UI that uses it.
Context is very powerful.
Regarding Twitter Bootstrap, have you used angular-ui bootstrap? I.e. did you ever include jquery? jquery seems very redundant with angularjs.
using angular-ui bootstrap (no jquery, just bootstrap css) most stuff work except for the 'hamburger' navi button when resized (for smaller screens)
@Andreas,
Angular includes a lite version of JQuery in the framework itself. If you include the full version JQuery in your page, Angular will use that instead of the lite version.
There are obviously a ton of extra features that jQuery brings to the table that come at a small cost of added filesize. In general we at RideAmigos include the full jQuery along side Angular.
Don't hesitate to include jQuery if you would like to use the features... check out this Stack Overflow post for more details: http://stackoverflow.com/questions/13151725/how-is-angular-js-different-from-jquery
We still include jquery, but honestly? It's more of a "woobie" now. Just feel safer having it around, even though most of our dom manipulation has moved into directives.
@Andreas, @Ben D, @Sharon,
Honestly, I would probably include the jQuery library by default. At some point, you're gonna hit something that jQuery Lite can't do and it's gonna be confusing until you realize its a compatibility problem. If you're used to jQuery, as Sharon is saying, it's nice to know what the features are and not have to double-check your approach.
When going from a jQuery-driven approach to an AngularJS-driven approach, one of the first hurdles that I had to deal with that doing "transitions" IS harder in AngularJS. Things like slide-down and fade-in and the like. Especially when you are dealing with ngRepeat, it's so disorienting that you [may] sort of give up on some transitions that wouldn't normally have used.
That said, ALL that stuff CAN still be used in AngularJS once you get your head wrapped around the rendering and the timing. And, when you do, you're gonna want all the jazz that jQuery brings to the table.
... in my opinion :)
Actually, i'm rather disappointed with the community, specifically their google group.
i asked a rather practical question, a few days ago, and got zero replies.
@Avi,
I'm sorry that you've had a different experience than me. It seems that the AngularJS community is growing in size; it's possible that it has hit a tipping point where the main group simply doesn't have enough time to get to everyone's questions (the way they used to).
What was your question? Maybe we can help?
@Ben,
that would be most kind, Ben, thank you!
i posted my question in stackoverflow, including the relevant piece of code:
http://stackoverflow.com/questions/16249256/angular-directives-how-to-catch-events-of-a-nested-directives-elements
Blessings
@Avi,
Hmm, I took a look at your SO post and nothing jumps out at me. Transclusion is still something I'm wrapping my head around a bit. I've played with it some, but I don't fully understand the intricacies of its lifecycle and binding considerations.
From the DOM perspective, I see you are using html( "" ) to clear the element before re-populating it with the various parts of the UI. It's possible that jQuery is actually unbind the event handlers when you do this.
What if, you try using .detach() to remove the pane1/pane2 references, and THEN do the clearing of the html:
scope.pane1 = pane1.detach();
scope.pane2 = pane2.detach();
element.empty() // same as html( "" )
That might help with the event bindings?
@Avi,
I just tried something similar in a test page and can confirm that the .html("") call WILL unbind the event handlers of the nested elements. Take a look at this quick video I put together:
http://screencast.com/t/6m5byGXmYt
Hope that helps.
@Ben,
That's excellent! i suspected it was something of this kind. It was most helpful!
~avi
It's funny really just how well that image describes the way I would imagine most people that go with angular for some project is. I have had a similar roller-coaster ride with it as well, but not quite as extreme since I'm just using it for personal projects
Is there any error logging and handling framework in angularjs, if not then in what way I can do this.
@Avi,
Really glad to help!
@Jaredwilli,
I'm finding a this image hits home with a lot of people :) Hopefully we can all work through the rough patches together!
@Prateek,
AngularJS has error logging built-into it. But all it does it log to the console and make sure the error doesn't break things (as far as I know). You can override the error handling using the "$exceptionHandler". But, I don't know too much about it. The only thing that I do is basically look into the $exceptionHandler and using jQuey AJAX to post JavaScript errors to the server using normal AJAX methods.
I'll try and put a small demo together for it.
@Ben,
Thanks for your reply,
I am waiting for demo.
I am coming from flex background and that's the reason I am getting confused with the way modules work in Flex and in Angular...can you help me in explaining how can i define multiple modules and each module should have it's own controller, services and directives etc
And my main index.html should not contain all the javascript files for all modules controllers and directives, i need a way in order to have them in separate module related files
@rohan,
Here's a post with good ideas on module and file organization with AngularJS:
http://cliffmeyers.com/blog/2013/4/21/code-organization-angularjs-javascript
@Jamie Krug: Thanks a lot buddy for the link... it will be great if you explain me the communication between two modules using the events with sample application... thanks in advance
@All,
One of the hardest parts of AngularJS is wrapping your head around Directives. At first, I found that my directives knew too much about the world - I had too much of my Controller "implementation" leaking into my Directives. What I've found over time is that the best way to create cleanly separated directives is to simply not build them at all! Or, rather, to delay building them for as long as possible:
www.bennadel.com/blog/2476-My-Approach-To-Building-AngularJS-Directives-That-Bind-To-JavaScript-Events.htm
In doing so, you make sure your Directive remains a "consumer" of the Controller and $scope, and doesn't accidentally become an "extension" of it.
@Rohan,
One thing to realize about modules, though, in AngularJS is that they all live in the same dependency-injection namespace. So, while you can group your code in modules, all your services, directives, value objects, etc. have to be globally-uniquely named within the AngularJS application for the dependency injection to work.
The only thing that I've found it easy to "namespace" was the Controller since it's value is both defined and referenced as a string.
That said, I know nothing about Flex and how it was put together; so, I can really speak to any comparison / contract on that front.
@rohan,
You might also check out this demo app:
https://github.com/angular-app/angular-app
I am trying "expect(element('.tab-content div span').text()).toMatch("hardcode");"
for e2e testing using karma, it is fine but I want to match "element('.tab-content div span').text()" with contents in files like xml or text file, I don't want to hardcode this toMatch("hardcode"), is it possible?
Hi Guys,
Actually i am doing e2e test of angular js of my project but i am not getting one thing that is how to press enter key through the test when my form is filled as i am not using a button but a form.
And form is submitted by pressing a enter key.
so what element should be used i tried with jquery
so please help me if u have a solution.
@Prateek,
to match a word or text you should use
.toContain('word')
that's a jasmine reference.
website is : http://pivotal.github.io/jasmine/
@Prateek,
Sorry, I have done much of anything with the e2e testing yet :(
I had some issues with $digest running on high frequency timed update. I found it very hard or impossible to handle each update manually. No, $digest is a global thing, and I understand why.
But some unnecessary calculations were made, and I'm a performance maniac, so like lightweight and efforts over magic.
I posted a couple of questions on the google group but not really found an answer.
Anyway, you might to have a look at soma.js if you want a framework with injection but with vanilla javascript as actors, it makes everything very reusable.
I also loved the angular workflow with the DOM but sometimes not willing to load 80k of framework, especially on mobile. So I built a template engine, DOM manipulation as angular. It doesn't have a ful parser as angular js but still have a lot of features, it makes the operation very fast. Workflow is very similar as I got the inspiration directly from it.
So for the curious:
http://somajs.github.io/somajs/
http://soundstep.github.io/soma-template/
Romu
This is funny. This is almost exactly my experience. I showed it to my boss who could also relate.
@Romu,
I've also had some problems with the digest stuff, especially in terms of Directives that are being linked in the context of ngRepeat. Having the directive do something can (sometimes) cause a LOT of unnecessary paints / redraws which slows down the rendering very noticably. I've had to get pretty tricky at times, wrapping the body of a Directive in a timer, or grouping a bunch of link-handlers together in a single timer... all stuff to limit redraws and the work that goes into a single or set of $digests.
Definitely there's a learning curve just to thinking about the processing that has to take place... AND when to even care about that overhead.
@Kevin,
Ha ha, awesome! Glad this struck a chord :D
I just went from "doomed" to "awesome" peak in 12 hours. Your drawing is perfect depiction of angularjs experience :D Imho anybody could sign under it.
Now, after a few month of a very intensive work with Angular, i can say the following:
1. Compared to other JS frameworks, this might be the best of its kind. Sencha (ExtJS) might be better, for those who prefer to build an application that is a bunch of ready-made web-components that just need to be heavily configured. Maybe EmberJS could be better if elegance is not important (i didn't try it).
2. ...Yet i think it has a long way to go, to make me feel JS UI frameworks are mature and beautiful and make me tingly :)
3. About the Dependency Injection mechanism and the module mechanism: until there's smart lazy-loading and smart-unloading, they are redundant and awkward; you could achieve better architecture with simple JS objects and scopes.
4. The data-binding is very nice and very useful.
5. The directive mechanism is also very nice yet it could be improved. i also miss some built-ins to easily access DOM elements from directive's template from the directive's code (and not as a result of an event).
6. JQLite is too light. The replacement of it with JQuery didn't work for me.
7. The digest/apply/eval mechanism etc. can (and i believe will) be improved.
8. Animation support - can be improved.
9. Memory leaks - on IE9 and older (yea, sadly i must be compatible to the piece of crap) - are problematic (ng-include can cause evil leaks, esp. under ng-repeat)
10. Directive inheritance/extension should be improved. It doesn't actually exist really; the way to achieve "overloading"-like ability, currently, is not elegant nor powerful enough (it's by definition a directive with the same name, and playing with the priority field...)
11. Tooling. Grunt/bower/yo support is still immature. i'm sure it will improve in the following year.
12. $location and routing can be improved (i think they did a lot already in 1.2)
and more...
@Edgars,
Niiice - sounds like you're moving faster than I was :D
@Avi,
I haven't gotten to play with the animation stuff; but, from what I've seen in the videos for 1.2, it looks promising. The one thing that I would think that it still misses is the "Don't animate on initial load... but animate everything else." I've tried to play around with that concept with directives and it's always a bit challenging, primarily with ngRepeat. With a directive that doesn't mess with DOM creation, things are a bit more straightforward.
More robust loading/unloading will also be interesting. I haven't looked into it at all yet - right now, in production, we just compile all our scripts and views together. It would be great to be able to do lazy-loading for the less-used parts of the application. I know there are some articles on RequireJS, but something more native would be awesome sauce.
And jQLite - I just went straight for jQuery. I didn't even bother trying to run things on jQLite - there was too much stuff missing right out of the box.
Overall, it's been really awesome - but, I think it has room and, as you say - will get better.
AngularJS feels just right, i never heard of it till few weeks ago, i was still coding using jQuery solo, i wanted a proper JS unit testing framework, my Google search lead me to experiment with Qunit for 2-3 days, but still i needed more, more search uncovered jstestdriver which integrates nicely with web storm but writing a realistic test for a complex feature took significant time & needless to say the project is no longer supported, till i finally came across AngularJS, i just love how it transforms web development completely, designed from the ground up to be testable with a BDD framework like jasmine, i think i have found the missing piece.
@Muhannad,
It sounds like you're really on the right track. Testing is something I need to get more into myself. I've started to really dabble in it on the server-side, but have barely scratched the surface on the client-side. So much to learn :( :)
Hello Ben,
Read your experience about angularjs.
M a newbie to the technology, I am stuck at one place and it devours a lot of my time.
I am using MVC 4.0 with .NET and Entity Framework.
I am trying to save data to multiple tables on a POST request to the server.
Its easy to save data to the table that is linked to the controller, but how do we save it to another table. I am using a collection because we are trying to pass multiple values for the same feild.
So basically I need to undersatnd the binding between "ICollection<Class_Name>" and angularjs.
Hi Ben,
Just wanted to write a quick thanks since I've been landing on your site a ton doing searches for different things in Angular and appreciate you taking the time to document your findings as you explore some new tech.
Totally agree on the chart too, Angular is a roller coaster, some things are impossibly easy and some things are seemingly just impossible (not literally, but you catch the drift).
I'm a bit surprised to see that you haven't been spammed here really, are you doing something alternative from the regular captcha to avoid bots?
Also how'd you make the chart (Illustrator, Inkscape, D3JS?)
Even if you don't have time to get back at me appreciate your taking the time to do make these posts.
-Shaun
I always refer to this blog post when I'm explaining AngularJS to people, and I wave my hand in the air to explain your "feelings about angularjs" graph.
I think I've just hit the "OMG That's Awesome!" stage. It's a good day for me and AngularJS, and more specifically directives.
Learn AngularJS With These 5 Practical Examples
http://tutorialzine.com/2013/08/learn-angularjs-5-examples/
I'm at:
I can't believe how difficult they make some of this stuff.
What is really painful is when you get the "Angular is Awesome" stage, then get bumped into another project full of legacy js code with no framework whatsoever. Feels like once was rich but now is poor.
Absolutely, 100% nailed it!
I've started from scratch with Angular, with very little knowledge of backbone, and I must say, I can't hardly understand how could anyone choose any other framework; I'm amazed. And honestly, taking away some little frustrating situation (because of my own limitation), not even once I thought the project was doomed.
If it is useful, I'm also totally into Restangular now....great complement.
Hi Ben,
interesting article about your experiences. What was the main reason you went with Angular over Backbone?
I am working on a project with AngularJS but my experiences are starting to look like your curve :)
AngularJS complexity makes it a BS as dev language.
JS is not a development language. Not OOP lang, very confusing, in real world not applicable.
In real world 90% corporations still use ASP.NET 2.0
It will be dead soon. None of the large corporations dont even think in investing in something like angularjs, nor they have people able to learn and/or support anything like that.
@Bob,
Plenty of "real world" apps use angular very successfully. Order a sub from JimmyJohn's, you're using Angular. Load up the YouTube app on PlayStation, you're using Angular. And JS is very suitable for development. Paypal recently switched their main account overview page from pure Java to NodeJS, there's a great blog post about it: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
@Richard Angular over backbone for a bit of a productivity boost when you need ease of binding. You can achieve something similar with Backbone + Marrionette. There are a lot of blog posts comparing Backbone to Angular. See this one: http://blog.nebithi.com/backbone-and-angular-demystifying-the-myths/
I don't see how this strange JS mutation can be better than any server-side generated HTML.
Performance? lol, based on my experience receive html generated on the server is not slower, but actually faster than loading and rendering all these JS libraries that depend on each other and then these JS libraries have to render HTML anyway on the client. Besides, you still need server-side code. bit and bytes of additional html tags is nothing these days and doesn't affect performance. However, loading huge JS libraries that don't work properly together and written by some strange people somewhere could be much more dangerous. Besides, in real world try to find a team of developers that know Angular JS, or even jQuery, or even JavaScript. lol Get real.
@Jonathan,
Not to my knowledge, I am currently looking for a job, 6 months already, in Canada. And I have over 17 years in architecture and development.
I have not found a SINGLE job posting where AngularJS is mentioned, not one in 6 months!
Actually I have NEVER seen any job postings asking for AngularJS, as well as I havent seen any job postings asking for any kind of JS framework other than jQuery. I assume that there are probably some companies on this planet that indeed try to use it ;) But not in the world I live in.
I was trying to learn it, but the effort is not worth the result. I understood one must dedicate weeks, maybe months, some - years to polish this framework. No companies, to my knowledge, are willing to go through this sacrifice today. Especially government and large corporations.
@Jon,
Client side interactions are important, as is having a site that works well on mobile. Having no JS in place means every interaction requires a round trip to the server try that on a 4G or worse 3G connection and you eat about .5s-1s just connecting to the tower not including transmitting the payload. It's much better to concat and minify your JS then use gzip to make the initial payload as small as possible but contains everything needed aside from extra data payloads you may load separately when needed. (CDN also helps reduce this issue)
@Bob
https://www.google.com/search?q=angularjs+jobs&oq=angularjs+jobs&aqs=chrome..69i57j0l3.1514j0j1&sourceid=chrome&ie=UTF-8#q=angularjs+jobs&start=10
There are plenty of projects using AngularJS it's definitely still an up and coming thing though and likely not well known by those doing hiring.
http://builtwith.angularjs.org/
Being a Google backed technology and allowing for clean testable front end code makes it ideal for large projects where a test suite is absolutely necessary. It also eliminates all the boilerplate code that teams tend to re-write for allowing some sort of binding and message/event buses, and handle routing, not to mention the ability to write directives which can abstract and greatly simplify the code that the end user developers will write.
It doesn't take that long to learn enough to get a huge benefit out of the framework. I recently posted a video showing how to setup an environment from scratch here:
https://www.youtube.com/watch?v=zQNbsCTFrAA
If you aren't familiar with developing in JavaScript check out codeacademy.com, if you have questions about AngularJS itself, Ben's blog comes in handy a lot as well as egghead.io
Anyhow best of luck in your endeavors remember to keep an open mind, technology changes quickly.
@Shaun,
I dont know about the entire planet, when you you run google search.
I was talking about a country where I live, Canada, which is pretty big, agree?
Here are 2 biggest IT jobs sites in Canada, and here is the search result without any filters:
http://www.workopolis.com/EN/job-search/angularjs-jobs?ak=angularjs&lg=en
http://jobsearch.monster.ca/jobs/?q=angularjs&cy=ca
5-7 jobs only - for entire country? is this a joke? and all in British Columbia? This is definitely NOT a market for angularjs.
Is it worth spending time learning it? not for me.
I am not in a position to spend time learning stuff that has no demand. Maybe for personal amusement, but not for the purpose of finding a job.
Geez, you'd think some guys were being forced to learn this stuff at gunpoint. I didn't get a job because I knew AngularJS, but I KEPT my job because we used it to reduce our code base by 30%.
The guys on my team learned to use AngularJS well enough to start streamlining code in a week. How? We did this awesome thing called "reading a book".
If you are just learning something to get a job and nothing else, I'd say you're in the wrong career. Clock punchers don't make very good developers.
@Peter
You probably missed the last paragraph I wrote:
Is it worth spending time learning it? not for me.
I am not in a position to spend time learning stuff that has no demand. Maybe for personal amusement, but not for the purpose of finding a job.
For personal amusement - it's ok, not for finding a job.
I am in a position where I interview programmers, and I'd like to inject something that may be helpful.
What is said: "There is no demand for it (that I know of). Why should I learn it?"
What I hear: "I am possibly unimaginative. My value may be limited to rote fulfillment of prescribed tasks."
And from the resume angle, I get dozens across my desk that read JavaScript/JQuery these days. Someone that puts down AngularJS or other emergent (more on AngularJS as emergent in a few) technology kills two birds with one stone: shows a higher degree of initiative than his peers, and importantly, demonstrates a broader skill set. Whether I use his skills or not, he's demonstrated his ability to learn something new.
This is Getting Hired 101 type stuff, however. I won't beat anyone further over the head with that.
As far as "no corporations are using this/there is no demand," I ask rhetorically, what corporation makes a habit of broadcasting specific coding practices that they use?
I would consider AngularJS extremely mature, particularly with regards to its dependency injection. If you work an environment where unit testing is an absolute must, bonus points to the dev team that embraces anything new to the table. SPA is here to stay, and AngularJS is absolutely establishing itself as reliable and well-supported.
@Brian,
I used angular to make web app for google itself. I didn't have other opportunities, fortunately or unfortunately.
Do you realize how much you have to learn in order to test angular components compared to test vanilla code or frameworks closer to vanilla javascript?
While I understand completely the angular attempts, I think it failed in many ways. Writing angular code or writing unit test for angular code for that matter is no way near writing vanilla javascript. It just feels different, almost like another language. It looks like 2 different things, look at the in-html filter syntax, wow. The truth is, you either write angular code or javascript code. Something is telling me that you shouldn't focus on something too proprietary.
See the comments, angular is compared to technologies such ASP or others, while it is only a javascript frameworks. And should only be considered as such.
IMHO, I think angular is nice for developers who have a limited knowledge of how to structure complex problems and how to solve common problems. Please no offense here, there's nothing you can't do without angular. While angular workflow is nice and attractive, there's not much efforts to make to reproduce its most important features, or what you need at least. Angular is for a niche development: single application that runs on desktop.
Angular is a no-go to low-powered device developments in my opinion, where you need every actions to perform amazingly well all the way through, following performance in each single step of the developement, and with small code.
Vanilla javascript or being as close as possible to it is the way for me.
yes dependency injection is very good for testing, no argument here. But angular is not the only solution:
http://www.soundstep.com/blog/2012/09/12/infuse-js-ioc-javascript-library/
Well-established? I found bugs in the latests version, that have been reported 10 months ago, either not solved or closed while developers are still having them. I think they are just overwhelmed. I can throw pull requests when I have time, I'm happy with that, I'm just overwhelmed too!
The really good thing about angular? it made me learn and think because they are clever people behind it. Now angular might be nice in some cases, in some projects, but really far from being the all-occasion-winner for single-page web app.
Again, it always comes back to the same thing: the right tool for the right job.
Not an all truth, just my opinions.
@Romu,
I agree with some of your points, not so much with others, but it all sort of misses my point.
Here it is, simpler:
a) Dismissing the value of learning this or that framework on the merits of its relevance to job finding is fallacious.
b) Dismissing the value of learning this or that framework on the merits of its relevance to corporate use is also fallacious.
You could honestly substitute any framework for the same argument I'm making.
I couldn't disagree with you more strongly on a couple of fundamental points.
1. You aver that AngularJS is a departure from vanilla JS. Perhaps in the scope of the template - it's not particularly intuitive, but it is well-documented, which mitigates the complexity of even what you cite, the in-html filtering. Otherwise, developing services, controllers, etc., looks like any other form of vanilla JS prototyping. It should feel damn familiar to any savvy JS developer, because it is.
2. Testing AngularJS work is no more or less exasperating than any other framework. Further, scads of folks, including myself, have taken the time to helpfully document, nay, hand-hold folks through unit and E2E testing using Node.JS, Jasmine, and Karma, or Protractor. If you can test vanilla JS, the skills are transferable to AngularJS. Period. To state otherwise is utter poppycock.
3. Bug fix turnaround is no indicator of establishment. Adobe has bugs reported early on in CF 10's release that still sit untouched, or have been declared moot. I keep tabs on AngularJS's issue tracker, and it enjoys the fluidity of any well-tended project.
I fundamentally agree with you, there is nothing that cannot be accomplished without vanilla JS, but that's never the point of a framework like this. I would argue that it's one of the best offerings for people with a real focus on testing driven development, that it's mature, that it's relatively stable, and it's worth even a casual skimming of the surface.
@Brian,
Do you know Prolog?
Do you anyone who knows Prolog?
I know Prolog, and I know Lisp,and ... lol Cobol.
The reason I am asking is related to your comment:
"And from the resume angle, I get dozens across my desk that read JavaScript/JQuery these days. Someone that puts down AngularJS or other emergent (more on AngularJS as emergent in a few) technology kills two birds with one stone: shows a higher degree of initiative than his peers, and importantly, demonstrates a broader skill set."
LOL, I can put whatever I want in my resume, assembler, lisp, prolog, cobol, name it... Doesnt mean shit... pardon my cobol.
99% of people LIE in their resumes to some extend. The same way employers LIE about their promises to use these technologies. The whole world is built on LIES these days.
Or they have learned the word $scope, and they put in the resume "AngularJS" :))
Having said that, why not give a preference to all those people who have Prolog in their resume?
But wait... who the hell needs Prolog in real world? Who needs AngularJs (in real world) and not in imaginary universe created by some bloggers copying stuff from one another?
You know how many blog posts I have read? Hundreds.. I guess. and 90% of them is a clear copy-paste from other blog posts (no thinking applied).
"a) Dismissing the value of learning this or that framework on the merits of its relevance to job finding is fallacious.
b) Dismissing the value of learning this or that framework on the merits of its relevance to corporate use is also fallacious."
huge mistake imho.
Why not learn Cobol, or Lisp, or Prolog, or Algol?
Why not? That would be ... fallacious.
Do you mind I rephrase you with these light changes:
a) Dismissing the value of learning this or that framework (Cobol, Lisp, Prolog or Algol) on the merits of its relevance to job finding is fallacious.
b) Dismissing the value of learning this or that framework (Cobol, Lisp, Prolog or Algol) on the merits of its relevance to corporate use is also fallacious.
Doesnt sound to good now, does it?
You totally nailed it Ben!
Hello !
Ok angular is good , Ember is Nice , Knockout is cute , backbone is wonderfull , SPA application are the future
My opinion all of these are juste like flash or Silverlight or javaApplets ; ephemere
No one told about resources , memory management ?
real world app are obese app not just phone app or todo app !!
Example Angularjs :
memory leaks are straights
$http release resources so late
ng-repeat creates more scopes then DOM elements
scope are gnarled and heavy weight
scope and its properties name are so longue making IE strive .
when i'll build my app with that angular all users must have 32GB RAM and 4GHZ CPU ?
@Lakhdar, Get real! I run Angular on cell phones with no problems. By your analysis Facebook or S3 services must be impossible to run on any computer.
I want to like Angular JS, but every time I try to get into it it overwhelms me with all the negative aspects of "big framework" coding.
May be Angular is not good for large scale applications! Even we ran into lot of memory issues. Later struggled to get rid of them.
@Himaja,
how dare you? LOL, can you elaborate more on your experience? where does angular get sluggish?
@muhannad,
:). Ofcourse, I worked on a medium scale application. It is completely an angular app. There is no doubt angular is amazing but, we ran into huge memory losses where, after using app for some time it started crashing. we used bindonce for ng-repeat, removed jquery dependency completely and implemented drag and drop, sortable like things in angular js. And sorry if I am wrong. I am still a learner. After struggling a lot with those memory issues, I thought that way.
And also, I am planning to write a cross platform application any body interested to join me?
@Himaja,
a mobile app? what's the project?
@muhannad,
It is a web application. It will have user hierarchy. Users can create content. They can create playlists with images, videos, html content. They can set the start date and end date. Those playlists can be assigned to the devices. Those playlist will be played on the digital signage boards. Locally user can also preview( SMIL Player ). It also has many other functions. I think, I shouldn't discuss much or my company will sue me ;).
@Himaja,
This talk from Google's DoubleClick team, at ng-conf, may provide some ideas for you: "Writing a Massive Angular App at Google" - http://youtu.be/62RvRQuMVyg
There's a good chance much larger apps than yours have been built with AngularJS, but you may have reached some use cases that require a more complex solution to meet the scale (as may be the case regardless of JS libraries/frameworks employed in your app).
@Jamie,
Thanks a lot. It is really helpful. :).
"Everything Should Be Made as Simple as Possible, But Not Simpler"
The feeling with Angular is that things are NOT as simple as possible but a lot more complicated that how they should be. Complexity diminishes understanding and make the developer more prone to put bugs in the code.
The simplicity of the first example at http://angularjs.org/ is quickly lost in any real world situation. Even the "Create Components" has more code than you would write in pure Javascript with some jQuery.
Most of the jQuery Plugins out there cannot be used anymore out of the box in AngularJs. You need to wrap them in directives and sometimes it is not even possible.
Sometimes the errors are cryptical and sometimes you do not have any error at all but things do not work as expected. You need to go under the hood and look at how the magic is working and unless you are a wizard in AngularJS internals, it is going to slow you down.
Using AngularJS require to go through a considerable steep learning curve. If you have a team that does not know Angular they need all to learn it. If you need to hire new developer they all need to go through the same learning curve and if you want to hire somebody proficient with Angular, you have a a lot smaller pool.
You should use a new technology if its pros offset the cons. My opinion is that this is not the case in Angular.JS.
A little example. Mansory.js would work with 5 line of javascript. If you want to use it with angular you need almost 200 lines to create a specialized directive. See https://github.com/passy/angular-masonry/blob/master/src/angular-masonry.js
OMG! My AngularJS Experience graph maps the same way! I am now on the "OMG! That's Awesome!" mark. Thanks Ben!
Like you I'm a jQuery guy, but even beyond that I love using plain old JS when I can.
Using custom tags and attributes doesnt sit well with me, and beyond two way data binding I don't see how Angular is doing a better job at Javascripting than jQuery. You could for all intents and purposes structure your jQuery in a way to mimic some of the patterns in Angular without it being too black magicky, afterall this is all just Javascript. You can do the same thing a dozen ways in JS, and you can do it without breaking the intent of HTML spec, even for a web app.
You could write a general plugin to handle two way databinding and statefulness and use it as a base plugin for any interactive components, that way you don't even have to think about it beyond sending data to a function endpoint. One day I hope to write a tiny jQuery framework for this that has a bit of an opinionated structure, is super lightweight, follows standards, and makes sense to everyone.
<rant>
I hate hate hate how Angular developers need to Javascript all of the things, even things that plain ol HTML/CSS can handle on its own. You dont need a dang directive for every element!
Angular encourages anti patterns and seems to only be a hit with people who never 'got' front end development, or any of the good principles that have been created over time. Web apps doesnt blow HTML standards out of the water. Sorry about it.
</rant>
Anyway, curious about your thoughts, since your blog is always a goto for me for Javascripty stuff.
@Chris,
I agree wholeheartedly. I really despise some of the poor practice that Angular is encouraging and you're right on target in that JS should be super simple!
I like the 'Our project is doomed' part:))) I was really enjoyed the process when it came to some very hacky project, previously written (horribly by me:) ) using Backbone, it took about three complete days to made all things done with angular.
The only thing I find confusing a little bit is animation. Of course because of IE. What if I need a carousel on my site? Then I need fallbacks cause of this and that... TweenLite/JQuery as dependencies? Ben, what do you think?
Hi Ben,
Thanks for sharing this, it made my day and gives me hope, because I see that I am not the only one with this exact feeling!
By the way, I came here because I feel frustrated about the ng-if creating its own scope. If you put a set of buttons inside a ng-if, it's really easy to end up with something that doesn't work and doesn't cause any exception!
Best Regards,
Roberto
When 2.0 cometh you'll need a new funny chart!
@Anthony,
You made my day there. You are already funny.
I am looking forward to the 2.0 funny chart.
The quality of software tools is not only measured by the success of software products created with them. I would like to see a graph of the cumulative damage done to your body by fluctuating cortisol levels over the same time period.
AngularJS gets things done and people dead (a couple of years sooner, at the very least).
I am, and have been in the doomed stage for the last week or so. Your chart hits right on the head!