Maybe I am missing something, but it seems like most of theses tools are working around the fact the windows doesn't come with make by default. They are essentially reinventing the wheel for web developers who have never worked from the command line before.
I've written both makefiles and gulpfiles. Yeah, I guess you can get make to do the exact same things as gulp, but gulp already does what a web developer needs, in a language they already know, with a massive plugin ecosystem you don't have to re-implement in shell.
Maybe stop using Grunt?
41–50 of 51 posts
Re: Maybe stop using Grunt?
#42I keep seeing people mention "a mess of shell scripts", and then use replacements which are dozens if not hundreds of lines of custom-configuration files. Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated. Not to mention that the ability to chain disparate tools and subshells can be incredibly elegant and powerful.
I ended up writing my own build library (npm install crankshaft). Docs aren't up yet, but here's what build scripts look like - https://github.com/jeswin/hitchslap/blob/master/build.js (simple example) and https://github.com/jeswin/fora/blob/master/www-client/build-... (more complex, with dependent tasks)
Re: Maybe stop using Grunt?
#43Earlier quoted context omitted.
> Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated. They're not always portable. Some people develop on windows.
Windows offers shell scripts as well. Powershell, instead of Bash/Zsh/..., but they still offer many of the same opportunities. Considering that teams frequently homogenize on one type of machine - bet it windows or Mac or Linux, shell scripts are typically portable enough for these use cases.
Re: Maybe stop using Grunt?
#44grunt < gulp < webpack < make
To be specific, what advantages does webpack have over gulp that webpack doesn't also have over make? (I would also accept advantages that gulp has over grunt that gulp doesn't also have over make.)
Re: Maybe stop using Grunt?
#45I keep seeing people mention "a mess of shell scripts", and then use replacements which are dozens if not hundreds of lines of custom-configuration files. Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated. Not to mention that the ability to chain disparate tools and subshells can be incredibly elegant and powerful.
Re: Maybe stop using Grunt?
#46How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem. I hack around it by keeping node_modules around as a special r…
2) We use StriderCD, the self-hosted CD/CI, and it too supports caching node_modules. 2 minutes is a 'long' time for us from git push to autodeploy.
3) We use gulp and npm always. Grunt and bower are a mess.
EDIT: Also, we npm shinkwrap projects. It avoids numerous issues and makes module caching a natural part of the process.
Re: Maybe stop using Grunt?
#47...I would like the task system to provide an abstraction for pipelining tasks. (Perhaps gulp helps with this?) Hmmm, perhaps someone needs to look at any gulpfile ever written, anywhere. gulp.src('src') .pipe(this()) .pipe(that()); Maybe it's frustrating for anyone who spent "18 months" hacking grunt, but gulp really is better. Both tools are built on node for Pete's sake; async really shouldn't be that hard.
Re: Maybe stop using Grunt?
#48Then, I found that working with many different projects, gulp wasn't DRY enough for me. I kept copying any pasting my tasks across projects and forgetting to go back and improve them as I went. I also disliked the chain of require statements and devDependencies in my package.json. I was spending too much time coding my build.
So, I started a project [1] to move gulp tasks into re-usable functions and hide the devDependencies. Now I'm pretty happy with the result, my gulpfile [2] is now mostly configuration and very little code.
[1] https://github.com/lookfirst/gulp-helpers/
[2] https://github.com/lookfirst/systemjs-seed/blob/master/gulpf...
Re: Maybe stop using Grunt?
#49grunt < gulp < webpack < make
Re: Maybe stop using Grunt?
#50How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem. I hack around it by keeping node_modules around as a special r…
1) We have our own private npm that can optionally include a caching layer. This has been invaluable since the beginning of our company to manage internal dependencies. 2) We use StriderCD, the self-hosted CD/CI, and it too supports caching node_modules. 2 minutes is a 'long' time for us from git push to autodeploy. 3) We use gulp and npm always. Grunt and bower are a mess. EDIT: Also, we npm shinkwrap projects. It a…
grunt has its issues, but you are correct that bower is truly a mess. "Let's do one of the many jobs that npm (the tool we use to install bower) already does, but not as well!" No thanks.