Hacker News Reader

Comment by morganherlocker | Hacker News Reader

90% of the time I see one of these build systems in place, all they are doing is running browserify, then minifying the results. Maybe they have a stylus compilation or a couple things thrown in on top. Either way, most of these tasks would be much less complex in simple bash or node. Does a build script like this really need to be abstracted away?:

https://github.com/morganherlocker/turf/blob/master/build

And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".

View on HN

That's exactly the case for what substack proposes. To me, these systems are a requirement in Windows. In other platforms, it's a matter of preference and convenience.

You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.

I think having options are healthy, as long as you pick the most reasonable one for your use case.

> You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.

This is a good point. In the example I linked to, I am actually planning on switching it over to node specifically for windows users. The reason I have not yet is that I handle all the builds so it has not really come up.

There is a windows version of make, as long as your other tools for the build process have windows equivalents.

And as long as you're not using bashisms inside of your Makefiles, which many people do.

Not sure if Grunt or Gulp do this, but Make will only run compilation if there have been changes since the last time it ran. Not something you're going to get with writing your own shell script.

Node core has fs.watch, and I know that grunt has a -w flag. I assume gulp does as well, so this is pretty easy to get with any of the solutions.

Reply on news.ycombinator.com