Take a look at Angular

This post is more than 2 years old.

Earlier this year I had the opportunity to hear Elliott Sprehn talk about Angular at cfObjective. I found the session fascinating and promised myself I'd play around with it a bit more later. I've finally gotten around to doing so and I thought I'd share a few thoughts on why folks may want to check it out.

First, what is Angular? At a high level it's a JavaScript library, much like jQuery is. (Edit: Ok, so "library" is not how Angular likes to describe itself, as you can read here in the "More Angular Philosophy" section. I get that - but I'm leaving the text in because I think it's the most direct way to get people thinking about Angular.) But what specifically does it feature? I'm going to quote their site and give a bit of commentary.

Declarative UI Templates
HTML is already a good templating language; angular makes it better. Preview your UI in your favorite HTML editor.

Right away one of the first things I noticed was that Angular reminded me a lot of Spry. I know I don't use Spry much anymore, but I have a great deal of respect for how easy Spry made it to take Ajax-loaded data and display it on screen. There's work being done on the jQuery side to help that as well (with templates), but seeing Angular's built in support for it really blew me away. As a simple example, and I know this won't be terribly clear out of syntax, but here's a simple template that iterates over a list of phones:

<ul> <li ng:repeat="phone in phones"> {{phone.name}} <p>{{phone.snippet}}</p> </li> </ul>

Code like this is something that a non-developer could easily work with. You could imagine a designer going in and tweaking layout.

Two-Way Data Binding
With angular, the view and data model are always in sync -- there is no need for manual DOM manipulation

What this means - to me anyway - is that there is much less $("#foo").html() and more just name=something. The binding allows you to work with data and have your display automatically update. It simplifies things quite a bit.

Framework
Angular supports the entire development process, provides structure for your web apps, and works with the best JS libraries.

MVC with Dependency Injection Separation of concerns, loose coupling, and inversion of control -- all the good stuff for testable and maintainable code.

This is where things get interesting. I've done a lot of jQuery work. A lot. But in general it's small features - ie a few things on a page. Certainly useful - powerful - etc. But not necessarily very deep. I've done a few games where I've gotten close to something that's a bit complex, but it's been a bit of a struggle to figure out the best way to organize things. It's a problem. And as I've said before - MVC (and design patterns in general) exist to help solve problems. I'm still wrapping my head around how Angular does this, but from what I see it makes adding MVC to your application very straight forward - especially with it's use of DI.

Here is what really sold me on Angular and - frankly - impressed the hell out of me. Angular has a tutorial. Ok, so do most frameworks. But what really surprised me was how well their tutorial is presented.

First - they make use of Git. Now - if you've never used Git before - don't let that scare you away. They lead you through how to get Git and tell you precisely what command lines you need to use. You don't have to learn Git. As you progress through the tutorial you load in a new branch for each step. What I realized - pretty early on - was that this allowed me to play around a bit. In fact, at the end of each step they have a set of experiments for you to try. This encourages you to screw around and best of us - if you break stuff - you have nothing to lose. Just go ahead to the next step and use Git to set the code up.

