Angular vs AngularJS: Same, But Different?

Angular vs AngularJS: Same, But Different?

It’s a standard practice to keep releasing new versions of a framework to keep up with the ongoing changes in the world, keep the competition on their toes, and simply make developers happier. And hopefully, less stressed.

But no one did it in such a style like Google.

Usually, all we get are improvements, fixes, and new features. But Google thought that wasn’t enough, resulting in the Great Rewrite. The resulting confusion as to what was left of the good old AngularJS and what was new is prevailing to this day. 

And we don’t like confusion. 

Hence, please enjoy this article which describes all the most important differences between AngularJS and Angular. 

AngularJS

Back in 2009, two developers — Miško Hevery and Adam Abrons — were working on their side–project, GetAngular. Its purpose was to make building web applications easy for web designers with no coding background. Once it was proven that 17,000 lines of code could be reduced to just 1,500, Google realized its potential and developed a framework of its own.

AngularJS, whose name was inspired after the sharp angles of the most famous brackets in the programming world (</>), gained popularity as a structural framework that brought dynamism into static web pages. Most importantly, it made the development process easier and faster.

Nobody had to be persuaded for long that AngularJS was the way to go.

Unfortunately, the world sped up, and with it, the further development of JavaScript. Many issues that AngularJS solved became redundant, like making the handling of DOM much more pleasant. Moreover, new technologies kept popping up following the example of the AngularJS framework, making it lose all of its advantages. 

The obvious solution would have been to simply keep improving the AngularJS, but it was deemed a fruitless endeavor. So in 2014, Google decided to rewrite it from scratch. 

Angular

So, let me share a secret with you.

AngularJS used to be called simply Angular. The rewritten version was supposed to be called Angular 2. But since it sparked a big confusion among developers, the old version got a new affix in the form of “JS”, and all the new Angular versions were simply reduced to “Angular”.

The “JS” affix represents the biggest difference between AngularJS and Angular: AngularJS is based on JavaScript, while Angular is based on TypeScript. Where did that change come from?

The short answer — TypeScript is more suitable for large projects, especially those that are worked on by many teams at once. It was developed by Microsoft for exactly that purpose.

The long answer — TypeScript comes with many benefits, besides the general JavaScript ones. Those benefits are:

  • Higher code predictability and readability. In result, it’s easy to involve new people in the project or include different teams to work simultaneously on it. Also, the project itself will be effortless to maintain in the long–run, since it has a much better structure.
  • Bugs are easier to spot. It’s a direct consequence of high readability — if the code is understandable, any mistakes will be clearly visible. 
  • Advances autocompletion and navigation. This speeds up the development process and also lowers the chance of making mistakes.
  • Fast and safe refactoring. There’s no chance of getting your code messed up since TypeScript alerts you automatically of any issues. It also shows you where you need to update your code.
  • Static typing. Since all the checks are run during compilation, many errors are found in advance automatically.

If you’re not a fan of TypeScript, not all hope is lost. Instead, you can use ES5, ES6, or Dart.

The State of Angular and Angular JS in 2021

Nowadays, Angular is considered to be among the most popular frameworks and is a strong competitor to both React and Vue. It has 2.0m to almost 3.0m weekly npm downloads and is used by over 1.8m GitHub Projects

Because of strong support from Google, Angular is considered to be pretty much future–proof. Not only is it heavily used in their products such as Google Cloud Console, Firebase, or Google Analytics, but also for their own internal use. At this point, switching to another technology would be too costly and time–consuming, so rest assured that Angular will stay with us for long.

Angular JS, on the other hand, is currently on Long Term Support (LTS) and its official site encourages users to try out the new version of Angular. We can consider that an official recommendation straight from Google, which should solve the debate of which version is more beneficial.

Should We Still Make The Comparison?

There are still active developers using AngularJS, and more importantly, there are still lots of sites and applications built with its help. And since not everyone has the means and resources for such a giant upgrade, AngularJS can still be found in the trenches. So yes, a comparison of the two is still worth the trouble, especially since people keep confusing the two.

Most Dramatic Differences 

Directives

One of AngularJS’s most characteristic features is the prefix ng which indicates directives. Directives let you add specified behavior to DOM elements, extending the HTML. For example:

  • ng–disabled will specify whether an element is disabled or not, 
  • ng–value will specify the value of an input element, 
  • ng–bind will replace the value of an HTML element with the value specified in the given expression. 

