[venantius]

I have worked extensively with Bazel in the context of migrating a very large Java/Scala codebase from Gradle to Bazel.

My impression is that it is a first-class build system _specifically for Java and C++_. There are specific properties of the compilation and packaging ecosystem around those languages and runtimes that make them uniquely in need of tools like Bazel. This is not true for Go, where build speed and large codebases were a consideration up-front (especially with the new build caching features that shipped in Go 1.10), and are almost completely irrelevant in the context of "interpreted" languages like Python, Ruby or JavaScript.

There are plenty of other languages and runtimes that stand to benefit from a tool like Bazel, but just because Bazel is a fantastic tool in some contexts doesn't mean it brings that much to the table in others.

[cromwellian]

Actually it is very relevant for JavaScript at Google, given Closure Compiler. Most of our JS apps are type checked, code split and optimized and Bazel is how we structure the module dependencies. The Bazel build rules define independent logical modules, and build processes prune unused dependencies, and calculate a dependency graph which is used to organize an optimal module structure, this is then used by Closure Compiler’s CrossModuleCodeMotion to further reduce size by moving methods and properties down to later modules.

Granted, JS isn’t incrementally built, but the dependency graph pruning (removing unused files from the build that aren’t imported or referenced in JS code) is parallelizable.

[venantius]

Yeah, JavaScript is a bit of an odd one out here, and I can obviously see the value in terms of providing a minimal build (in a way that's of less import to Ruby/Python users, say).

That said, it all depends what benefits you want to get out of Bazel. For us, incremental builds were the key thing we cared about - minimizing JAR size was important, but we already had a decently good handle on that.

[letientai299]

I can speak for Java only. Most of my Java project, which are using Spring Boot and lots of libraries, gradle (previous is maven) works just fine. If there's any build issue, assume that it's not compilation issue, I just delete the `build/` and `.gradle` folders, then `./gradlew clean build` again.

I've took a hard look as bazel, for what they claim to be fast, correct, but the complicated setup and document just put me off.

Why should we consider bazel over gradle or maven for Java, or any other JVM languages?

[venantius]

Your comment makes it sound like you don't run your build process in a continuous integration environment.

[letientai299]

I do. In fact, I'm working on several Spring Boot services that has CI/CD configured on Gitlab. The workflow from push, build, test, release docker image and deploy are all automatic on Gitlab CI.

[foota]

I don't really view bazel as being that complicated to set up, what makes you think that?

[danmux]

Spot on.