Live data from Hacker News

Grunt 1.0.0 released

gruntjs.com

11–20 of 106 posts

Re: Grunt 1.0.0 released

#11
post #9

Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies. Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.

I don't regret learning gulp. Node streams are bizarre, interesting construct and I'd probably had no chance to touch them but gulp made me understand them to the minute detail.

Re: Grunt 1.0.0 released

#12
post #4

Earlier quoted context omitted.

until the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).

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

You 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!

Re: Grunt 1.0.0 released

#13
I still use Grunt for small, one-off tasks that I'd like to be able to configure declaratively. For example, it's useful to wrap Webpack to make simple static deploys: https://github.com/thomasboyt/monotron/blob/master/Gruntfile...

I imagine that if I was more comfortable with shell scripting I could just use that, but I do like declarative tasks a lot, and there's very little overhead to adding Grunt to a JavaScript project.

Re: Grunt 1.0.0 released

#14

Earlier quoted context omitted.

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

You 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.js…

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

Re: Grunt 1.0.0 released

#15
post #7
post #5

Earlier quoted context omitted.

The 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,…

I don't see how that's different from Grunt, which is also driven by code.

This is a good explanation; https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-...

Re: Grunt 1.0.0 released

#17
post #9

Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies. Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.

One thing this dissuaded me from webpack is that it markets itself on support for AMD and script tags - if you need JS modules that are only available as AMD or script tags in 2016 it's a worry.

That said, I use gulp now and a notice lot of gulp seems to be replicating parts of JS itself - tasks are just functions, I don't see why they need to be special. There's always 'gulp foo' which is a less maintained wrapper around 'foo'. And browserify seems slow to build bundles - is webpack any faster?

Re: Grunt 1.0.0 released

#18
post #3

better late than never :)

Is it though? What's the point of a 1.0 release this far into a projects life? If it's utterly meaningless what's the point of versioning it at all?

Re: Grunt 1.0.0 released

#19
post #4

Earlier quoted context omitted.

until the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).

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

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

Re: Grunt 1.0.0 released

#20
post #17
post #9

Obsolete before it hit 1.0. While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies. Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.

One thing this dissuaded me from webpack is that it markets itself on support for AMD and script tags - if you need JS modules that are only available as AMD or script tags in 2016 it's a worry. That said, I use gulp now and a notice lot of gulp seems to be replicating parts of JS itself - tasks are just functions, I don't see why they need to be special. There's always 'gulp foo' which is a less maintained wrapper a…

Markets itself with support for AMD and script tags? What are you talking about, it's all about bundling things automatically without script tags, you don't even need to write the damned html file if you use loader for it.

Also it may have support for AMD, but it's key usage is to bundle libraries from npm using commonjs.

I'm not saying webpack is all roses (even in version 2), but these two things are not the issue.

Post reply on HN