Gradle and Maven are both a million times better than whatever constantly changing collection of random stuff you have to use to build a contemporary node project.
Nah. Gradle has its advantages but it's way more complex than building a node project. The Gradle DSL is utterly incomprehensible to anyone that isn't a seasoned Java dev. Honestly, I struggle to think of a language with a more complex build system than Gradle, besides building cpp apps.
Nah, Gradle is a fucking mess no matter what. If you don't absolutely understand the gradle life cycle, how to avoid task configuration, keeping everything lazy, avoid cross configuration, understand that buildSrc is shit, gradle will be hell.
Agreed. Maven is boring, but for most stuff it just works. Hard to customize, but before doing that, ask yourself why you're doing something different than millions of other projects. Go with the defaults and things will work.
Gradle feels to me like trying to set up a webpack project. Loads of magic configuration no one dares to touch after it happens to somewhat work correctly.
Let's not compare Maven to Gradle. One is a stable, rock-solid, decades old declarative build tool with reasonable performance and excellent backward compatibility - the other is a configuration, semantic and maintenance nightmare.
Gradle is a very very good build tool from an engineering perspective - it can seriously speed up compilation, is actually correct (maven sometimes need a clean install to be 100% sure it creates the actual things) and basically has every capability out there.
The only reason Gradle is faster is because it uses a daemon for build caching and leverage JVM code optimization.
Once you apply that same strategy to Maven, it actually tends to beat Gradle in performance too. See Maven Daemon: https://github.com/apache/maven-mvnd
And if you build from inside IntelliJ, I think it already does essentially the same thing (unless you tell it not to) by importing the Maven project into its internal build system and using a compiler daemon: https://www.jetbrains.com/help/idea/delegate-build-and-run-a...
You don't need anything to build a node.js app. If you use typescript then yes you'll want typescript, but honestly the experience out of the box in node is pretty fantastic that you don't need anything else, as far as build goes.
Granted if you are talking frontend browser code then sure webpack, but that tool has been around and stable for many years now.
Added bonus too is browser adoption is way better than ever so you don't really need a transpile either, typescript being the exception.
Not sure I agree. NPM as a technology is actually pretty decent and fast. The biggest issue is that package.json doesn't allow comments. Webpack is shit. But there are good alternatives to it now - primarily esbuild.
I'd take that build system over Java's dog slow build systems any day. Just a shame about the JS ecosystem itself. Too many badly written libraries not written in Typescript (inexcusable these days) with a gazillion dependencies.
There's a lot of garbage TypeScript libraries too. I think a lot of this just comes down to size. Smaller languages tend to focus together on maintaining and contributing just one package that does the thing. TypeScript and JavaScript as lowest common denominator languages for many scenarios means there's a lot more options for better and worse. What hurts both as well is they are multi-paradigm while the broader communities are general pushing very hard into a single paradigm which necessitates more libraries and ecosystems.
Loving FP and admiring `fp-ts`'s work, I can't help but think our communities would be better off doing FP in FP languages instead of writing unergonomic and idiomatic code to much of the splintered TypeScript community. Yet, we'll writing things this way because it feels like the correct way to do software, meanwhile a bootcamper would find it incomprehensible; this same person would find an FP language more approachable because there's only one way to code it.
How is Java’s build tool slow? The single frontend compile step is literally the slowest in a badly architected project we use, even though it goddamn deploys to wildfly!
Java literally compiles as fast as it gets, while npm chews through the same files multiple passes, and goddamn barely does anything yet takes eons of time.
Yeah, I have no idea what that person is talking about. I'm in the same situation as you; we can compile hundreds of thousands of lines of Java code in dozens of different jars in less time than it takes for one of our frontend javascript builds to run.
The problem isn’t necessarily the quality of gradle or maven but rather that you get one more build dependency, thus increasing complexity of the project.