The first point is "Don’t try to be clever," and using Make in the JavaScript ecosystem defies exactly that to begin with.
Make is in no way limited to C or C++ projects and there is absolutely nothing wrong in using Make for a JavaScript project.
The only thing that sucks a bit is maintaining the list of inputs and outputs if you have a lot of files.
Well, that and the fact that Makefiles are not generally portable between GNU and BSD Make so if you use both Linux and a BSD you need to install either gmake on BSD or bmake on Linux and then remember to invoke that rather than just make for your project. Of course you could have a bash function that will look and pick GNU make if there is a GNUmakefile in your directory and BSD make if there is a BSDmakefile, but maintaining such things is a hassle as well.
It always comes down to picking the right tool and sometimes Make will be it and sometimes it won’t but whether the output is JavaScript or a PDF (e.g. from LaTeX documents) or JPEGs or whatever has very little to do with it.
The fact that you have to acknowledge this proves how unorthodox it is, and ignores team concerns. So no, there is something wrong with using Make for a JavaScript project: people don't normally do it.
> It always comes down to picking the right tool
You're right, stick to the ones people actively use and don't pretend features exist in bubbles.
I'm sure my comments would be more popular if I ignored the realities of software development and only praised the novelties of it.
im astounded so many idiots have such high karma counts on hn, what a wonderful place to have discourse
I don’t see why your comments have to be grey at all, if that helps, just pointed out where few may have ‘misheard your tune’. But if it is unthoughtful, then it’s their problem, not yours. They’ll use make and suffer, isn’t it fair?
I say this as someone who doesn't really like the JS ecosystem and its churn. I suppose you could argue the JS community itself has valued novelty over using tooling others will be familiar with. But if you have two tools that do roughly the same thing, one known to a majority of contributors and one known to a minority, I would go with the more popular.
I am a developer who works with other developers, so most of us will be comfortable with make.
so is gradle, maven, xcode, it does not matter what target is or what source is (as language, file etc)
they have tasks/recipes and dependencies/prerequistes imho JS's stack of build system still not good at all. changing to new system every 2-3 years. (note that i am not a js-dev, just outside point of view)
which is kind of a not-stable-ecosystem feeling. I see small agencies spending days maybe weeks to port their 'themes' to new stacks (long ago jquery, then gulp, now webpack) where as haven't encountered single "porting to new makefile format" case, because, of course solid history/background of make.
brilliant
But it does matter what the language is for the build script for each build system, e.g. Apache Groovy for Gradle, XML for Maven.