Hacker News Reader

Comment by badthingfactory | Hacker News Reader

My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.

View on HN

I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-)

Just be glad Gradle hasn't entered the JS scene yet:

With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned.

With Gradle however I haven't seen two similar setups so far. Edit: I might have seen two similar setups.

Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos.

I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc.

The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff where all this complex stuff just makes sense.

> The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff.

Android Gradle Plugin: here, hold my beer.

https://developer.android.com/studio/releases/gradle-plugin?...

I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a suggestion to re-run the possibly very long build with -info or -debug. At that point, instead of not having enough output, you're usually drowned in megabytes of irrelevant messages.

Not a fan of all the magic behavior at all.

This is what I was referring to the knowledge cliff.

Gradle is incomprehensible until it isn't. It has a very steep but short learning curve and understanding is completely binary. It's very unfortunate but it is how it is.

I still take it over the JS stuff but I do acknowledge it's shortcomings. I also don't do Android development so I don't know if it's particularly bad there.

The knowledge cliff doesn't end with Gradle because it's infinitely extensible. So you have to understand all the plugins as well. Because there is so much implied magic happening behind the DSL, when it breaks, you don't have a clue why. Reading the documentation is often insufficient, you have to track down the source code for the version of the plugin you're using.

In general, I find DSLs make my life harder, not easier.

Gradle is my least favorite build tool ever. It's just too much magic in too many places.

This is not an endorsement of the JS ecosystem either. It also sucks, but it has wasted less of my time than Gradle (again, in the context of Android).

Reply on news.ycombinator.com