AngularJS isn’t the solution to every problem, and it important to know when you should use AngularJS and when you should seek an alternative. AngularJS delivers the kind of functionality that used to be available only to server-side developers, but entirely in the browser. This means that AngularJS has a lot of work to do each time an HTML document to which AngularJS has been applied is loaded—the HTML elements have to be compiled, the data bindings have to be evaluated, directives need to be executed, and so on, building support for the features I described in Chapter 2 and those that are yet to come.
This kind of work takes time to perform, and the amount of time depends on the complexity of the HTML document, on the associated JavaScript code, and—critically—on quality of the browser and the processing capability of the device. You won’t notice any delay when using the latest browsers on a capable desktop machine, but old browsers on underpowered smartphones can really slow down the initial setup of an AngularJS app.
The goal, therefore, is to perform this setup as infrequently as possible and deliver as much of the app as possible to the user when it is performed. This means giving careful thought to the kind of web application you build. In broad terms, there are two kinds of web application: round-trip and single-page.
1. Understanding Round-Trip and Single-Page Applications
For a long time, web apps were developed to follow a round-trip model. The browser requests an initial HTML document from the server. User interactions—such as clicking a link or submitting a form—led the browser to request and receive a completely new HTML document. In this kind of application, the browser is essentially a rending engine for HTML content, and all of the application logic and data resides on the server. The browser makes a series of stateless HTTP requests that the server handles by generating HTML documents dynamically.
A lot of current web development is still for round-trip applications, not least because they require little from the browser, which ensures the widest possible client support. But there are some serious drawbacks to round-trip applications: They make the user wait while the next HTML document is requested and loaded, they require a large server-side infrastructure to process all of the requests and manage all of the application state, and they require a lot of bandwidth because each HTML document has to be self-contained (leading to a lot of the same content being included in each response from the server).
Single-page applications take a different approach. An initial HTML document is sent to the browser, but user interactions lead to Ajax requests for small fragments of HTML or data inserted into the existing set of elements being displayed to the user. The initial HTML document is never reloaded or replaced, and the user can continue to interact with the existing HTML while the Ajax requests are being performed asynchronously, even if that just means seeing a “data loading” message.
Most current apps fall somewhere between the extremes, tending to use the basic round-trip model enhanced with JavaScript to reduce the number of complete page changes, although the emphasis is often on reducing the number of form errors by performing client-side validation.
AngularJS gives the greatest return from its initial workload as an application gets closer to the single-page model. That’s not to say that you can’t use AngularJS with round-trip applications—you can, of course—but there are other technologies that are simpler and better suit discrete HTML pages, such as jQuery. In Figure 3-1 you can see the spectrum of web application types and where AngularJS delivers benefit.
AngularJS excels in single-page applications and especially in complex round-trip applications. For simpler projects, jQuery or a similar alternative is generally a better choice, although nothing prevents you from using AngularJS in all of your projects.
There is a gradual tendency for current web app projects to move toward the single-page application model, and that’s the sweet spot for AngularJS, not just because of the initialization process but because the benefits of using the MVC pattern (which I describe later in this chapter) really start to manifest themselves in larger and more complex projects, which are the ones pushing toward the single-page model.
■ Tip This may seem like circular reasoning, but AngularJS and similar frameworks have arisen because complex web applications are difficult to write and maintain. The problems these projects face led to the development of industrial-strength tools like AngularJS, which then enable the next generation of complex projects. Think of it less as circular reasoning and more of a virtuous circle.
ANGULARJS AND JQUERY
AngularJS and jQuery take different approaches to web app development. jQuery is all about explicitly manipulating the browser’s Document Object Model (DOM) to create an application. The approach that AngularJS takes is to coopt the browser into being the foundation for application development.
jQuery is, without any doubt, a powerful tool—and one I love to use. jQuery is robust and reliable, and you can get results pretty much immediately. I especially like the fluid API and the ease with which you can extend the core jQuery library. If you want more information about jQuery, then see my book Pro jQuery 2.0, which is published by Apress and provides detailed coverage of jQuery, jQuery UI, and jQuery Mobile.
But as much as I love jQuery, it isn’t the right tool for every job any more than AngularJS is. It can be hard to write and manage large applications using jQuery, and thorough unit testing can be a challenge.
One of the reasons I like working with AngularJS is that it builds on the core functionality of jQuery. In fact, AngularJS contains a cut-down version of jQuery called jqLite, which is used when writing custom directives (and which I describe in Chapters 15-17). And, if you add the jQuery to an HTML document, AngularJS will detect it automatically and use jQuery in preference to jqLite, although this is something you rarely need to do.
The main drawback of AngularJS is that there is an up-front investment in development time before you start to see results—something that is common in any MVC-based development. This initial investment is worthwhile, however, for complex apps or those that are likely to require significant revision and maintenance.
So, in short, use jQuery for low-complexity web apps where unit testing isn’t critical and you require immediate results. jQuery is also ideal for enhancing the HTML that is generated by round-trip web apps (where user interactions cause a new HTML document to be loaded) because you can easily apply jQuery without needing to modify the HTML content generated by the server. Use AngularJS for more complex single-page web apps, when you have time for careful design and planning and when you can easily control the HTML generated by the server.
Source: Freeman Adam (2014), Pro AngularJS (Expert’s Voice in Web Development), Apress; 1st ed. edition.