Gulp.js: The streaming build system
gulpjs.com
gulpjs.com
All of that said, webpack is so very far ahead of everything else in the field that there is almost no way I would use anything else. It also has the side effect of making gulp mostly unnecessary. Simple Makefiles or shell scripts just get me a lot further nowadays.
Alas, at this point, my build needs are also being handled by Webpack. And, if I'm faced with something weird, I'd first try to solve it with a Webpack plugin. It's nowhere near as pretty as Gulp but it's the simplest to configure and most comprehensive.
It's been a tumultuous few years for JS build systems...
I encourage people to use webpack for any kind of js building unless you're using browserfy, but you can use browserfy with straight up gulp. You could also replace browserfy with webpack. Webpack will build your require.js (and your commonjs) without need for almond.js if you're making single builds. Setting up require.js with grunt was a nightmare, and a cinch with gulp + webpack. Like it took me an entire day in the past with grunt, and like 5 minutes with gulp and webpack.
I have never used Webpack (and now very little about it), but was wondering if it is worth investigating it?
start here : https://github.com/petehunt/webpack-howto
I prefer webpack just because how easy it is to use and how fast it is. It comes with its own watcher too, but I use gulp watch since I use gulp for building less, not the webpack less loader. I haven't wrapped my head around using `require` statements for less just yet.
Sooo many options, so little time.
I personally learned JS circa 2006 in the jQuery era and now I'm in a position where web-minded individuals ask me how to learn JS but they are "10 steps ahead" asking questions like react vs ember, ember vs angular, etc. Thoughts? Do they basically have to learn up the chain? I guess what I'm saying is there is a lot of history that I'm not sure can be skipped?
Having said that grunt is very bad because it is intimidating even for seasoned front-end programmers, it probably scared a lot of new developers away from even looking at front-end build systems. That's probably a good reason why it should fall off the radar. Thankfully gulp is much easier and I bet if you try it you will find it useful. If you don't, that's OK.
Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling.
[edited for a grammar nitpick]
I'm speaking from personal experience and time lost trying to just get things to work so I can focus on building the application, not making a hobby out of building the frontend tooling. What I said may be harsh, but it's the truth. Have you tried gulp?
If Grunt makes sense on some projects, and Gulp makes sense for others, why the need for all the value judgements? I still stand by the assertion that such claims add nothing to the conversation and muddy the waters for everyone.
I use Grunt to run Broccoli and tests. Broccoli is the best asset tool right now. Trees are so much better than streams or anything else. I even made some Sweet.js macros for making Broccoli files look super neat: https://github.com/myfreeweb/sweetbuild
People here are mostly saying to use webpack. Webpack is not a replacement for all of gulp but does work well with it (as do the other JS builders).
I recently did a tour-of-duty looking for the best JS build system. I settled on gulp early (over grunt) because grunt files were just too big to do the same thing. But Gulp is not the best for some aspects of JS building (bundling for multiple-pages). For those, I looked at RequireJS, Browserify and Webpack. Here's my overview opinion:
- RequireJS - a great starter and very powerful. Since it's old and not well-liked in the NodeJS community, people seem to not give it the credit it is due. Documentation could use some updating (some of the nuances of RequireJS take some googling). The one feature that this has that others don't is that you don't need a server to take advantage of it so you can start actually coding now and optimize as your project grows. - Browserify - great for building libraries that you expect to run on NodeJS and in the Browser. But it really falls short on building multiple bundles and dynamically loading resources (it's possible, just annoying). Watchify (auto-building) is nice. - Webpack - The cream of the crop. Multiple pages, dynamic loading, auto-bundling, built-in dev-server to monitor changes. If you have a project that is more than one-page, use webpack.
When using any of these with gulp, I would not use the gulp plugins. Rather use the NodeJS APIs alone. It may be a tad more cumbersome, but the gulp plugins mostly just try to shoe-horn gulp's streaming into a file-based API (and it's limiting).
But let's not forget that grunt had been real forerunner. It's been the only major build tool for years (probably also because streams weren't really as mature when grunt was initially designed). So here's to pioneer Ben Alman, for his immensely valuable contribution to the community!
For instance, I wrote a custom tag to modify specific pages to inject javascript include statements in HTML pages. There is probably a plugin for that, but I was able to write the code in 15 minutes so I didn't care.
I recently switched to Gulp for several projects, and I'm thinking of switching back to Grunt.
Gulp lacks of some important features. For instance, it does not allow to sequentially execute tasks: everything is done in parallel. This could for sure be emulated by using async, but the overhead is not worth it.
On the other side, Grunt does support sequential and parallel tasks execution, but is more verbose and does a lot of file writing on the disk (though it is relatively moderate).
One concrete example for sequential tasks execution (easily done with Grunt):
- Watch JavaScript files, when a modifications is detected:
- lint files -> [JSHint, JSCS]
- if success: launch tests -> [Karma, Mocha]
- if success: notify
But that's great if you are going to do it. This may make me come around and give a second chance to Gulp.
This is false. You can set perquisites for a task, which will be executed in sequence.
However, task dependencies allows sequential tasks execution, but that's not very handy as you may want a same task to be executed in two different sequences.
Let's see a simple example on which I honestly struggle to reproduce with Gulp:
[Lint, Test] -> Concatenation -> Minification
Watch -> [Lint, Test] -> LiveReload
[1]: https://github.com/gulpjs/gulp/blob/master/docs/recipes/runn...
There's a package[1] for Gulp which does exactly that.
gulp.task('copy', function() {
return gulp.src('src/foo/**/*').pipe(gulp.dest('dest/foo'));
}); //Don't let node crash
process.on('uncaughtException', function (err) {
console.error(err);
});