4 ms·

Why these days Gulp is no longer in favor? Isn't it harder to configure projects in plain NPM/yarn?

by jpkeisala 10y ago

dlandis 10y ago
I think Gulp is still in favor, but you only need it if you have more complex task running requirements. In the example, all the scripts in the package.json are just simple commands so there is no need for Gulp. If you wanted more complex scripts, then scripts in package.json could reference Gulp tasks.
russellbeattie 10y ago
After having to tweak and extend first Grunt, then Gulp, to do basic (yet custom) build tasks, I finally switched to a pure NodeJS build.js script and it a revelation: Cleaner, clearer tasks using standard JavaScript code. I was super strict about dependencies at the begining, but now import ShellJS to make file management easier and Chokidar to watch file changes. Depending on the other functionality I need for that project, I may import ESLint, Node-Sass and other libs, but the core is simple. Beyond just having less libraries and lines of code to maintain and understand, I have complete confidence that anyone reading or maintaining the build script after me will understand it easily with zero learning curve. This can't be overstated in importance.
tdumitrescu 10y ago
I think gulp lost a lot of ground to webpack thanks to the popularity of react, and webpack offered a more declarative and convention-driven api for the sort of things people used gulp for the most: chaining together build steps to transform source files step-by-step into browser-ready assets. For more one-off tasks like kicking off scripts and specifying how they should run in parallel and sequence, the native ES landscape has improved greatly since the heyday of gulp; with native Promises, async/await etc you can organize task flows with a syntax that doesn't require any special knowledge of your build tools.

4 ms·

Why these days Gulp is no longer in favor? Isn't it harder to configure projects in plain NPM/yarn?

by jpkeisala 10y ago

Why these days Gulp is no longer in favor? Isn't it harder to configure projects in plain NPM/yarn?

dlandis 10y ago
I think Gulp is still in favor, but you only need it if you have more complex task running requirements. In the example, all the scripts in the package.json are just simple commands so there is no need for Gulp. If you wanted more complex scripts, then scripts in package.json could reference Gulp tasks.
russellbeattie 10y ago
After having to tweak and extend first Grunt, then Gulp, to do basic (yet custom) build tasks, I finally switched to a pure NodeJS build.js script and it a revelation: Cleaner, clearer tasks using standard JavaScript code. I was super strict about dependencies at the begining, but now import ShellJS to make file management easier and Chokidar to watch file changes. Depending on the other functionality I need for that project, I may import ESLint, Node-Sass and other libs, but the core is simple. Beyond just having less libraries and lines of code to maintain and understand, I have complete confidence that anyone reading or maintaining the build script after me will understand it easily with zero learning curve. This can't be overstated in importance.
tdumitrescu 10y ago
I think gulp lost a lot of ground to webpack thanks to the popularity of react, and webpack offered a more declarative and convention-driven api for the sort of things people used gulp for the most: chaining together build steps to transform source files step-by-step into browser-ready assets. For more one-off tasks like kicking off scripts and specifying how they should run in parallel and sequence, the native ES landscape has improved greatly since the heyday of gulp; with native Promises, async/await etc you can organize task flows with a syntax that doesn't require any special knowledge of your build tools.