5 ms·
until the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).
by kyriakos 11y ago
until the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).
- onion2k 11y agoThe advantage of Gulp, in my opinion, is that it's driven by code rather than config - that is to say, in order to define your tasks you write JS code instead of JSON. That gives you a considerable advantage in cases where you want to do something outside of the scope of what the plugin developer was thinking. Of course, that brings with it the disadvantage of needing to be able to write JS in order to configure it, and an additional point of failure (eg your own code).
- Jean-Philipe 11y agoI never got what's so great about Grunt in the first place, and instead stuck to makefiles. Something like `cat src/*.js | uglify > build.js` would take me a lot more effort to do with Grunt (or Gulp).
- CraigJPerry 11y agoYou old curmudgeon you... ;-) Make has it's foibles - before we talk about those we need to declare are we talking gmake, nmake, BSD make etc. - our build scripts can break in the wrong make. And how will windows users collaborate (they'll install cygwin). Etc etc All that said though, I still find make to be lower barrier to entry. If I need to start a watcher or something, I generally have that in my npm package.json but there's nothing stopping me having a make target to call npm start or whatever. I forced myself to learn enough gulp to be dangerous (incidentally I see strong parallels between grunt / maven and gulp / gradle) and the faux pipes implementation is clearly influenced by make, it's just far more clunky an implementation. So it could just be I'm wired up wrongly but I have to agree, neither grunt nor gulp moved the needle meaningfully. Counter arguments like it's all one language don't hold much water for me, or for the designer who only really knows css. I'm resigned to being labeled a curmudgeon in this one!
- foldr 11y agoI had reservations about using make for node builds until I got berated by another curmudgeon on here, who kindly showed me all the tricks necessary to implement the rules I needed. I'm very very happy I switched to make. I think part of the issue is that I (and I suspect many others) though I knew basically how make works, except that I had no idea about % patterns, the patsubst function, etc.
- onion2k 11y agoWith gulp; var gulp = require('gulp'), concat = require('gulp-concat'), uglify = require('gulp-uglify'); gulp.task('js', function(){ return gulp.src(['src/**/*.js']) .pipe(concat('build.js')) .pipe(uglify()) .pipe(gulp.dest('.')); }); gulp.task('default', ['js']); With grunt; module.exports = function (grunt) { grunt.initConfig({ concat: { js: { files: {'build.js': 'src/**/*.js' } } }, uglify: { bundle: { files: {'build.min.js': 'bundle.js'} } } }); The bash script is easier for such a trivial job. Gulp and Grunt aren't better if that's all you're doing. They come in to their own when you have a large number of tasks to run. But even then, if you (and your team) prefer make then it's better to use make.
- douche 11y agoIt does seem overly complicated, for what ends up usually being not much more than a makefile or even a simple batch script. We haven't quite come out of the cycle where everything that we already had has to be half-implemented a dozen times in JavaScript/Node...
- pcr0 11y agoIf that's all you want to do (concat, minify, convert es6/sass), then by all means, I do agree make is the simpler albeit slightly less maintainable and non-cross-platform solution. I use make for my quick static sites too. But when you need more features like bundle splitting (app code and libraries live in separate files, for caching), cache-busting, lazy-loading, separate configs for production and development, etc. make doesn't quite cut it IMO.
- Jean-Philipe 11y agoSure, cross-platform (read: supports also Windows) is a big plus for grunt, gulp and the likes.
- cristianpascu 11y agoI have large project built with Grunt and at one point I have tried to move it to Gulp. Gulp, as far as I can tell, requires much less code to do the same stuff. However, two things forced me to stick with Grunt. 1) The build scripts were working just fine. Why fix something it ain't broken? :) 2) When Sass or Coffee fails, gulp watch fails entirely. It's something I wasn't able to solve. Grunt will just pick up from it was before the error. Dunno!
- codebeaker 11y agoThis must be solved with `gulp-plumber` which is actually about a 10 line hack around fixing some underlying bugs with merging streams if memory serves.
- maxo123 11y agofor less it's a pretty easy fix: .pipe(less()) .on("error", function (err) { console.log(err); this.emit("end"); }) I presume, something similar will work for sass too.
- tangue 11y ago(Just a personnal feeling) Gulp commands are more standardized, while in Grunt every plugin seems to develop its own way of doing things. And Gulp tends do do things faster. But as you said, nothing wrong with Grunt. Indeed feeling the Javascript build tool fatigue , I'm seriously hesitating to do everything in a makefile
- romankolpak 11y agoOne huge advantage is speed - Grunt relies on disc I/O and copying files to temp folders, while Gulp is based on streams and all your file transformations are done in memory.
- tragic 11y agoIME, with enough dependencies in enough tasks, it can get very slow to start.