If you have used Wijmo 3, you are probably familiar and comfortable with jQuery. But you may not yet understand the high-level differences between jQuery and AngularJS, or the mind set behind using AngularJS and how it came into being. I will walk you through these differences and introduce you to the AngularJS mindset.

HTML is great for declaring static data. As the web stack matured, ( that is, the combination of OS, web servers, database servers, and programming languages ) people needed to be able to dynamically change that static page (HTML).

jQuery and DOM
jQuery and DOM came along to help us build applications on the web instead of serving static content from some server side application such as PHP or Ruby. Wijmo3 followed the jQuery implementation that uses selectors ( talked about below ) that are used to search through your markup ( the Document Object Model ) and identify unique elements on the page and then bind and register event handles to them all done via Client-Side:
1. search through the markup (the Document Object Model , or DOM)
2. identify unique elements on the page
3. bind and register event handlers to the elements
This method lets us tell the compiler what to do step by step (Imperative). When the event triggers, the code executes to update or change the HTML blocks that comprise the DOM elements

As moving work to the client side became more popular, developers needed a way to communicate from client to server without doing a full postback. This is where AJAX came into play. Using AJAX, DOM, jQuery, and HTML, you had a lot of power and flexibility when building web apps.
This worked for many years until web apps needed to become more like desktop apps, that is, they had to become fully functional. Building a fully functional app on the web became very cumbersome and complex with the existing tools.

Single-Page Application (SPA) frameworks
People started looking into creating a SPA framework. AngularJS is a structural framework for dynamic web apps. It is not a complete client-side solution, but it does a lot.
• It takes care of all of the DOM and AJAX code that you once had to code by hand.
• It lets you use HTML as your template language.
• It lets you extend the HTML syntax to express your application’s components clearly.
To use AngularJS, it helps if you completely change your mindset about what the markup is. Think about “views” rather than DOM elements. Views consist of declarative HTML that contains AngularJS directives, which we will talk about later. These directives are very important, because they allow you to create event handlers behind the scenes, ultimately giving you dynamic data-binding.

Model View ViewModel (MVVM)
The implementation is as follows: Views are tied to Models.
Views are projections of the model. You can think of the view as the scaffolding of a house, and the look and feel of the house is dependent on the furniture and paint (Model) you use. The views that project the models update automatically for us with dynamic data-binding, virtually eliminating the need for jQuery selections and DOM manipulation.
A lot of AngularJS developers are getting away from jQuery. Bootstrap is the last remaining reason to maintain a dependency on jQuery.
The AngularJS View offers a declarative method that lets you write code that describes what you want, but not necessarily how to do it. I cover this in more depth in the Data Binding section near the end of this article.
Before we dive any deeper, let me define some terms. (This is from the AngularJS documentation.)
Template- HTML with additional markup
Directives- extend HTML with custom attributes and elements
Model- the data shown to the user in the view and with which the user interacts
Scope- context where the model is stored so that controllers, directives and expressions can access it
Expressions- access variables and functions from the scope
Compiler- parses the template and instantiates directives and expressions
Filter- formats the value of an expression for display to the user
View- what the user sees (the DOM)
Data Binding- sync data between the model and the view
Controller- the business logic behind views
Dependency Injection - Creates and wires objects and functions
Injector- dependency injection container
Module- a container for the different parts of an app including controllers, services, filters, directives which configures the Injector
Service- reusable business logic independent of views

The old mindset might tempt you to design your page and then change it with DOM manipulations.
In Angular, an application only accesses the DOM from within directives. This is important because artifacts that access the DOM are hard to test. If you need to access the DOM directly, write a custom directive for it. See the image to the left.

jQuery promotes the concept of unobtrusive JavaScript. This means separating your JavaScript from the structure of your page (the HTML). This requires you to jump through several hoops.
• Keep JS modules independent of other modules.
• Make all content available even if the JavaScript code does not run successfully, a concept known as degrading gracefully.
• Improve the accessibility of the HTML, never degrading it.
By contrast, AngularJS uses controllers and directives to remove the behavior from the structure (View) and employs services and filters to help separate and organize your code base. AngularJS documentation explains it this way:
“Angular is built around the belief that declarative code is better than imperative when it comes to building UIs and wiring software components together… By declaratively describing how the UI should change as your application state changes, you are freed from low level DOM manipulation tasks.”

