Hire the Top 3% of Freelance AngularJS Developers

Toptal is a marketplace for the best AngularJS developers, engineers, programmers, coders, architects, and consultants. Top companies and start-ups choose Toptal AngularJS freelancers for their mission-critical web development projects.

No-Risk Trial, Pay Only If Satisfied.

Clients Rate Toptal AngularJS Developers4.4 / 5.0on average across 675 reviews as of May 30, 2023

Hire Freelance AngularJS Developers and Engineers

Muhammed Mutahr

Freelance AngularJS Developer

United StatesToptal Member Since June 9, 2018

Muhammad is a senior software engineer with several years of experience in industries ranging from the public education sector (WSU), privately owned healthcare companies (Meridian), and public Fortune 500 companies in the automotive industry (GM & AAM). Throughout his career, he’s designed web apps in HTML/CSS, developed client-side apps using JavaScript frameworks (Angular/Ionic), and used Java and C# to develop robust server-side apps.

Show More

Congwen Ma

Freelance AngularJS Developer

United StatesToptal Member Since March 6, 2018

Congwen is a dedicated web developer specializing in developing full-stack web applications using practical frameworks. He's passionate about solving problems for others. A good solution to Congwen usually requires a dose of creativity that requires more effort to adapt and perfect.

Show More

Ryan J. Peterson

Freelance AngularJS Developer

United StatesToptal Member Since November 25, 2013

Ryan is a top architect, entrepreneur, and developer. He boasts a proven competency in building cloud-scalable, extensible software and systems. He writes code that can be maintained and expanded over time as business systems and requirements adapt to market demands or pivots in core business direction.

Show More

Patrick Keenum

Freelance AngularJS Developer

United StatesToptal Member Since July 6, 2018

Patrick is a senior full-stack engineer with more than 10 years of experience developing beautiful, reliable, and scalable products. He is passionate about bringing ideas from conception to launch, working with clients of all levels of technical acumen, and building products that help companies grow.

Show More

Jonathan Serle

Freelance AngularJS Developer

IsraelToptal Member Since July 24, 2014

Jonathan is a highly motivated developer and architect with a unique edge: his communication skills and ability to understand software projects from the top-down. His experience has taken him through a wide range of development environments, from the startup to the Fortune 500.

Show More

Bryce Ott

Freelance AngularJS Developer

United StatesToptal Member Since June 23, 2014

With almost 20 years working as an engineer, architect, director, vice president, and CTO, Bryce brings a deep understanding of enterprise software, management, and technical strategy to any project. His specialties include Amazon Web Services, real-time systems, business intelligence, big data, enterprise web apps, scalability, education, and open-source software.

Show More

Dennis Ippel

Freelance AngularJS Developer

NetherlandsToptal Member Since March 14, 2014

A creative technology expert with 15+ years experience, Dennis has worked for over eight years for top ad agencies and production companies in London, UK. He makes high-end websites, digital installations and mobile apps, and he specializes in 3D, VR, and AR. He has worked for clients such as Nike, Ferrari, Fiat, Mini, EA, Disney, Unilever, and Intel, and he is the creator and lead developer of Rajawali, an open-source 3D framework for Android.

Show More

Zoran Melis

Freelance AngularJS Developer

CroatiaToptal Member Since December 6, 2014

Zoran is a software engineer with over ten years of professional experience with a wide range of technologies. He has worked with C/C++, Python, Go, JavaScript, Java, and more. Currently focusing on full-stack, scalable applications development, he has been a part of teams of all sizes in environments ranging from small private companies to Google.

Show More

Rashid Wakileh

Freelance AngularJS Developer

United StatesToptal Member Since November 17, 2014

Rashid is a passionate lead front-end engineer. He is an expert in test-driven development, and has extensive experience in leading teams to create software solutions. He enjoys using JavaScript frameworks and thoroughly testing all aspects of his code.

Show More

Sign up now to see more profiles.

Start Hiring
Frequently paired together

Get Additional Expertise

Our clients frequently pair these additional services with our freelance AngularJS Developers.

