Live data from Hacker News

Maybe stop using Grunt?

medium.com

41–50 of 51 posts

Re: Maybe stop using Grunt?

#41

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.

A plug in system is nice. I didn't say it was totally bad, I just think its interesting.

Re: Maybe stop using Grunt?

#42

I 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 agree mostly. But when you're in the node ecosystem, often times you need to run JS as part of the build. For example, you might need to create some JSON data as part of the build.

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?

#43
post #30

Earlier 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.

Msysgit on Windows comes with a bash emulator (for running hooks) that could be used in a cross-platform build process.

Re: Maybe stop using Grunt?

#44

grunt < gulp < webpack < make

I'm willing to believe the first two comparisons even though I haven't used webpack, but I have tried to use make on multiple occasions over the course of decades. (That is, I've attempted to write new Makefiles and to modify existing ones to fit a purpose; I'm not talking about just using a Makefile someone else already wrote.) make is not nice. I admire anyone who can use it!

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?

#45

I 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.

Indeed. For JS projects these days I just use npm as the command-line tool. npm scripts gives you an easy way to create commands for building, watching, etc.

Re: Maybe stop using Grunt?

#46

How 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 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.

yes I found gulp to be more easy to implement than grunt. Maybe I haven't mastered grunt but I am happy with gulp.

Re: Maybe stop using Grunt?

#48
I started with grunt, then moved to gulp because I like the plugin support more and it felt less magical to me.

Then, 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?

#50

How 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 and bower are a mess.

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.

Post reply on HN