Hacker News Reader

Comment by selfmodruntime | Hacker News Reader

There is no „wrangling the build-chain“ if you use the available clis all frameworks come with in advance.

Well since there's a plural in "CLIs", that goes into the "wrangling" category for me. If the dev/dep process involves more than one bespoke tool (looking at you js/Node monstrosities) and learning the arcana of their interactions, I'm out.

Well, I guess you‘re out of programming as a whole then, no? Most languages and dev process involve a lot of configuration or „bespoke tools“ and learning the arcane of their interactions.

Java? Gradle. JUnit. Maven. JavaDoc. etc.

C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager

Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...

Deployment? Docker. Jenkins. Travis. Kubernetes.

Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.

Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.

I understand what you mean but disagree. I merely appreciate tools that make some effort to standardise their UX. Of course configuration is going to be a major part of the system; however that doesn't mean I must use fragmented tools to manage them.

For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.

And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)

It's like you've never seen a webpack "config file"...

Do people not re-use previous configs as a starting point for new projects?

Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.

It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.

I have. Compared to what most back-end languages have to offer (CMake and the like), it‘s a joy to use, pretty straightforward and well documented.

C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.

> Python, Ruby, Go and, Rust are much more commonly used on the backend

Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.

However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.

I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.

I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.

Reply on news.ycombinator.com