A Hiring Guide

Guide to Hiring a Great AngularJS Developer

Although AngularJS has a gentle, initial learning curve, the powerful and flexible framework relies a lot on developers’ skills and understanding of the framework to produce well-engineered and maintainable applications. This hiring guide offers a set of insightful questions to help you identify amazing AngularJS developers who are experts in their field.

Read Hiring Guide

AngularJS Hiring Resources

Toptal in the press

... allows corporations to quickly assemble teams that have the right skills for specific projects.

Despite accelerating demand for coders, Toptal prides itself on almost Ivy League-level vetting.

Our clients
Building a cross-platform app to be used worldwide
Thierry Jakicevic
Building a cross-platform app to be used worldwide

Tripcents wouldn't exist without Toptal. Toptal Projects enabled us to rapidly develop our foundation with a product manager, lead developer, and senior designer. In just over 60 days we went from concept to Alpha. The speed, knowledge, expertise, and flexibility is second to none. The Toptal team were as part of tripcents as any in-house team member of tripcents. They contributed and took ownership of the development just like everyone else. We will continue to use Toptal. As a start up, they are our secret weapon.

Brantley Pace, CEO & Co-Founder


I am more than pleased with our experience with Toptal. The professional I got to work with was on the phone with me within a couple of hours. I knew after discussing my project with him that he was the candidate I wanted. I hired him immediately and he wasted no time in getting to my project, even going the extra mile by adding some great design elements that enhanced our overall look.

Paul Fenley, Director

K Dunn & Associates

The developers I was paired with were incredible -- smart, driven, and responsive. It used to be hard to find quality engineers and consultants. Now it isn't.

Ryan Rockefeller, CEO


Toptal understood our project needs immediately. We were matched with an exceptional freelancer from Argentina who, from Day 1, immersed himself in our industry, blended seamlessly with our team, understood our vision, and produced top-notch results. Toptal makes connecting with superior developers and programmers very easy.

Jason Kulik, Co-Founder


As a small company with limited resources we can't afford to make expensive mistakes. Toptal provided us with an experienced programmer who was able to hit the ground running and begin contributing immediately. It has been a great experience and one we'd repeat again in a heartbeat.

Stuart Pocknee , Principal

Site Specific Software Solutions

We used Toptal to hire a developer with extensive Amazon Web Services experience. We interviewed four candidates, one of which turned out to be a great fit for our requirements. The process was quick and effective.

Abner Guzmán Rivera, CTO and Chief Scientist

Photo Kharma

Sergio was an awesome developer to work with. Top notch, responsive, and got the work done efficiently.

Dennis Baldwin, Chief Technologist and Co-Founder


Working with Marcin is a joy. He is competent, professional, flexible, and extremely quick to understand what is required and how to implement it.

André Fischer, CTO


We needed a expert engineer who could start on our project immediately. Simanas exceeded our expectations with his work. Not having to interview and chase down an expert developer was an excellent time-saver and made everyone feel more comfortable with our choice to switch platforms to utilize a more robust language. Toptal made the process easy and convenient. Toptal is now the first place we look for expert-level help.

Derek Minor, Senior VP of Web Development

Networld Media Group

Toptal's developers and architects have been both very professional and easy to work with. The solution they produced was fairly priced and top quality, reducing our time to launch. Thanks again, Toptal.

Jeremy Wessels, CEO


We had a great experience with Toptal. They paired us with the perfect developer for our application and made the process very easy. It was also easy to extend beyond the initial time frame, and we were able to keep the same contractor throughout our project. We definitely recommend Toptal for finding high quality talent quickly and seamlessly.

Ryan Morrissey, CTO

Applied Business Technologies, LLC

I'm incredibly impressed with Toptal. Our developer communicates with me every day, and is a very powerful coder. He's a true professional and his work is just excellent. 5 stars for Toptal.

Pietro Casoar, CEO

Ronin Play Pty Ltd

