A year and a half ago we announced our second attempt to add a Bazel backend to Nx. Unfortunately this is not going to happen in the near future. I'd like to provide some context about why we wanted to do it and why we decided that this isn't the time.
We started the Bazel effort for the following two reasons.
Computation Caching
We really wanted to add computation caching to Nx and Bazel had good support for it. So one way to add computation caching to Nx was to run Nx on top of Bazel.
We then realized, however, that to really integrate caching in the dev workflow it will have to be a first-class concept in the build tool itself. That's why we've added distributed computation to Nx. At this point adding Bazel would not give us much on top of what we already have.
Bazel and Angular
Nx is widely used in the Angular community. The Angular team at Google had plans to add Bazel support to the Angular CLI for many years, but the plans didn't materialize. The key folks (e.g., Alex Eagle) working on the effort left Google. Google employees no longer maintain rules_nodejs.
This, of course, doesn't mean that rules_nodejs isn't maintained well. It simply means that the vast majority of Angular developers won't use Bazel, so there is less motivation for us to support them.
Bazel or Nx
When using Nx you can swap its default task runner with one using Bazel. You could make it work, but most people should not do it.
The core of Nx is technology-agnostic. You can use it to build anything, and folks do (there are third-party plugins for Go, Java, Python, etc.). A lot of the value Nx provides is in its plugins. These plugins use existing tools, many of which either don't work with Bazel at all or require significant workarounds.
This is the issue we faced. We built a Bazel-based runner for Nx. Some plugins (e.g., tslint) worked with it, but the majority didn't.
In many ways, Bazel is akin to something like Dart. It's a great piece of technology, but it doesn't play nicely with existing systems. Existing JS libraries didn't work well with Dart. Similarly, existing tools don't work well with Bazel.
Nx is more like TypeScript. Sometimes it results in suboptimal choices (Dart has int and floats, and TypeScript has only numbers), but most of the time it doesn't matter. It is straightforward to add to an existing project. Learning resources are plentiful. It integrates well with the rest of the stack.
Discovered a new tool, say [Snowpack](https://snowpack.dev_? Adding it to an Nx workspace is trivial. Any tool you want either "just works," or can be made to work with minimal effort. We value this and I believe a lot of folks do as well. Building a custom stack for your organization is not just a technical challenge. It's also a recruiting one.
You can also see some benefits after introducing Nx almost right away, which means it is a lot less risky for the business.
Of course, I think Nx is a better choice for most companies, otherwise I would not be working on it, but I know that for some Bazel might be the right tool. I recommend you to try out both. Go to nx.dev and try it out. Try out Bazel as well. And then make your own mind.
Top comments (0)