What Angular is doing with Bazel and Closure
In his ng-conf 2017 keynote, Brad Green announced an effort called ABC — Angular with Bazel and Closure. The goal is to converge how we develop Angular applications internally at Google with how the external community does it. This is still in the design phase, so detail and documentation will not be ready for some time. But we also care deeply about the Angular community, and believe it’s important to give some sketch of what we aim to do, and why.
In the 10 years since, the team has continued to make incremental improvements to the optimizer in Closure Compiler. Even single-digit-percentage optimizations provided enough benefit across Google’s webapps that we could dedicate the engineering effort needed. Features like code-splitting to support lazy-loading, and A/B experiments and code hiding at the level of individual JS files have been added to our build toolchain.
The necessary property to make this work is that development turnaround time must be proportional to the size of a “library”, not to the size of an application. By dividing compilation into individual compilation units, we only need to run `ngc` on the handful of files including those you’ve just changed, but not on the rest of the application. In other build systems, it would be very cumbersome to orchestrate all the needed re-compilations, and especially hard to reliably re-build the right ones. After all, the only thing worse than a non-incremental build tool is a build tool where you don’t trust that the change you just made is actually reflected in the running application. Bazel users trust the incrementality so much that they never run “bazel clean” (I speculate that many Googlers aren’t even aware of that command).
We think this is pretty cool, and really important to developing large, enterprise-scale frontends. But unlike most of Angular, we’ve developed this integration in our closed-source internal repository. Now we are working to make this available to everyone. This benefits both the open-source community (especially enterprise users), who could build Angular applications like Google does, and also benefits the Angular team, by reducing the amount of parallel effort we undertake behind the scenes.
At the same time, this is also pretty intimidating. Building Angular applications can already be challenging at large-scale. We want to make this better, not worse. So our plan is to first roll this out in our own GitHub repository (which has been suffering a shell-script based build for a year) and prove to ourselves that we can love this developer experience.
After that, we’ll evaluate some options to assemble a build toolchain that provides the best of what we’ve built for ourselves and also the best of what has been built by the community. For example, even though Bazel will run all the compiler tools, we can still use Webpack as the development server. We will also consider how this toolchain can be available in the next generation of the Angular CLI.
There is a lot of work ahead of us, but we are also tremendously excited to tear down some of the walled garden that has separated the developer experience of our two crucial groups of users: our Google co-workers and our Angular community.