The need for things like this often make me sad, despite recognizing/accepting how complicated the landscape can be.
I almost always think tutorials like this make things more complicated than they need to be. Usually by including too many pieces under the "guise" that it is the "modern JavaScript stack" when many projects/companies often do not have nearly this many pieces.
> You don't need to use this entire stack if you build a simple web page with a few JS interactions of course (a combination of Browserify/Webpack + Babel + jQuery is enough to be able to write ES6 code in different files)...
Actually you can build a simple webpage with HTML and javascript. You don't need all those other tools adding complexity just because everyone else is doing it. This is especially true with how expressive es6 is.
Awesome!
v1 was fantastic for what it aimed to cover, and the v2 changelist covers almost exactly the set of things I considered gaps or suboptimal choices worth replacing.
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.
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.
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.
I almost always think tutorials like this make things more complicated than they need to be. Usually by including too many pieces under the "guise" that it is the "modern JavaScript stack" when many projects/companies often do not have nearly this many pieces.