| <a href='http://github.com/angular/angular.js/edit/master/docs/content/guide/introduction.ngdoc' class='improve-docs btn btn-primary'><i class="glyphicon glyphicon-edit"> </i>Improve this doc</a> |
| |
| |
| <h1 id="what-is-angular-">What Is Angular?</h1> |
| <p>AngularJS is a structural framework for dynamic web apps. It lets you use HTML as your template |
| language and lets you extend HTML's syntax to express your application's components clearly and |
| succinctly. Angular's data binding and dependency injection eliminate much of the code you |
| currently have to write. And it all happens within the browser, making it |
| an ideal partner with any server technology.</p> |
| <p>Angular is what HTML would have been had it been designed for applications. HTML is a great |
| declarative language for static documents. It does not contain much in the way of creating |
| applications, and as a result building web applications is an exercise in <em>what do I have to do |
| to trick the browser into doing what I want?</em></p> |
| <p>The impedance mismatch between dynamic applications and static documents is often solved with:</p> |
| <ul> |
| <li><strong>a library</strong> - a collection of functions which are useful when writing web apps. Your code is |
| in charge and it calls into the library when it sees fit. E.g., <code>jQuery</code>.</li> |
| <li><strong>frameworks</strong> - a particular implementation of a web application, where your code fills in |
| the details. The framework is in charge and it calls into your code when it needs something |
| app specific. E.g., <code>knockout</code>, <code>ember</code>, etc.</li> |
| </ul> |
| <p>Angular takes another approach. It attempts to minimize the impedance mismatch between document |
| centric HTML and what an application needs by creating new HTML constructs. Angular teaches the |
| browser new syntax through a construct we call directives. Examples include:</p> |
| <ul> |
| <li>Data binding, as in <code>{{}}</code>.</li> |
| <li>DOM control structures for repeating/hiding DOM fragments.</li> |
| <li>Support for forms and form validation.</li> |
| <li>Attaching code-behind to DOM elements.</li> |
| <li>Grouping of HTML into reusable components.</li> |
| </ul> |
| <h2 id="a-complete-client-side-solution">A complete client-side solution</h2> |
| <p>Angular is not a single piece in the overall puzzle of building the client-side of a web |
| application. It handles all of the DOM and AJAX glue code you once wrote by hand and puts it in a |
| well-defined structure. This makes Angular opinionated about how a CRUD application should be |
| built. But while it is opinionated, it also tries to make sure that its opinion is just a |
| starting point you can easily change. Angular comes with the following out-of-the-box:</p> |
| <ul> |
| <li>Everything you need to build a CRUD app in a cohesive set: data-binding, basic templating |
| directives, form validation, routing, deep-linking, reusable components, dependency injection.</li> |
| <li>Testability story: unit-testing, end-to-end testing, mocks, test harnesses.</li> |
| <li>Seed application with directory layout and test scripts as a starting point.</li> |
| </ul> |
| <h2 id="angular-sweet-spot">Angular Sweet Spot</h2> |
| <p>Angular simplifies application development by presenting a higher level of abstraction to the |
| developer. Like any abstraction, it comes at a cost of flexibility. In other words not every app |
| is a good fit for Angular. Angular was built with the CRUD application in mind. Luckily CRUD |
| applications represent the majority of web applications. To understand what Angular is |
| good at, though, it helps to understand when an app is not a good fit for Angular.</p> |
| <p>Games and GUI editors are examples of applications with intensive and tricky DOM manipulation. |
| These kinds of apps are different from CRUD apps, and as a result are probably not a good fit for Angular. |
| In these cases it may be better to use a library with a lower level of abstraction, such as <code>jQuery</code>.</p> |
| <h1 id="the-zen-of-angular">The Zen of Angular</h1> |
| <p>Angular is built around the belief that declarative code is better than imperative when it comes |
| to building UIs and wiring software components together, while imperative code is excellent for |
| expressing business logic.</p> |
| <ul> |
| <li>It is a very good idea to decouple DOM manipulation from app logic. This dramatically improves |
| the testability of the code.</li> |
| <li>It is a really, <em>really</em> good idea to regard app testing as equal in importance to app |
| writing. Testing difficulty is dramatically affected by the way the code is structured.</li> |
| <li>It is an excellent idea to decouple the client side of an app from the server side. This |
| allows development work to progress in parallel, and allows for reuse of both sides.</li> |
| <li>It is very helpful indeed if the framework guides developers through the entire journey of |
| building an app: from designing the UI, through writing the business logic, to testing.</li> |
| <li>It is always good to make common tasks trivial and difficult tasks possible.</li> |
| </ul> |
| <p>Angular frees you from the following pains:</p> |
| <ul> |
| <li><strong>Registering callbacks:</strong> Registering callbacks clutters your code, making it hard to see the |
| forest for the trees. Removing common boilerplate code such as callbacks is a good thing. It |
| vastly reduces the amount of JavaScript coding <em>you</em> have to do, and it makes it easier to see |
| what your application does.</li> |
| <li><strong>Manipulating HTML DOM programmatically:</strong> Manipulating HTML DOM is a cornerstone of AJAX |
| applications, but it's cumbersome and error-prone. By declaratively describing how the UI |
| should change as your application state changes, you are freed from low-level DOM manipulation |
| tasks. Most applications written with Angular never have to programmatically manipulate the |
| DOM, although you can if you want to.</li> |
| <li><strong>Marshaling data to and from the UI:</strong> CRUD operations make up the majority of AJAX |
| applications' tasks. The flow of marshaling data from the server to an internal object to an HTML |
| form, allowing users to modify the form, validating the form, displaying validation errors, |
| returning to an internal model, and then back to the server, creates a lot of boilerplate |
| code. Angular eliminates almost all of this boilerplate, leaving code that describes the |
| overall flow of the application rather than all of the implementation details.</li> |
| <li><strong>Writing tons of initialization code just to get started:</strong> Typically you need to write a lot |
| of plumbing just to get a basic "Hello World" AJAX app working. With Angular you can bootstrap |
| your app easily using services, which are auto-injected into your application in a |
| <a href="http://code.google.com/p/google-guice/">Guice</a>-like dependency-injection style. This allows you |
| to get started developing features quickly. As a bonus, you get full control over the |
| initialization process in automated tests.</li> |
| </ul> |
| |
| |