Angular provides a methodology to implement via JavaScript, an MVC (model-view-controller) framework, for web-based applications. With Angular JS you can extend HTML and HTML5 within the framework.
10 reasons why Angular is of interest.
Most frameworks implement MVC by asking you to split your app into MVC components, then require you to write code to string them up together again. That’s a lot of work. Angular implements MVC by asking you to split your app into MVC components, then just let Angular do the rest. Angular manages your components for you and also serves as the pipeline that connects them.
Because Angular acts as the mediator, developers also won’t feel tempted to write shortcuts between components that break abstractions just to make them fit easier.
Angular uses HTML to define the app’s user interface. HTML is a declarative language which is more intuitive and less convoluted than defining the interface procedurally in JavaScript. HTML is also less brittle to reorganize than an interface written in JavaScript, meaning things are less likely to break. As well, you can bring in many more UI developers when the view is written in HTML.
HTML is also used to determine the execution of the app. Special attributes in the HTML determine which controllers to use for each element. These attributes determine “what” gets loaded, but not “how”. This declarative approach greatly simplifies app development in a sort of WYSIWYG (what you see is what you get) way. Rather than spending time on how the program flows and what should get loaded first, you simply define what you want and Angular will take care of the dependencies.
Data models in Angular are plain old JavaScript objects (POJO) and don’t require extraneous getter and setter functions. You can add and change properties directly on it and loop over objects and arrays at will. Your code will look much cleaner and more intuitive, the way mother nature intended.
Traditional data models are the gatekeepers of data and are responsible for data persistence and server syncing. Those data models behave like smart data providers. But since Angular’s data models are plain objects, they behave more like a cork board. A cork board is nothing more than a temporary storage area for people to put and retrieve data. However, Angular’s cork boards work closely with a controller and view. To differentiate it from the traditional sense of data models, Angular calls them “scopes”.
All properties found on the scope object are automatically bound to the view by Angular. Meaning, Angular quietly watches for changes to these properties and updates the view automatically.
The scope has no data to begin with and relies on the controller to feed it data according to business logic needs.
Directives are Angular’s way of bringing additional functionality to HTML. Imagine a world where HTML has so many rich elements (for example <accordion></accordion>, <grid></grid>, <lightbox></lightbox>, etc.) that we never have to manipulate the DOM to simulate them. All that our app needs to do is to assign attributes to elements to get any functionality out of the box.
Directives achieve this by enabling us to invent our own HTML elements. By putting all our DOM manipulation code into directives, we can separate them out of our MVC app. This allows our MVC app to only concern itself with updating the view with new data. How the view subsequently behaves is up to the directives.
Directives come in the form of custom HTML elements
<myticker></myticker>
custom attributes
<div data-myticker></div>
and custom class names
<div class=”myticker”></div>
allowing them to be used like regular HTML elements.
Directives are designed to be standalone reusable elements separate from your app. In fact, if a particular element becomes adopted by the HTML5 standard, it should be as simple as removing your custom directive, and your app should behave exactly the same without needing to change your app.
Remember, as a rule of thumb, your controller should not manipulate the DOM directly. All DOM manipulations should be performed by directives.
Filters cleanse the data before they reach the view and can involve something as simple as formatting decimal places on a number, reversing the order of an array, filtering an array based on a parameter, or implementing pagination. Filters are designed to be standalone functions that are separate from your app, similar to Directives, but are only concerned with data transformations.
Filters are so resourceful that it is possible to create a sortable HTML table using only filters without writing any JavaScript.
All the points up till now mean that you get to write less code. You don’t have to write your own MVC pipeline. The view is defined using HTML, which is more concise. Data models are simpler to write without getters/setters. Data-binding means you don’t have to put data into the view manually. Since directives are separate from app code, they can be written by another team in parallel with minimal integration issues. Filters allow you to manipulate data on the view level without changing your controllers. Yes, this is sort of a summary bullet point, but writing less code is a big deal!
Traditionally, the view modifies the DOM to present data and manipulates the DOM (or invokes jQuery) to add behavior. With Angular, DOM manipulation code should be inside directives and not in the view. Angular sees the view as just another HTML page with placeholders for data. This way of looking at the view pairs nicely with user interface designers.
By abstracting out the DOM manipulations and jQuery calls, user interface designers are able to focus on the view without those distractions.
By making your MVC app purely about presenting business data into views, and not have to worry about manipulating DOM, web app development suddenly became more fun.
Controllers in Angular are simple functions that have one job only, which is to manipulate the scope. For example, you can use it to prefill data into the scope from the server or implement business logic validations. Unlike other frameworks, controllers are not objects and don’t inherit from anything.
If controllers are so simple, then where should all the heavy lifting be performed? Angular introduces Services to do just that.
Services are exactly what they sound like. They don’t get involved with the MVC of your app, but simply provide an outward API to expose whatever you want it to expose. Most of the time it syncs up to a server to maintain an offline data store and exposes methods to push and pull data to and from a server. Or it can be used to create a resource sharing service that allows multiple controllers to share the same resources.
Services are designed to be standalone objects separate from your app and allow your controller to be remain lean and dedicated to the view and scope that it is assigned to. Of course, implementing services is not required and it is perfectly acceptable to do some light lifting inside your controller to avoid over complexity.
A PubSub system is a pretty common tool that allows for decoupled communication. Most PubSub implementations on the web are not context aware. Sometimes you want a PubSub message to be readable only by children of a particular node, or only readable by the ancestors of a particular child. In other words, sometimes you don’t want unrelated MVC components to be reading your messages.
The PubSub system in Angular is precisely that broadcast() will send a message to all children controllers, while emit() will send a message to all ancestors.
But PubSub isn’t the only way to communicate between controllers. In fact, if all you’re doing is telling other controllers to update their views when a property changes, you should be relying on data-binding. We already know that the view can be bound to properties on the current scope. But what I didn’t tell you is that scopes inherit the properties of their parent scopes. That means if a property exists on the parent scope, and a child scope modifies it, then all other scopes that inherit from the same parent will also see the same modification and their views will be updated automatically by Angular! This automated way beats using PubSub any day.
What description of Angular would be complete without talking about it’s unit testing readiness? The whole of Angular is linked together by Dependency Injection (DI). It’s what it uses to manage your controllers and scopes. Because all your controllers depend on DI to pass it information, Angular’s unit tests are able to usurp DI to perform unit testing by injecting mock data into your controller and measuring the output and behavior. In fact, Angular already has a mock HTTP provider to inject fake server responses into controllers.
This beats the more traditional way of testing web apps by creating individual test pages that invoke one component and then interacting with it to see if it works.
These 10 reasons should give you an idea of why Angular is so powerful. Not all web apps should use Angular. For example, if you are writing a game or a computationally intensive math program, there is no reason why Angular would fit your particular problem domain. But for generic web apps, it should serve as a viable framework to build upon.