If you find the built–in directives lacking, you can also create custom ones. You can name them however you like.

In Angular projects, you can also find the ng prefix, but don’t be fooled — while those are also directives, they’re used differently. They’re divided into three categories, depending on their purpose:

  1. Component Directives — the most common type that comes with templates, which are a basic building block of Angular,
  2. Attribute Directives — lets you change the appearance or behavior of DOM elements. For example, an ngClass will add or remove CSS classes and ngModel will add two–way data binding to an HTML form element.
  3. Structural Directives — lets you change the design and structure of the DOM layout. For example, ngSwitch will add or remove DOM elements and ngIf will display or remove an element once it meets a certain condition.

Architecture

AngularJS has an MVC architecture. This design pattern’s main purpose is the separation of concern, which divides the application into three parts: 

  1. Model — stores and manages all the data. It’s basically the back–end,
  2. View — represents the data in the form of the user interfaces. It’s basically the front–end,
  3. Controller — controls the data. Once a user interacts with the interface — for example, by clicking on a “show more” button — the controller will request data from the model and update the view.
The Model–View–Controller architecture depicted on a diagram. User interacts with the View, the View informs the Controller, the Controller sends a request or an updated to the Model, the Model notifies the Controller, the Controller updates the View.

Although the Model–View–Controller pattern can be replicated with Angular up to a certain point (with components and directives as controllers and the template as the view) and it also shares some similarities with the MVVM (Model–View–ViewModel), its architecture is component–based — meaning that functional and logical components of the app are kept separate.

Angular uses ngModules to group chunks of code together — be it components, directives, pipes, or services — based on their functionality, like routing or forms, providing a higher level of abstraction. This modular approach heavily enforces reusability and scalability, which is perfect for large–scale projects.

Scopes

In the case of AngularJS, between the aforementioned Controller and the View stands one thing: scope ($scope). 

Scope’s duty is to pass data between all the components in Controller and the View. It resembles the Model in the way that it also serves as a data source. Every object in your project can access it.

Angular doesn’t share data in such a way, just like it doesn’t need the Controller anymore, relying purely on components instead. As a component–based framework should.

How can you share data now, then? There are several ways to do that:

  • You can use shared services (SharedService),
  • You can use input binding (@Input()),
  • You can use @viewChild,
  • You can use local variables,
  • You can use a setter to intercept input property changes,
  • You can also use ngOnChanges to intercept input property changes.

To detect changes, Angular uses ngZone

Dependency Injection

The winning core functionality of AngularJS was dependency injection, a technique that lets objects (clients) be dependent on other objects (services) without clients being aware of the external code (injector). Also, the clients don’t have to know how the services are constructed — they only should use them.

In a real–life example, imagine an employee (client) on their first day at work. In order to do their job, they’re going to need their own hardware and software. But they’re not going to bring any of their own — the employee is going to be dependent on the employer to provide all that. Moreover, the employee doesn’t know what they’re getting and they don’t even care. They’re simply going to use whatever’s given to them. And they won’t ever ask for details.

The benefit of the dependency injection is code reusability and readability, as well as easy testing and maintenance.

Dependency injection is also present in Angular, but with two significant differences:

  • DI Tokens, identifiers used for table lookup, are always strings in AngularJS. In Angular, they can also be strings, but most often they’re classes.
  • In Angular JS, there is exactly one injector. In Angular, there’s a whole hierarchical dependency injection system, with the help of declarations, providers, and constructor functions.

Data Binding

Two–way data binding was yet another popular feature of AngularJS that made a big impact in the tech community. By synchronizing the model (data) with the view (user interface) in two directions, both the view and the model would be automatically updated at once whenever any new changes were made to either. So if you cared about having everything up–to–date at all times, two–way data binding was the best way to go. 

Also, it reduced the amount of code necessary.

Two–Way Data Binding depicted on a diagram. Any change done to the View results in updating the Model and every change done to the Model results in updating the View.

It did come at a cost, though.

The drawback of this process is that each update triggers a series of events in the form of dirty checks and callbacks — each $scope is observed by $watch and once triggered, it runs the $digest cycle, which updates the DOM. The bigger the project, the more watchers will be on the lookout, which can slow down the application tremendously. In inexperienced hands, this can lead to catastrophic results.

One of the solutions to this problem is to avoid using watchers altogether as much as possible. Or to utilize one–way data binding.

