Angular as a Strategy for Collaboration and Scale

This series of blog posts which I have converted from Youtube videos. I personally have really enjoyed these videos so in order to textually document them, these are essentially some screenshots and rough notes organised. 

This particular post is based on the awesome Brad Green NGAtlanta 2018 talk. It can be found on the link

Strong, steady community growth

The angular community has grown tremendously from 2017 to 2018. There are now more than a million developers in the Angular community and 790+ meet-ups happening worldwide.


If we compare this growth rate to AngularJS (1.x), we find it to be at 5x faster growth rate.

Bazel is a build system which is being used at Google for over a decade.

Bazel benefits

It has a really nice environment where the builds are all hermetic, it provides fully incremental builds every time and it never redoes work which is already done. If the applications are required to be tested, it reuses that, when some other part is run, it is not required to redo something which has been done.

It possible to move to any size team and any size codebase. The developer will receive a consistent build speed on rebuilds. It is possible to have multiple repos which share code or one huge model repo.

Bazel supports multiple languages. There is a python like extension language and a vast set of extensions which are contributed by the company. It is also important to know that Angular now builds with Bazel.

Bazel current status

There is a very fast round-trip development cycle and the service level goal is to get in under 2 seconds. It has recently released bundling with a roll-up and uglify. It also gives away the ability to reuse libraries across several different apps. It might come in handy when dealing with a big set of apps. A couple of things coming up are:

Bazel roadmap

  • Packaging for libraries
  • Code splitting and lazy loading
  • These might come up in next couple of months



Schematics is the engine inside the angular CLI. It is most commonly used. The CLI is where one can use it to scaffold apps and add components. It helps in building and offers a productive development cycle.


Schematics is the part which has been extracted and it powers all of the procedure for describing templates. These templates can be taken out of the box and put to use. They can be extended, replaced and edited. As the specifications of the app go, they can be completely replaced as well. 


Ng update automatically updates all of the dependencies on NPM and then it refactors the code for any of the breaking changes.

There are certain things which can be tried in order to gain more experience and expertise.

  • Building a schematic which automatically changes all the routes to lazy loaded routes.
  • Replacing all of the buttons with angular material buttons.

At NRWL, they are using the schematics to help in building Nx. Nx gets all of the teams set up with the right infrastructure which can be scaled quickly. Native Script is in progress. They are using it to help in building bridges between existing angular projects and mobile projects for iOS and Android. They can be easily extended and the code can be shared across the two of them.

Component Dev Kit

This is a part of the process of building components. At Google, there is a design aesthetic which is called material design. All the pieces required to build CDK has been extracted out.


It contains, accessibility, bidi layout and many more. There are some of the new pieces on the way as well like, SVG, overlay, tree and many more. These can be used as building blocks. These are intended to be scaffolding, so the components can be built quickly.

In the chart below, there are some of the things which are difficult to be done right, if the developer is trying it out themselves, like, accessibility, scrolling, and overlay.


Then, there are un-opinionated components- things which do not have a look or feel associated with them. They can be used to build whatever version which was required.

Observables as a standard

Whether it is the default API, RxJ or NgRx, the observables are being used in all of them.

Benefits of standardization

There are a couple of goals of standardization. To unify the APIs across all of the different libraries. This helps in shipping lesser code to the browser. The lesser code is written for the impedance matching between the observables API and what is in the DOM. It is intended to be useful, out of the box.


When the browser is used, the user should be able to rely on some of the reducers- some of which are more common than the others, like map filter which is further integrated with DOM APIs.

Something like this can be done,


Interact with it in the same way as one would with any other observables in the environment.

Angular elements

It helps in taking the components with which one builds an angular and publishing it them as custom elements. The custom elements are a part of web components specification. It is a default standard comes with the browser.


It has a bunch of different pieces, but the most important part is a custom element. The idea is that the browser comes with a bunch of different default elements like inputs and checkboxes, forms and many more.

The angular component would be wrapped inside the custom element. So to the users who consume it, it is seen as custom elements only. They do not know anything about angular, they do not interact with any of the angular’s API.


This allows to wrap the angular components as custom elements. It does the bridging between the angular APIs with inputs and outputs.

It is not required to know anything about angular. It will be bootstrapped by the browser just by loading the piece of JavaScript۔

There is just one bit of new API which will be required to be learned. It is a king of the register which custom elements call.


Status and roadmap



It is a new renderer for angular. Moving from angular 2 to angular 4, the renderer is required to be replaced. 


Transition the size to very small. It helps out in the mobile space making.

For some of the components which are required to be distributed, the framework is required to be tiny.

Making things simpler, the procedures will be faster as the architecture would be simpler.

Currently debugging an Angular application is a little bit complex due to reading unfriendly stack traces. NgIvy has very small and easily understandable set of instruction which makes complete sense while debugging.

The ngIvy compiler only needs to know about a single component and then compile it individually so that all the compiles are incremental.

With this new renderer, hello world was generated.

Effective teams and Diversity and Inclusive



Why diversity?

  • Personal connection, either to you or yours to someone else.
  • From a personal point of view, it may appear to be the right thing to do.
  • Team productivity, how well a work can be done together?

Support diversity

There is a bunch of different ways to support diversity.

  • Inspire things like NgGirls which helps women around the world into learning.
  • Support individual people. On LinkedIn, it is possible to connect with anyone.
  • Help by giving money to the organizations which are working to support diversity.
  • Work on recruiting.
  • The more important aspect is Inclusion.

Let’s conflate some things!

The productivity and diversity are very tightly related. Productivity and inclusion are also tightly related. All of these are bound together.


By keeping inclusion at the focus, the properties of the rest of the two aspects can be received for free.

What makes a team productive?

The productivity of the team relates to the IQs of the team members.

According to a study, 699 participants were chosen and they were to go through a bunch of different team-based tasks.


What mattered was social sensitivity. How well is an individual able to look at someone’s face or what they are typing or saying, and understand the feeling and respond appropriately?

  • Another thing was taking turns in conversation
  • The number of women
  • Other considerations might include the individual tasks of an employee and extrapolation to tech population

There was a follow-up study which was better due to their findings.

A much stronger predictor about how teams do was the average social perceptiveness of the group. There is a way to measure this, called the Reading the Mind in the Eyes (RME) test.

  • Balances teams may be necessary
  • The more the cognitive diversity, the more innovative ideas
  • The more cognitive similarity, the better the efficiency

Reading the mind in the eyes test gives the person a picture of the eyes and there is 4 option below as to the corresponding emotion.

Google’s findings

More than 200 people were interviewed. More than 180 teams looking over 250 attributes.

Off all the things which matter, the top one is psychological safety. How much an individual feel at ease that they are able to take risks for the team, that they can be vulnerable about many things.


What should I do?

  • Make social sensitivity and conversational turn-taking part of your team’s explicit values.
  • Sleep 7 to 9 hours every night. Sleeping is important to keep the minds fresh, even if does not appear to be.
  • Become aware of your biases.
  • Meditate. Meditation can be one of the ways which improve the ability to empathize with others.
  • Improve Games. These are skill-building exercises, where the person has to read what other people are thinking or feeling and react to them.