Working with Toptal has been a great experience. Prior to using them, I had spent quite some time interviewing other freelancers and wasn't finding what I needed. After engaging with Toptal, they matched me up with the perfect developer in a matter of days. The developer I'm working with not only delivers quality code, but he also makes suggestions on things that I hadn't thought of. It's clear to me that Amaury knows what he is doing. Highly recommended!

George Cheng, CEO

Bulavard, Inc.

As a Toptal qualified front-end developer, I also run my own consulting practice. When clients come to me for help filling key roles on their team, Toptal is the only place I feel comfortable recommending. Toptal's entire candidate pool is the best of the best. Toptal is the best value for money I've found in nearly half a decade of professional online work.

Ethan Brooks, CTO

Langlotz Patent & Trademark Works, Inc.

In Higgle's early days, we needed the best-in-class developers, at affordable rates, in a timely fashion. Toptal delivered!

Lara Aldag, CEO


Toptal makes finding a candidate extremely easy and gives you peace-of-mind that they have the skills to deliver. I would definitely recommend their services to anyone looking for highly-skilled developers.

Michael Gluckman, Data Manager


Toptal’s ability to rapidly match our project with the best developers was just superb. The developers have become part of our team, and I’m amazed at the level of professional commitment each of them has demonstrated. For those looking to work remotely with the best engineers, look no further than Toptal.

Laurent Alis, Founder


Toptal makes finding qualified engineers a breeze. We needed an experienced ASP.NET MVC architect to guide the development of our start-up app, and Toptal had three great candidates for us in less than a week. After making our selection, the engineer was online immediately and hit the ground running. It was so much faster and easier than having to discover and vet candidates ourselves.

Jeff Kelly, Co-Founder

Concerted Solutions

We needed some short-term work in Scala, and Toptal found us a great developer within 24 hours. This simply would not have been possible via any other platform.

Franco Arda, Co-Founder

Toptal offers a no-compromise solution to businesses undergoing rapid development and scale. Every engineer we've contracted through Toptal has quickly integrated into our team and held their work to the highest standard of quality while maintaining blazing development speed.

Greg Kimball, Co-Founder

How to Hire AngularJS Developers through Toptal


Talk to One of Our Industry Experts

A Toptal director of engineering will work with you to understand your goals, technical needs, and team dynamics.

Work With Hand-Selected Talent

Within days, we'll introduce you to the right AngularJS developer for your project. Average time to match is under 24 hours.

The Right Fit, Guaranteed

Work with your new AngularJS developer for a trial period (pay only if satisfied), ensuring they're the right fit before starting the engagement.

Find Experts With Related Skills

Access a vast pool of skilled developers in our talent network and hire the top 3% within just 48 hours.


  • How are Toptal AngularJS developers different?

    At Toptal, we thoroughly screen our AngularJS developers to ensure we only match you with talent of the highest caliber. Of the more than 200,000 people who apply to join the Toptal network each year, fewer than 3% make the cut. You'll work with engineering experts (never generalized recruiters or HR reps) to understand your goals, technical needs, and team dynamics. The end result: expert vetted talent from our network, custom matched to fit your business needs.

  • Can I hire AngularJS developers in less than 48 hours through Toptal?

    Depending on availability and how fast you can progress, you could start working with an AngularJS developer within 48 hours of signing up.

  • What is the no-risk trial period for Toptal AngularJS developers?

    We make sure that each engagement between you and your AngularJS developer begins with a trial period of up to two weeks. This means that you have time to confirm the engagement will be successful. If you're completely satisfied with the results, we'll bill you for the time and continue the engagement for as long as you'd like. If you're not completely satisfied, you won't be billed. From there, we can either part ways, or we can provide you with another expert who may be a better fit and with whom we will begin a second, no-risk trial.


How to Hire a Great AngularJS Developer

AngularJS is the framework of choice for multiple high-end web applications. The reason many teams choose this technology is because it is flexible and powerful, seems to evolve in the right direction, has a great community, and has countless extensions and integrations.

There are also many Angular developers. While starting out with Angular is fun and building small single page applications is not very difficult, maintaining even a small app can be tough. Until today, a large number of good practices and advanced techniques have been documented and discussed, and some high-quality standards have emerged.