Second - they make use of unit testing. Right away. I'm not a TDD extremist, but I definitely encourage the use of unit testing, and seeing them being used throughout the tutorial was great. Let's be honest - no one is testing enough. (It certainly isn't just a problem for ColdFusion devs.) The more encouragement folks have to add testing to their development cycle the better off we will all be.

I haven't yet done any demos with Angular, but I'm hoping to build something involving a ColdFusion back end this week. I'm also interested to see if I can rebuild my old Hangman Adobe AIR application to make use of it. If any of my readers have used it and want to share their experiences, I'd love to hear about it. I'd also recommend the mailing list. I posted there a few times and got responses pretty quickly (and friendly responses at that - friendly communities rock).

p.s. Ok - so one thing I'm not sure about is if I should be calling it "Angular" or "AngularJS" or "<angular/>". I can promise you I'm not going to use the last version - that's too much typing. ;)

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Andrew Scott posted on 6/20/2011 at 12:49 AM

This is one of the reasons why ExtJS is so good, not only is it an OO framework but all the UI widgets are made up of smaller OO snippets of code, that can be easier to extend/overwrite and get that extra functionality. Don't like the way the Grid displays its data, then extand/overwrite the view class for the Grid and you have changed the way it looks, behaves with extremely minimal code.

Templates are no excpetion, ExtJS has had such things as templates before it even hit version 1.0 from memory. But to be able to write something like this has so much power, and so far I have not even seen jQuery come close to matching ExtJS and its awesome in these two areas.

ExtJS has had excellent Databinding for years and now with the new model, has become even more pwerful and it is has been using an MVC type of approach for sometime now, and has gotten a huge overhaul in the latest release as well.

And ExtJS has a similar approach to DI in the new release as well.

Now having said all that, it might still be worth a further look down the track.

Sorry not to ditch Angular, as it looks interesting. It is just that Angular so far is no different to ExtJS or ExtJS core at this stage except that the license may be appealable to many for Angular.

Comment 2 by Raymond Camden posted on 6/20/2011 at 1:37 AM

I've never had any doubts about the capabilities of Ext - I just plain don't like it. Much like I'm sure I could use Ruby to build sites like ColdFusion, I don't like Ruby's syntax and wouldn't enjoy coding with it.

Comment 3 by Andrew Scott posted on 6/20/2011 at 1:56 AM

Ok Ray why don't you like it?

The syntax is almost identical between ExtJS core and jQuery, and both provide the same desired results towards the end. The only difference is that one can write far less code with ExtJS than jQuery put together.

But as that is now off topic, I am sort of liking the way the binding works in Angular. The problem that I am seeing at the moment, and this may chnage in time as google develop this further, is the time it takes to traverse the DOM to make the binding changes. I haven't looked to far into this as yet, but from what I can tell off the cup, is that it traverses the DOM looking for the binding block and changes it accordingly.

So the more that needs binding on the page, could mean problems with the user experience as well. Might not be the case, but something to be aware off I guess.

Comment 4 by Raymond Camden posted on 6/20/2011 at 2:02 AM

Do I have to have a logical reason? I just don't. :) To be fair, some constructs in jQuery bugged me at first too. Maybe I haven't given Ext a fair shake. At the end of the day - it just doesn't interest me I guess.

Binding: I know binding can be an issue in Flex apps. I _seem_ to remember Elliott saying they worked to make binding perform well. I can't say that for certain though.

Comment 5 by Andrew Scott posted on 6/20/2011 at 2:07 AM

Knowing Google they will have looked at it with serious intent to overcome the DOM traversal, but in time it will worth keeping an eye on to see how well this develops and/or matures overtime.

Comment 6 by Raymond Camden posted on 6/20/2011 at 2:10 AM

Ajax performance in general is still something I don't know how well to test. I've got a good hand on the data portions (lessons I learned painfully), but outside of that, I've got a lot to learn.

Comment 7 by Andrew Scott posted on 6/20/2011 at 2:19 AM

Well to be honest I have done none of the tests to answer that either, but from what I can say with most frameworks that use Ajax are still using the standard type wrappers to the browser way of doing it. The difference is that there are extra featurs like callbacks and events that you don't get with the standard browser XHR way, not to mention configuration params for post and get etc, that you would have to write manually yourself.

I think the extra time it takes to run this wrapper for Ajax is nothing to be concerned about either. It will always run faster than the time it takes to connect to the remote call and get what you need. And at that point you are in the hands of your favourite browser.

Comment 8 by Jean Ducrot posted on 6/20/2011 at 5:59 AM

Ray,

Just a friendly heads up. In the second point you make to support how impressed you were with their tutorial (I was too BTW) you write "I'm now TDD extremist". I think you mean to say "I am not a" or "I'm no".

Since I never got the TDD evangelist vibe from you I am just looking out for your inbox flooding with that type of questions on Monday morning :)

Jean

Comment 9 by Dave Hoff posted on 6/20/2011 at 6:06 AM

In my opinion the best JS MVC framework available today is backbonejs. Not really digging these frameworks that want to do data binding through dom elements. Just feels icky to me. Backbone really helps you write better JS, making it clear how to best separate code, but keeping it light on convention. Check it out: http://www.backbonejs.com

Comment 10 by Raymond Camden posted on 6/20/2011 at 6:19 AM

@Jean: Oops, yep, I meant "not" - thanks.

@Dave: I've heard good things about Backbone too. I'll try to take a look sometime this summer.

Comment 11 by Andrew Scott posted on 6/20/2011 at 6:52 AM

