A (really) quick explanation of AngularJS

If this article feels basic to you, its because it was meant to help explain the JavaScript library to people who may not inherently be JavaScript programmers, let alone programmers at all; so feel free to to skim.  I want to note that I intentionally used inconsistent capitalization of terms.

AngularJS is, at its base, a client side, JavaScript-based templating language. Templating languages provide programmers with a way to create templates in HTML with additional element components that provide extra functionality, data binding, and logic. After that, Angular is a pretty dependable and solid Model-View-View-Model JavaScript platform.

AngularJS takes typical HTML elements and can encapsulate them as well with logical code that executes based on a particular context of web page content. This encapsulation of a block of HTML is an Angular Controller.

Each controller has discrete responsibilities over the HTML elements and content, including event handling, data binding, and basic model manipulation needed only for the UI, for instance observing some data and its associated data type and putting an appropriate currency symbol to it. Additionally, a controller can contain many controllers, with awareness of one another in code. The "Parent" controller can send and receive data from children, grandchildren, and so on, but should generally only be responsible for its discrete set of HTML, not any of the elements contained under other controllers.

When using Angular, you will find that it leverages JQuery without you. There is a way to handle HTML elements with greater customization when you need it within Angular, and these are Directives. Directive can provide reusable bits of HTML Element manipulations where you might have used native JQuery to do the job, and you cannot find a way to do it using Angular.

Angular provides element access to specific elements by Id and Class like JQuery, using a simple syntax. The complications with any directive is that every directive exists somewhere within the context of an Angular Controller, and many times, directives need extra special handling when doing garbage handling, (stopping of intervals, timeouts, watches, scope observables), and then even more extra, extra special handling of JQuery event bindings. This is because Angular does some clever, hard-to-wrap-your-head-around stuff with data binding and HTML element updating that can cause someone to go bonkers when first using it if they do not understand how it works. So let us get into that and come back again to directives.

The stuff Angular does is the digest loop or cycle. It is constantly looping, (you can make this asynchronous with a few lines), and applies changes in data to elements based on data binding on each loop. Part of how that works includes creating a queuing stack of data to handle over time, so when HTML element changes occur outside of the digest loop, several errors will occur complaining about doing things outside of the digest loop. Therefore, do not use JQuery natively in Angular or you will run into these problems; the caveat to that being, you can do things natively in JQuery, but you must subscribe them to the digest loop and apply them asynchronously with manual code. Mostly it is just a pain to manage and maintain over time, so try to avoid it. The digest loop stacks what it wants to apply on a pass, so it is possible to add code that makes this all just fail and get out of sync. This is similar to breaking anything that runs on timed events.

So back to the directives; directives may exist in the context of an Angular Controller, they do not necessarily exist in the context of the digest loop. As well, when destroying a controller’s HTML element block via something like JQuery’s remove function, it does not inherently trigger Angular digest destroy events on child directives contained in the controller. This means that when handling components a developer must be wary of the code written by others and handle this code manually and with great caution.

When dealing with data handling and communication between controllers that may be unrelated, Angular has services. Services do not tie to a specific piece of HTML content. Instead, services remain relevant to sets of data and data manipulation. Services can keep track of navigational state. Services should be doing all the heaviest lifting in an Angular application. The best thing about an Angular Service is that a developer can reference a service in two places and use it to communicate between unrelated controllers, effectively bridging functionality and making the UI compartmentalization responsible appropriately.

While this is not every little bit and piece of AngularJS, it is an overview to help explain how it interacts and functions, and what the different pieces mean to do. Angular is a particularly great JavaScript library when it comes to using it with a stable backend platform, and has a lot of community and formal development support as they expand release new versions and implementations for better leveraging of DOM virtualization.

As a competent library, ReactJS is taking a lead of DOM virtualization, but suffers from the same kind of maturity deficits that the NodeJS platform does as a server. I am a big fan of using, exposing, and understanding the new code libraries coming out (for instance Ionic), but also understanding that the longer a library is around, the better managed the code base becomes, and the commitment to evolve that code base are all important parts of selecting a good platform to use for a particular solution. The things that AngularJS does not have now “out-of-the-box” that other platforms do is markedly superseded by the maturity of the code base and commitment to improving it that exists. Every new exciting technology when it comes out for programming is a fad until it has the chance to really mature, evolve, and gain greater audience acceptance. Being an “early adopter” is in the nature of technophiles, but do not rush into trying to sell a technology as enterprise-ready and a silver bullet for the marketplace. No technology I have seen ever meets that criteria.