One–way data binding was introduced along with Angular. It sacrificed automatic synchronization for better performance since it reduced the number of updates the DOM had to go through. One–way data binding can either bind the data from the component to the DOM or reverse, but never both. 

One–Way Data Binding Depicted on a diagram. Template and the Model merges and updates the View. The View does nothing.

There are many one–way data binding techniques that Angular offers, like class binding, property binding, event binding, and many more.

But Angular didn’t let go of two–way data binding entirely — it’s still useful, especially in projects that require strict data accuracy. It can be done with the help of ngModel.  Don’t get surprised, though, once you notice a different expression syntax — in AngularJS, you use the {{ }} attribute, while for Angular, you use ( ) and [ ].

Routing

If you want to create yet another Single Page Application (SPA) the likes of Facebook — excuse me, Meta — you have no choice but to involve routing. Routing is necessary to create the illusion of switching between different pages, while in truth, the user stays on one. The page doesn’t change, only what’s visible.

To achieve that with AngularJS, you need to use the <a href="https://docs.angularjs.org/api/ngRoute" target="_blank" rel="noreferrer noopener">ngRoute</a> module and $routeProvider service for configuration. It’s the best solution for basic needs, but along with the growth of the project, you can discover some limitations. For example: 

  • You can’t have nested views, as well as multiple named views,
  • You can’t pass data during navigation,
  • If URL changes, you’ve got to manually change URL strings
  • For navigation, you need to remember the route syntax, word for word.
  • When adjusting UI elements, it might be hard to tell whether you are in a state or a parent of a state.

These stem from the fact that AngularJS’ native routing is based on assigning controllers and templates to URL routes. That’s why it loses against a third-party tool, Angular UI Router, which is a self–proclaimed “standard choice for routing”. It solves all of the issues listed above, so if you’re frustrated by them, you can easily switch to the UI Router.

Angular has a different approach to routing. It also comes with its own built–in routing — angular/router package. Because it’s component–based, components can manage their own sub–routes, which removes the need for global router configuration. Also, all routing is static, which consumes less bandwidth and ensures predictability and easy maintenance for large networks.

Command–Line Interface (CLI)

Command–Line Interface tool was introduced with Angular and therefore, you won’t find it in AngularJS. CLI is an amazing tool that significantly saves time and effort throughout the whole project, from setting up your environment to writing code, scaffolding, deployment, testing, and maintenance. CLI will also configure all the necessary dependencies for you — which is especially useful for beginners — while ensuring you’re following the best practices. 

In short, CLI does all the heavy lifting for you, allowing you to focus on what matters the most — the code itself. 

While the Angular CLI is optional, it’s strongly recommended.

Mobile Support

AngularJS doesn’t offer mobile support.

Angular does.

The difference is the result of different times — when AngularJS was first introduced, mobile support wasn’t as needed. Now, it’s a necessity.

The Angular framework handles this challenge just fine. Ever since its inception, it was possible to build mobile apps with the help of NativeScript. If you’re a fan of Ionic, you could use it with versions Angular 6 and up.

Conclusion

While AngularJS did save us from the horrors of JQuery’s spaghetti code and changed much in the development world, it’s time to slowly let it go. Not because it’s bad and useless — but because there’s no longer the support necessary to keep it thriving. But for those who fell in love with AngularJS, don’t despair. Angular is a worthy successor which goes head–to–head with the most popular frameworks nowadays. 

Angular vs AngularJS Table Comparison. AngularJS: developed by Misko Hevert and Adam Abrons in 2009, is on Long–Term Support, written in JavaScript, has a pack of Directives, MVC architecture, uses scopes and controllers, has Dependency Injection, Two–Way Data Binding, built–in ngRoute module (although Angular Universalis recommended). Angular: developed by Google in 2014 and still supported by Google, based on TypeScript, has standard directives, is component–based, uses hierarchy of components, has Hierarchical Dependency Injection System, Two– and One–Way Data Binding, has a built–in @angular/router package, has a Command–Line Interface, supports mobile.

Looking for a reliable software development team?

We use cookies

We use cookies to make sure your website experience is as easy and as personal as possible. By accepting, you’re allowing them to do their job. Change your cookie preferences if you wish to.

Why? To analyze our visitor data, improve our website and show personalized content to our users. We want to give you a better experience of Massive Pixel Creation. Are you fine with this?