Our hiring guide will help you find full-time and part-time AngularJS development experts who strive to follow that high-quality approach. It is the one that results in great applications which attract clients. In this guide, we will cover concepts relevant to scopes, the digest loop, services, testing, and more.

Working with Scopes

Scopes are the data-model of Angular apps. They are the single source of truth in the app development process, and should be bound and handled with the greatest caution. There are many caveats in dealing with scopes. We will describe a few significant ones below.

Q: How does scope inheritance work in AngularJS? Describe the various ways for data to be passed into a scope.

Scope inheritance in AngularJS is prototypal for child scopes, but not for isolated scopes. Core directives, which create a new scope, use the child scope option. Those scopes have access to the models set on the parent scope. Accessing parent scope models works seamlessly for objects, but when trying to write to a primitive model (e.g. a string), a new model will be created on the child scope. The model on parent scope will be masked, or shadowed.

When building custom directives, it is possible to create an isolated scope. Isolated scopes don’t have direct access to their parent’s models. Still, bindings can be set manually by specifying them in the directive’s scope property object. In such a case, data can be passed into the directive through HTML attributes. That supports both two-way and one-way bindings, and also expression bindings.

Directives also have the ability to transclude scope onto contained elements. When using transclusion manually, it is possible to create a cloned scope - one that would keep all the properties of the parents, but would lose all the bindings. That feature is not very well documented.

At this point, it seems very important to note that it is possible to traverse scopes, in all directions. Every scope has a $parent property (“null” for root scope), and also \(childHead,\)childTail, \(prevSibling, and\)nextSibling properties. It is possible to communicate between scopes using those properties, though it may be difficult and also not a good practice.

Q: What exactly are controllers? What is their lifecycle and relation to the scope?

Controllers are classes, that is, constructor functions, which are bound to a scope AND a section of HTML through the directive “ng-controller”, routing, or through a directive. Setting a controller creates a new scope (child scope). The controller’s purpose is to set up the initial state of the scope and also manipulate it by adding behaviour, setting watches, event listeners, etc.

Even though at first controllers may seem like the primary ground of operation in AngularJS, once the dedicated developer truly understands the purpose of scopes in AngularJS, their use of controllers will minify. It is not optimal to perform calculations directly on scope models, as those might be watched, and in effect may trigger and slow down the digest phase. The motto that transcends MVC frameworks — “keep controllers thin” — applies very well to AngularJS.

Controllers are bound to their scope, and so is their lifecycle. Once a new scope is created, the $compile service sets up initial watches on the scope. At that point, the scope can be manipulated, models on the scope can be created, mutated or destroyed, new watches and listeners can be set. For the changes to take effect, a digest phase needs to be triggered. That allows for observing and responding to model mutation (which is a reaction, thus the next step). The scope’s lifecycle ends with its destruction. Additional events are fired on that occasion. This usually is also the end of the interest for the controller, though it may live on as JavaScript closures do.

Q: Please explain what “.$eval()” and “$parse()” are used for in AngularJS.

“.$eval()” is a simple scope method which takes an expression (and optionally locals) and then executes it against the current scope, using “$parse()”.

The service “$parse()” is where the magic happens. It takes an Angular expression and returns a function, which takes two arguments: “context” and “locals”. The latter is used for overriding variables set in the context. The context is the key part.

