AngularJS has been around for some time and has proven itself to be a framework that is here to stay. While there is a lot of promise (pun intended!) and speculation around the AngularJS 2.0 release, the 1.x releases have stabilized quite a bit. Checkout this blog from a colleague about why we think Angular is ready right now. I have personally had the opportunity to use it consistently over the last 18 months across 3 different code bases. We have solved some complex interactions and have built some nice reusable widgets. While no framework is without its quirks, and AngularJS has quite a few, on the whole we are quite pleased with everything it has to offer.
There are a lot of posts around that talk about each feature offered by AngularJS. However, there aren’t many that put all these features in context. Rather than the individual features, you should be looking at AngularJS as your framework of choice because of the way it enables rapid UI development. You can go from nothing to something that works within minutes. And this is not just a prototype – you can write production quality code as well as be functionally complete without always depending on a fully implemented backend.
To understand what makes AngularJS ideal for rapid development, let’s take a look at some of its features. Although these features by themselves don’t necessarily hint at helping one go fast, if you understand the implications, you can start building rich user interactions quickly.
Wishful coding (MVC paradigm)
“Wish that something exists and build on top of your assumption. Then go ahead and implement what you assumed” – this is a simple way of describing wishful thinking and coding. This is considered to be a very powerful tool while building complex systems and is usually considered one of the best ways to go very fast.
This is what makes AngularJS so powerful. Since there is just one place where you get the data and the rest of the code base is abstracted away from this, you can now start stubbing data. This lets you build out all the views and real interactions as if the back end APIs are implemented. This fits perfectly into the wishful thinking model.
In one of my first Aha! moments with AngularJS, a designer and a UI developer from my team sat together. They came out with an end-to-end UI implementation for the first set of stories of a feature with some simple stub data. Within a few hours they had a completely operational UI that we then put in front of our end users. We iterated over this rapidly developing UI using the real feedback from the users. Within a couple of days we had exactly what our end users wanted and loved.
Now, the great thing about doing it this way is that the data contract that the UI needs is already available to the backend developers. All they have to do is to go ahead and implement the API to return a JSON (or any other format) response that matches the UI’s expectation or receive the data that the UI is providing.
On my current project, one of my colleagues calls this approach “Building the walking skeleton”. The operational UI is the bones and the data is the muscle which is yet to be implemented.
Two way data binding
While this may not seem like a lot, once you start using two way binding heavily, you will realize the amount of code you have not written is huge. You would hate working in an environment where there is no two way binding!
Going fast is completely useless if you keep breaking things that are already working. The only way to ensure this is to be able to write and run automated tests. Anyone who has written JavaScripy tests for, say, jQuery code, knows that it can get very messy. You have to maintain the HTML that you would use in tests because the production HTML might have changed.
This is where the modularization of AngularJS comes very handy. Dependency injection, directives and services all make testing very easy. You can start building small, reusable units that are unit tested, making life simpler.
For example, let’s say you are building a Google Calendar-style widget. You can potentially build reusable components like time slots, day widget, week widget, etc., where each builds on the finer grained widgets. You can independently test each of these. The widget’s view component is associated with the production code, so in the test you don’t need to muck around with any HTML. Thus you can write simple, easy to understand and maintainable unit tests.
Frameworks like Karma now make this so simple that there is just no excuse to avoid writing tests anymore.
Given that AngularJS has been around for sometime, chances are that for any issues you might run into, there’s already someone who has solved it. Breadcrumbs, pagination, data tables, filters – whatever you can think of – there is most likely an AngularJS module out there that takes care of it. There is also a nice AngularJS-Bootstrap integration that works very well and is easily extensible. This means you can start rolling out your UI without having to reinvent the wheel.