Getters and Setters
In jQuery, we create a DOM element and then make it do something. So in Wijmo 3, we create our DOM element (a grid or something) then use setters and getters to change the DOM to the desired behavior. More information on this concept is in the Wijmo help: http://wijmo.com/docs/wijmo/#GettingAndSettingOptions.html
The web has become much more complex over the years, so this simple concept has become cumbersome and difficult to maintain. With AngularJS, you do it this way.
1. Start with what you want to accomplish.
2. Build your application.
3. Design the presentation layer or the view.
Notice that we do not augment jQuery with AngularJS. The mindset is not that you can build a jQuery site, and then add AngularJS controllers and directives later. In fact, developers fluent in AngularJS recommend that you not use jQuery at all in your AngularJS application, at least while you are learning the framework. Think in terms of the architecture.

Complexity, tamed
As the complexity of the web increases and as web applications are not being required to behave more like a traditional desktop application, we need to adjust our mindset. Rather than writing very lengthy static markup, we want to divide our web applications into individual, extensible, testable components.
Think of the view as the official record. In a jQuery application, it is the view that we change programmatically. The view could be a table with standard markup. Using Wijmo 3, we select that DOM element and update it with the wijgrid library, ultimately updating the DOM as shown in the code snippet below.

<table id="”wijGrid”" class="”wijmo”"></table>
$(function () {
var options; // Type: wijmo.grid.wijgrid.options

When we look at the view in a jQuery application, it is not obvious in the markup that the HTML table element is a WijGrid. You must look in the script to see the ID to which WijGrid is assigned. Also, if the structure of the table element changes, it could disrupt WijGrid at run time.
In AngularJS however, the view is the official record. The two implementations bring about the same result: a grid. But in the markup for the AngularJS view, it is obvious that this element is a Wijmo 5 FlexGrid.

The goal of any software development project is to produce something that works as requested in the specifications. The challenge is to build an application that not only meets the specifications, but that also performs well, and perhaps most importantly, is maintainable.
The software world has a high turnover rate for developers, as they move on to new projects or new companies. When you architect your application using AngularJS thinking, the next developer on the project can look at the view and quickly figure out what is going on without examining any code.
Remember that the view is our official record. With AngularJS thinking, we never change the DOM outside of the directives that we apply in the view. This way, our intent is clear. Quote from StackOverflow:
“Don’t design, and then mark up. You must architect, and then design.”

Data binding, one way and two way
One of the coolest features of jQuery is the ability to update data on the page based on user interactions. For example, if we have a shopping cart and a user updates the Quantity, we can use jQuery and DOM manipulation to update the Total field for the user without refreshing the page, saving valuable bandwidth.
In jQuery, you have an event listener that runs scripts to perform DOM updates in response to events. This requires each DOM element to have a unique ID of which the developer must be aware. When you think of the number of IDs there are, one to correspond with every element on the page, you can see how this makes bringing in new developers very difficult.
The beauty of AngularJS is that it updates the data for you in the View, freeing you from the need to keep track of a unique ID for each DOM element.
In jQuery the DOM is kind of like the Model.
In AngularJS, we have a separate model layer that we can change independently of the view. This enhances testability. The view acts as the official record of what is supposed to happen, and the model represents your data. The ViewModel is a service layer that performs reusable tasks. You do DOM manipulation and augment your view with directives, and you glue it all together with controllers using scope.

Scope is nothing more than an object that glues together the view and the controller. Our controllers will hold the Models data that we need to pass to the applications view. Scopes are basically going to mimic the DOM structure of the application.

In AngularJS, a controller is a JavaScript constructor function that is used to augment the Angular Scope. Controllers are regular JavaScript Objects. We can use this to control the data of our AngularJS application. The best practices here would include setting the initial scope and adding behavior to that scope. We do not want to use a controller to manipulate DOM, Format input, filter output, share code or state across controllers, and finally managing the life cycle.