A good helper question to this one would be: did you, the developer, ever wonder why core Angular directives take only the model name set on the scope? E.g.: ‘<button ng-click=“foo = 5”>Sets the value of scope model foo to 5</button>`. In the directive, the scope object is implicit. What really happens: the expression passed to ng-click is parsed, which returns a function, which is then executed with the current scope passed in as context.

$ = 3;
var parseFn = $parse(‘foo = 5’);
$; // returns 5

or shorter:

$ = 3;
$scope.$eval(‘foo = 5’);
$; // returns 5

There are many use cases for $parse, as it is a really great service. A particularly useful one is to check for deep nested properties of objects when there is no assurance that at any level the property is not null.


… will return undefined if is undefined. If one would try to access “quux” directly, JavaScript would throw an exception.

Another more specific use case is to allow users to declare variables and assign values to them, such as in text input fields, and then reuse the variables in other input fields (and more). An example of that might be a calculator or notepad application. To keep it safe, scope could be used as the context for the variables. “.$eval()” and “$parse()” would play key roles there.

Working with the Digest Loop

The digest loop is used to keep the DOM in sync with the models set on the scope. In Angular, running into issues around the digest cycle is common. A deep understanding of the digest cycle is much less common.

The developer being interviewed should be familiar with what the digest cycle is and how it works. The requirement for that knowledge will emerge sooner than later when building a large application. The questions below will help you assess their level of proficiency.

Q: How does AngularJS know when to perform dirty checking and update DOM output?

The answer is short — when it is told to do so. The point is, there is no polling mechanism that would trigger dirty checking automatically. Core AngularJS directives, services, and methods usually set up watches, or fire the digest cycle explicitly. That process is executed internally, it is not exposed, and may not be obvious to the developers. In fact, there are articles which contradict the facts, falsely stating that there is a constant heartbeat in AngularJS. There is no such thing.

Manipulating scope models using non-core functionality requires the developers to manually trigger the digest cycle. In most cases, that is done by using the scope method “.$apply()”, which triggers a digest on the root scope. That phase propagates down to every child scope.

Without anything triggering digest, the dirty checking will not happen. The callbacks to watches will not be fired, and DOM output will not be updated.

Q: What is the difference between “.$apply()” and “.$applyAsync()”? Why would you choose one over the other?

The main difference between them is that the latter happens on a 0 timeout. The actual delay is about 10ms. Consecutive “.$applyAsync()” calls cancel the previous timeouts. The point is that for multiple “.$applyAsync()” calls, there will only be a single digest trigger, and not one for every call. That would be the case with the regular “.$apply()”.

At this point, the reason should be obvious — the main concern is performance. Applying a certain change to your scope, only to redo or change it again in a fraction of a second can often be redundant. $applyAsync() helps avoid that.

Q: What is the difference between “.$digest()” and “.$apply()”? Why would you ever call “.$digest()” on a scope?

There are a few differences. First of all, “.$apply()” takes an argument, an expression, and evaluates it against the current scope. “.$digest()” does not take any arguments.

Secondly, “.$apply()” calls “.$digest()” on root scope. That digest will propagate down through every child scope — it will eventually affect every scope in the application. Calling “.$digest()” directly on a scope does not affect any scope that is higher in the hierarchy. That means that any watches set on parent scopes will not be evaluated.

Again, the reason why a developer might want to call “.$digest()” instead of “.$apply()” is performance. It can be safely done when working with isolated components, e.g. widgets, that don’t communicate with the rest of the app. More precisely — when it is known that no models set on parent scopes will be affected.

However, it is not a common practice. As a rule of thumb, the use of “.$apply()” is preferred and expected.


Services in Angular are where the business logic is kept. Even in core Angular, there is more than one (even more than two) supported ways of creating services. The style guides have a lot to say about optimal approaches in dealing with services. The engineer you consider hiring should too!

Ranging from correctly applying patterns, through communication, persistent models, to handling client-side data stores, the services in Angular usually consist of advanced, complex methods that should be reusable across the application. The business logic itself requires proficiency in JavaScript. Binding it to Angular demands from the developer to comprehend what types of structures he or she intend to use.

Q: Please explain when to use a service, when to use a factory, and when to use a provider.

The three are almost the same internally. When initialized, a service returns a factory, which in turn returns a provider.

The difference between services and factories lies in how they are declared and initialized. Services are constructor functions — they are instantiated, that is, when first loaded a “new” instance is created. The consequence is that when declaring a service, all its methods are defined as properties of “this”. Factories, on the other hand, should return an object literal.

There is an advantage to knowingly using providers, as they can be configured before all services are available, in “config()” blocks. When declaring a provider named e.g. “api”, Angular registers two injectables: “api” and “apiProvider”.

function api() {
  this._apiUrl = '';

  this.$get = function () {
    var that = this;
    var hostObject = {
      printApiUrl: function () {
        return ‘api address is ' + that._apiUrl;
    return hostObject;

  .provider(‘api’, api);

  .config(function (apiProvider) {
    apiProvider._apiUrl = ‘';
  .controller(’NewCtrl’, function ($scope, api) {
    $scope.apiName = api.printApiUrl();

Q: What are services in AngularJS? When are they initialized?

Angular services are singletons — there is only one instance available during an app’s lifecycle. Angular lazy loads its modules, so all services become available after they were injected into a “run()” block, or into another module (which of course needs to be initialized too).

Providers become available prior to that, as they can be readily used in “config()” blocks. Their core functionality is still unavailable at that time. It can be manipulated though.

Q: What means of HTTP communication are available in AngularJS? Describe and explain the differences between at least two.

The two core services for Angular that deal with XHRs are “$http” and “$resource”. The latter actually needs explicit installation, while “$http” is readily available.

“$http” is a low level module, which already provides a lot of functionality, but using it with a RESTful API might lead to duplication of code, and is somewhat primitive. The module can be used for communicating using XML HTTP Requests or JSONP. It is rather simple to use.

“$resource”, on the other hand, is a high level service built on top of “$http”, designed for communicating with RESTful APIs. It was built to deal with standard server-side resources. It provides a rich api, allowing the declaration and reuse of multiple defined parameters, even ones which can be used alternatively on the same path level. It provides standard actions (except for “update”, but that one is described as an example in the module’s documentation). It also allows new actions to be defined.

There is a common ground for both “$http” and “$resource” — the “$httpInterceptors”. More about those in the next section.

A third alternative is Restangular. Restangular is a contributed module, and was built as a substitute for $resolve. It has a different, rich API, operates primarily on promises, and is supposed to have an easier syntax. In fact, developers consider $resource to be somewhat confusing. Restangular allows you to generate new types of requests on the fly. It is a fairly popular module. On the other hand, there haven’t been many commits lately.


AngularJS has a lot of power. To be able to use it, the developer often needs to dig in to documentations, techniques described on blogs and forums, and also into the source code. After spending some time building client-side applications using AngularJS, the engineers broaden their view on AngularJS. New paths open up as a result of searching for optimal approaches. A veteran developer should be at least somewhat familiar with the cases described in the questions and answers below. They all relate to advanced aspects of using Angular. The developer’s fluency in discussing them may indicate to you their thorough understanding of the framework.

Q: What is transclusion, in relation to directives? Are there ways to manually control transclusion?

Transclusion is a property of directives, which allows them to contain and access elements, which are declared within them in HTML hierarchy, but which are not declared in their templates.

An example of that would be a lightweight directive, which when applied to an element creates a new scope for it, applied also to all contained elements.

  <p>PARENT SCOPE:</p>
  <p>foo: {{ foo }}</p> <!-- assuming foo === 1 -->
  <p>bar: {{ bar.hotNumber }}</p> <!-- assuming bar.hotNumber === 1 -->
  <div light-scope>
    <p>CHILD SCOPE</p>
    <p>foo: {{ foo }}</p>
    <p>bar: {{ bar.hotNumber }}</p>
    <button ng-click="foo = 2">change foo</button>
    <button ng-click="bar.hotNumber = 3">change bar.hotNumber</button>

this can be a view template — notice that the content of the “div” to which the directive “light-scope” is bound is not part of the directive’s template.

function lightScope() {

  function postLink(scope, element, attrs, controller, transclude) {
    // allow to set isolated scope,
    // but not by default
    var isolateScope = false;
    if (attrs.lightScope === 'isolated') {
      isolateScope = true;

    // there are two scopes: 
    // one created by the directive in the definition, through `scope: true`, and 
    // another one created just above...    
    var newChildScope = scope.$parent.$new(isolateScope);

    transclude(newChildScope, function (clone) {

    // ... so the second scope needs to be destroyed manually.
    scope.$on('$destroy', function () {


  var directive = {
    link: postLink,
    restrict: 'E',
    scope: true,
    transclude: true

  return directive;


angular.module('lightScope', [])
.directive('lightScope', lightScope);

So obviously, the “transclude()” function is very interesting. We provide it an arbitrary scope, and can append it to the DOM element. That will propagate to the elements below in the HTML hierarchy.

Please refer to the official documentations for $compile service, they’re quite exceptional:

Q: Is it possible to manipulate HTTP requests globally in AngularJS? Describe your approach.

Yes, requests can be intercepted, and Angular provides a great api to do that - the “$http” interceptors. “.interceptors” is an array, available at “$httpProvider”, so it can be manipulated from “.config()” blocks. That array should consist of functions which return an object, basically factories.

Requests can be intercepted at: request (just before sending), request error, response success, and response error.

Considering that also “$resource” relies on “$http” to cover XHRs and the functions passed to the $httpProvider.interceptors array, can be normal Angular factories, using interceptors is a good practice for general global manipulation of HTTP requests.

Q: How does root scope differ from all other scopes?

“$rootScopeProvider” is a service. It is a singleton; it does not have a parent, siblings, or another root. It was created directly from the “Scope()” class, and not through the “.$new” method of another scope.

Perhaps the biggest differences are in how root scope is meant to be used. It’s primary use for developers is meant to be event handling. In Angular, “.$broadcast()” and “.$emit()” are ways to trigger events, which are sent down or up the scope hierarchy respectively. The effects are optimal at the root scope, i.e. “$rootScope.$emit()” will only be caught by listeners set on root scope, while “$rootScope.$broadcast()” will reach to all listeners in the app.

Models should not be set on root scope. That scope can be seen as a form of global namespace, especially when evaluating expressions in the context of scopes. Polluting the global namespace is almost never a good practice. The recommendation in Angular documentations is to use root scope only for small parts of data, which are useful throughout the app (globals), but not functions.


Building applications without writing tests is a no-go. Fortunately, Angular was built with testability in mind. Writing tests requires developers to learn and apply different approaches, depending on what type of Angular structure is tested. Some of the differences may be subtle and incomprehensible without knowing the good practices of software development. Others may include alternative approaches to achieve the same goal.

Setting up testing also for a continuous integration environment is the Angular developer’s responsibility. Who else would take care of it otherwise? Though the techniques described here are not required to build great applications, most of the teams behind the great applications value them deeply.

Q: Unit testing controllers and services - what are the differences?

The main difference between unit testing controllers and services stems from the differences in concerns. Controllers are used for setting the initial state and behavior of the scope they are bound to. We could say that all the models set on scope, either directly or using the //this// keyword, are public. This is still somewhat similar to the public properties of services. Controllers should not contain business logic though.

In unit testing controllers, one could expect more assurances of the initial values of models, and less logic. The logic in controller methods should mostly be just coupling UI actions to services. All functionality that is not tightly bound to the current view and scope, should be delegated to services. The developer would definitely have more spies set on mocked services objects in controller tests than in service tests.

Conversely, the services should be tested primarily for correct business logic handling.

Q: Please describe an approach to testing directives.

Directives are responsible for handling new and/or complex functionalities within custom HTML tags. Directives are set through HTML, and in most cases their effects directly affect the user interface of an application. That is unlike services, whose effects usually have an indirect effect on the UI.

Many directives have all of their logic in their postLink function. That function is not added to modules as controllers, services, and filters are, so they cannot be injected. Unless they are made globally available, it is very difficult reach them directly when testing.

The recommended, official way to test directives using unit tests is to inject the “$compile” service, pass it a single HTML element with the directive set on it, and compile it against a scope, e.g. root scope. After that, a digest phase is manually called, and then the compiled HTML element is tested for expected results.

it('Should compile to expected results', function() {
    var element = $compile('<div widget-component></div>')($rootScope);
    expect(element.html()).toContain('Simple as that');

That approach is rather fast. It might just be a bit difficult to test directive’s reactions for complex user actions. This is where Protractor comes into play. Protractor is a testing framework for AngularJS, written on top of webdriver, which executes tests against Selenium servers. It is used for e2e testing.

The alternative approach to testing directives is to do almost exactly the same thing, just with e2e tests. Compiling a directive in a unit test is a great way to isolate the directive. What is ultimately tested though is usually the visible HTML result. This alternative approach is about writing simple HTML pages, which load the directive (and it’s dependencies), and isolate the directive and its functionality on a simple page. No routing, nothing - just the directive. Such an HTML page is not yet the test — it is a standard example. The test needs to be run against that example page. This approach is particularly useful when writing libraries.

The latter approach is a bit slower in terms of execution. The application needs to boot in order to test the directive. However, such a test has a lot of value. Even more value comes from the fact that in the process, an example HTML page is created — a very useful artifact. Perhaps such tests could be called functional tests, and not yet full e2e tests, because the developer should still want to isolate behaviour and add every module that the final application is using, to the example HTML page.

Q: How would you automate the testing within a larger team, or in a production environment?

This is not a strictly AngularJS question, but a veteran front-end developer should at least have an idea of how continuous integration environments work, in regard to front-end testing.

First of all, we need to make the assumption that the project is version controlled with Git, and is hosted on GitHub, or BitBucket, or some similar code repository service. It would be great if at this point, the developer would mention gitflow, as it is a method with proven effectiveness. More importantly though, the developer should mention hooks, e.g. GitHub webhooks. Those are event handlers, described in-depth in a recent article on Toptal Blog, which allows HTTP requests to be made to arbitrary URLs in response to various repository events. An example would be to ping a third-party testing service when someone pushes commits to a repository.

There are multiple services, most notable of which are Travis, another GitHub product, available for free for open source projects, and SauceLabs, which allow automated testing on mobile devices. Those tools will do most of the configuration automatically, including configuring the webhooks. What the front-end developer will need to provide is a script, most often a bash script, similar to what probably already is in the repository’s file — the client application needs to be installed and run on the machine provided by the third-party testing service. The script usually installs all dependencies, runs the tests, builds the application, then deploys it. That last step is critical.

The continuous environment, after successfully completing the tests, should perhaps push the code to a remote server. The author never used such processes to push to production, but he did set up several systems where deployment was performed automatically to pre-production servers, e.g. development and staging. In fact, those servers were never pushed manually again. Such setup relieves developers from having to do the build themselves — the only thing they need to do now is commit their code and push. Even more importantly — it runs the tests on another machine. The developer would be expected to test their changes locally anyway. If the tests pass both locally and remotely, there is a big chance that the codebase is stable.


This hiring guide covered a wider spectrum of duties and knowledge than would be historically expected from front-end developers. A great Angular developer is perhaps more of an engineer. Debugging selenium issues, creating sophisticated build processes, and setting up continuous integration environments are more than client-side JavaScript. It is expected from the developer to be proficient with the latter, but experience and an understanding of the wider ecosystem of the application should be a requirement.

A great AngularJS developer is capable of blending art into engineering.

There were also some areas not covered by this guide, such as animations and rendering performance and CSS / HTML expertise. AngularJS programmers don’t have to be top-notch designers, but they must strive for making performant applications which mirror the provided designs. As there are so many concerns on the side of the logic, it would be alleviating if the team included an HTML / CSS developer. Static HTML templates provided by them could be easily applied to and coupled with an Angular application. Otherwise, animations in Angular, though frustrating at times, are well documented and rather easy to use. Please refer to the Top 18 AngularJS developer mistakes article for more on client-side performance.

Lastly and maybe most importantly come the communication skills. Dedicated AngularJS developers might very well become the main communication node of your development team. They will need to constantly cooperate with the back-end team, the HTML coders, and the designers. Their work will be what the end client directly interacts with. Essentially, the Angular dev will need to be very responsive, an expert at their field, and on good terms with everyone. Finding the right one is a difficult task. Toptal makes it easier.

Top AngularJS Developers are in High Demand.

Start Hiring