Yeah Backbone is supposed to be fantastic, I haven't used it for nearly 5 years though so its probably gone through a lot in that time too.

Comment 12 by existdissolve posted on 6/20/2011 at 8:16 PM

@Andrew-- +1 from me for ExtJS. I've not used jQuery enough to really make a comparison, but I've loved working with ExtJS over the last couple years.

Curious: have you done anything with ExtJS 4 yet? I have to say, the full-on MVC approach threw me for a loop at first, but after using it for developing an entire application, I'm sold :)

Comment 13 by Raymond Camden posted on 6/20/2011 at 8:32 PM

@Existdissolve: Not sure if your second paragraph was for Andrew or "all of us", but for me, I haven't taken a good look at Ext lately. Maybe this summer - along with Backbone, I'll take another look. I still feel like it won't be a good fit though (and that's not Ext's issue of course).

Comment 14 by Andrew Scott posted on 6/20/2011 at 11:56 PM

Yes I have played around with ExtJS4, and can I say I love it. Was a pain to migrate some badly written code, but its worth the upgrade.

I also made a blog that shows how to read in an XML file into a data model, that can be used for a lot of scenarios. Data Models rock, the fact that they now support relationships, of manytoone etc, absolutely rocks.

http://www.andyscott.id.au/...

Comment 15 by Igor Minar posted on 6/21/2011 at 10:59 AM

@Ray Thanks for kinds words. Feel free to drop us an email on the mailing list if you have any further questions.

@Andrew don't worry about the data binding performance. It might surprise you to hear, that it performs better than a hand-coded dom manipulation in most cases. Especially if you start using repeaters (ng:repeat).

I gave a lightning talk on this topic at Velocity conference recently. It might be worth it capturing the main points in a blog post. In the meantime, you'll have to take my word for it or benchmark stuff for yourself.

Comment 16 by Andrew Scott posted on 6/21/2011 at 4:31 PM

@Igor, is that with a deeply nested dom?

From what I have seen so far, still want to find some time to sit down and play with it myself, but it looks fairly good to date.

Comment 17 by Vojta Jina posted on 6/21/2011 at 5:20 PM

Just note about ExtJs (I'm talking about v3.4, haven't touch v4.0):

I think ExtJs is FANTASTIC, especially the UI components. The overall design of the framework is good from the extendability point of view, but unfortunately not for testing. The separation of presentation and logic is very bad.

I worked on one bigger project on ExtJs and this was a big issue. It took a lot of energy to test and organize ExtJs code.
So this is a big advantage for angular - clear separation of logic (with full unit/e2e testing environment) and declarative presentation.

Comment 18 by Igor Minar posted on 6/21/2011 at 6:39 PM

@Andrew we traverse the dom only once - when the application starts - we call this phase html compilation.

Once a template is compiled, we have all the references to DOM nodes that may need an update, as well as all the binding expressions that we need to use to watch the model for changes.

So if anything, it might be the number of bindings on a page that could slow down your app. We estimate that you'll start to see issues only after adding a few thousand bindings to your template, which nobody has had a need to do yet in the real world.

Comment 19 by Andrew Scott posted on 6/22/2011 at 4:14 AM

@Igor, sorry but that was what I was referring to in the first place. I know even with the likes of ExtJS, jQuery and others the more DOM Nodes there are on the page, the slower it is to move something around on the screen. I used that as a reference, beause I would have imagined that the more binding on the page would have some impact.

Now this is not the fault of the JS framework/library as we all know, most browsers handle there DOM differently when they traverse etc.

So yeah that was my main concern, whether that might still be a problem.

Still I think so far this is still worth much further playing around with.

Comment 20 by Andrew Scott posted on 6/22/2011 at 4:17 AM

@Voita that I couldn't argue with, however in ExtJS4.0 it is now taken a leaf from Sencha Touch which is to now have an MVC type approach.

I am not sure it is perfect, haven't really had a good play with it as yet. But it looks fairly impressive to say the least.

Comment 21 by Igor Minar posted on 6/22/2011 at 8:40 PM

@Andrew we have yet to see a real world (useful) app, that has performance problems that we can't address somehow.

Comment 22 by Andrew Scott posted on 6/23/2011 at 8:47 AM

@igor, cool it was only a thought anyway.