3 ms·

Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build syst

Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build systems in JavaScript (grunt and gulp), and the other isn't a build system. Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from. But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make! >Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world. For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.

flukus 10y ago
See I looked at grunt and gulp and they both seemed lacking. Grunt doesn't seem to be a make clone at all, the getting started page only pays lip service to custom tasks. They both seem to require the tools you want to use to have plugins specifically for them. Neither seems to allow for variables from the command line. When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.
- Klathmon 10y ago
  Personally I ended up sticking with gulp, but writing a small helper that turns the tasks into command line commands (search up gulp-run-command and my username if you care to look, I really only published it for ease of use though so don't rely on it not changing), so it basically feels like an easier cross-platform make with a fancier dependency system. 99% of tools have a CLI and it's generally pretty damn good. If you don't have many "tasks" or they are pretty simple, just use npm's built in "npm run scripts" which works fantastically for smaller projects IMO. I agree though about the lack of ability to pass flags. I wanted something that lets me make command line commands as tasks, build a dependency tree ala gulp, and pass in optional flags to trip things like prod vs dev builds. But at the end of the day getting make to cooperate on all platforms was a mess, and it sure as shit didn't scale well or do stuff in parallel at all. So a simple if somewhat inelegant gulp file seems the best bet for us. (I imagine this is how new build systems are born!)
vacri 10y ago
> Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills. Some competition is good, but there is a point beyond which lots of choice becomes counter-productive. Troubleshooting also becomes harder when the various tool communities are smaller on average.
- Klathmon 10y ago
  I disagree with that premise though. Just because I made a package that's in the same realm as make doesn't mean that I could have or would have contributed to make instead. And there's something to be said about smaller single-purpose tools. Adding a ton of features to something like make to support every possible option isn't a good idea IMO. Sometimes a small opinionated package with a "correct" way to use it is best for some circumstances. Regardless, I really think that the market will sort itself out. If it's oversaturated then some big players will rise to the top and the rest forgotten. Unlike a Linux distro package manager, anyone can add anything to NPM with zero oversight. It makes the "floor" of quality much lower, but fragmentation isn't that big of a deal as the effort to publish is so low.

flukus 10y ago

See I looked at grunt and gulp and they both seemed lacking. Grunt doesn't seem to be a make clone at all, the getting started page only pays lip service to custom tasks. They both seem to require the tools you want to use to have plugins specifically for them. Neither seems to allow for variables from the command line. When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.

Klathmon 10y ago
Personally I ended up sticking with gulp, but writing a small helper that turns the tasks into command line commands (search up gulp-run-command and my username if you care to look, I really only published it for ease of use though so don't rely on it not changing), so it basically feels like an easier cross-platform make with a fancier dependency system. 99% of tools have a CLI and it's generally pretty damn good. If you don't have many "tasks" or they are pretty simple, just use npm's built in "npm run scripts" which works fantastically for smaller projects IMO. I agree though about the lack of ability to pass flags. I wanted something that lets me make command line commands as tasks, build a dependency tree ala gulp, and pass in optional flags to trip things like prod vs dev builds. But at the end of the day getting make to cooperate on all platforms was a mess, and it sure as shit didn't scale well or do stuff in parallel at all. So a simple if somewhat inelegant gulp file seems the best bet for us. (I imagine this is how new build systems are born!)

vacri 10y ago

> Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills. Some competition is good, but there is a point beyond which lots of choice becomes counter-productive. Troubleshooting also becomes harder when the various tool communities are smaller on average.

Klathmon 10y ago
I disagree with that premise though. Just because I made a package that's in the same realm as make doesn't mean that I could have or would have contributed to make instead. And there's something to be said about smaller single-purpose tools. Adding a ton of features to something like make to support every possible option isn't a good idea IMO. Sometimes a small opinionated package with a "correct" way to use it is best for some circumstances. Regardless, I really think that the market will sort itself out. If it's oversaturated then some big players will rise to the top and the rest forgotten. Unlike a Linux distro package manager, anyone can add anything to NPM with zero oversight. It makes the "floor" of quality much lower, but fragmentation isn't that big of a deal as the effort to publish is so low.