Gulp, Grunt, Whatever | Hacker News Reader

Gulp, Grunt, Whatever

blog.ponyfoo.com

46 pointsbevacqua22 comments

Gulp has a lot in common with the venerable make(1) in its approach to building targets, but make is seemingly overlooked in certain circles. It's definitely worth checking out. I wrote something of an introduction to make with the setting of managing a JS app's codebase:

http://justinpoliey.com/articles/make-for-front-end-developm...

Make is old, but still pretty relevant. Maybe some peoples' avoidances come from the association with autotools and the complexities involved in building portable C programs. Using make to manage something like a front-end codebase, which doesn't suffer that family of complexity, is pretty straightforward and kinda enjoyable.

I used make for a long time on my JS codebases, and I agree that it is very useful. You can do a lot without needing to write a lot, and file targets usually 'make sense' for most build tasks.

I decided to switch to Grunt, though, to enable Windows developers to build my projects. This decision stems from the fact that Node does not run in Cygwin in Windows, so we weren't getting Windows build support 'for free'. The Grunt build files are much much more verbose, but I know that they work cross-platform as I no longer rely on CLI tools that may not be present, or may have different flags between the BSD and GNU variants.

If you don't care about Windows developer support, though, make is definitely worth investigating.

Curious... if you have to support windows developers who are okay with Cygwin, why not use VirtualBox with Vagrant to achieve the same thing without the "doesn't work with cygwin" problem?

Visual Studio has really nice TypeScript support. :)

Also, I never said the Windows developers were 'okay' with Cygwin... just that it wouldn't solve the problem. ;)

With make you wind up having separate makefiles for each platform. For cross-platform by default environments like Node, that doesn't make sense.

90% of the time I see one of these build systems in place, all they are doing is running browserify, then minifying the results. Maybe they have a stylus compilation or a couple things thrown in on top. Either way, most of these tasks would be much less complex in simple bash or node. Does a build script like this really need to be abstracted away?:

https://github.com/morganherlocker/turf/blob/master/build

And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".

That's exactly the case for what substack proposes. To me, these systems are a requirement in Windows. In other platforms, it's a matter of preference and convenience.

You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.

I think having options are healthy, as long as you pick the most reasonable one for your use case.

> You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.

This is a good point. In the example I linked to, I am actually planning on switching it over to node specifically for windows users. The reason I have not yet is that I handle all the builds so it has not really come up.

There is a windows version of make, as long as your other tools for the build process have windows equivalents.

And as long as you're not using bashisms inside of your Makefiles, which many people do.

Not sure if Grunt or Gulp do this, but Make will only run compilation if there have been changes since the last time it ran. Not something you're going to get with writing your own shell script.

Node core has fs.watch, and I know that grunt has a -w flag. I assume gulp does as well, so this is pretty easy to get with any of the solutions.

Like most of these modules, you can use it without installing it globally: Just use an NPM task. My `package.json`:

    {
      "name": "hi there",
      "version": "0.0.1",
      "scripts": {
        "gulp": "gulp build --require coffee-script",
      },
      "devDependencies": {
        "coffee-script": "~1.6.3",
        "gulp": "~3.2.2",
      }
    }

And then happily run `npm run gulp`. Solves 98% of my problems since I have at most 3 tasks that I want to execute individually.

This may be the most helpful thing I've seen for npm ever. Thank you

When I first heard about Gulp I was enthusiastic but skeptical. Grunt seems unassailable in many ways, it's nearly ubiquitous in JavaScript projects. Gulp doesn't need to be as popular as Grunt, but if it can be popular enough to have plugins for most common tasks, I'll switch in a heart beat.

It already has plugins (150+) for the most common tasks: http://gratimax.github.io/search-gulp-plugins/

Cool, will have to check out the browserify plugin and see if amdeify and bowerify work with it.

I prefer bash. However this gulp code actually looks a little easier to read than grunt, so that's nice. But I think I would prefer something declarative if I wasn't using bash and grunt is a lttile complicated and so I made my own thing that is very simple and uses yaml.

Its called bild. So you can check that out on npm if you want.

Anyway I think using regular node scripts, maybe with a module like shelljs, would also be a decent solution.

Does git-bash run normal bash scripts OK in Windows?

The biggest issue for me is this: "Gulp doesn't solve any new problems really" I want a build system that works and then just gets out of the way. Something I can setup once and then hopefully never look at it again. The code I'm writing is where I'm creating value, not mucking around with the build system. Given this, there is no motivation to move away from Grunt for my Javascript projects.

If you're trying to find a good build tool, also look at Bud: http://github.com/azer/bud https://medium.com/p/6a4c74b4bd90

After going from maven to rake (switching from java to ruby) it was like a breath of fresh air. Using grunt then seemed like a real step backwards. I'm really glad to see gulp and hope that it becomes the defacto build tool for javascript.

A rousing "pick the best tool for the job" towards the end. Ho hum. That's what they all say, but of course, how that is defined is where things get interesting.

Reply on news.ycombinator.com