
Grunt 1.0.0 released - plurby
http://gruntjs.com/blog/2016-04-04-grunt-1.0.0-released
======
vladikoff
Hey! Core maintainer here.

I see a lot of comments are basically saying our project is obsolete or sucks.
That does not stop us from working on Grunt though.

We are still seeing record download numbers, even with the 2 year old
releases. This is why we felt it was important to keep releasing this software
and supporting developers.

For those who support and use Grunt - huge thank you! Pick up your free open-
source copy made by volunteers on npm.

~~~
reitanqild
I don't get node and npm (although I was good with JS), but you seem to be
cool.

Noted. : )

Edit: again, now that we have a bunch of people capable of understanding
trendy JS here: Care to share a link to somewhere I can learn?

~~~
armandososa
Here: [http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-
tool...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/)

I don't hate grunt, I used to love it and used it for all my projects. And
then I started using gulp.

But after reading this article I just use npm script 99% of the time. I don't
know if it is better over all, I just prefer it over grunt/gulp.

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

~~~
rkwz
The problem with Webpack is that if you want to do something that's not
straightforward[1] or covered in the dozen tutorials that are on the web,
you're going to have a hard time.

The docs are very basic and there are so many configuration params.

If you want to do something that's not covered in tutorials or boilerplates,
be prepared to spend a ridiculous amount of time reading Webpack PRs, issues
and the codebase.

Webpack does a great job and it's a nice concept but it has very bad
documentation.

[1] Isomorphic apps, or multiple builds for i18n etc

~~~
amelius
> The problem with Webpack is that if you want to do something that's not
> straightforward[1] or covered in the dozen tutorials that are on the web,
> you're going to have a hard time.

I really hate systems that are built like that. Nobody should build software
like that.

I just want simple tools with a clear API that I can combine together and
easily replace by other tools, like in the Unix tradition.

I guess it is a case of "LEGO versus Playmobil". The former allows modularity,
while the latter is just complex crap that allows you to do nothing other than
what the instructions say.

~~~
igl
Webpack does not glob-search against the filesystem like
grunt/gulp/brunch/broccoli/make. If you look for that: Sorry, webpack does not
"replace" simple tools like that.

Think of it as a tool executing require.extensions at build time. It's not
operating on files as much as it's looking directly at the source-code AST.
That makes it more complex to get into over the glob tools but it's worth it.

It's also just as modular as anything else:
[http://npmsearch.com/?q=loader%20AND%20keywords:webpack](http://npmsearch.com/?q=loader%20AND%20keywords:webpack)

------
sakopov
I don't see the hype behind build tools. I still use Grunt on just about any
project because I can just copy/paste the entire build process from another
project and never come back to it again. Don't see much point in switching to
anything else.

~~~
BinaryIdiot
Honestly there isn't much point. You can do the same stuff on grunt, gulp and
apparently webpak. Personally, to avoid the extra mountain of dependencies, my
newer projects just use scripts now to do building and I just simply reference
the same depdencies grunt and all wrap. It's quite easy.

Honestly there is _some_ utility to using these build systems as they make it
a _tiny bit_ easier than just writing a script...but that's about it. It's
really easy to write your own scripts to do the same thing with barely any
extra code.

~~~
petetnt
> my newer projects just use scripts now to do building and I just simply
> reference the same depdencies grunt and all wrap

Which is basically reinventing the wheel for the Xth time, but now with your
spin on it. Don't get me wrong, I have nothing against spinning a script or
two for building, but as soon as you share them with others there might be
some problems. Modern build systems have pretty thriving ecosystems which
means less time doing stuff which is out of the development time. Thriving
ecosystems mean that many are already familiar with the tools, which means
less time for them to get a grasp of your project. And so on and so on. There
are many benefits of using commonly used tools besides just running few simple
or complex scripts.

~~~
BinaryIdiot
> Which is basically reinventing the wheel for the Xth time, but now with your
> spin on it.

False. Do you consider calling a function versus setting a property, even if
they use the same amount of lines of code, reinventing the wheel? I sure
don't. It didn't take long at all for me to write and npm already provides a
way to run scripts so I can still do `npm run build`, etc just as if I typed
`grunt build`.

> Modern build systems have pretty thriving ecosystems which means less time
> doing stuff which is out of the development time. Thriving ecosystems mean
> that many are already familiar with the tools, which means less time for
> them to get a grasp of your project. And so on and so on. There are many
> benefits of using commonly used tools besides just running few simple or
> complex scripts.

The vast, vast, _vast_ majority of Grunt and Gulp plug-ins simply wrap
existing libraries, make a call to those libraries with the options you define
in Grunt or Gulp and then move to the next step when it's finished. That's it.

When I moved a web app from Grunt to my own script, that still used the same
dependencies, the amount of code was almost the same minus all the grunt
dependencies.

------
hoodoof
I feel sorry for the developers after reading all these comments. Why would
they continue with such a project that gets such little love?

~~~
mikegioia
The comments here are not indicative of the developers at-large. This is
mostly posturing to validate decisions to use other tools.

I love Grunt, I understand the complaints but it's a great system that's easy
to understand and work with. It's not unlike Makefiles but the learning curve
is lower with Grunt.

------
dereke
I am so pleased I abandoned grunt/gulp. Life is so much simpler with simple
build commands. Now I just run whatever I need using npm run.

~~~
progx
For simple things, yes npm run is a better option. But with more and more
Tasks i prefer cleaner and better readable solution.

Depending on the kind of project and tasks i use grunt / gulp or webpack.

~~~
dereke
I've not found anything that can't be accomplished with npm run. I mostly use
browserify, the commands for which can easily be run from a single line. For
more complicated things all I have to do is create a js file and add it to the
scripts object. It is really much simpler than grunt/gulp make it out to be.
AND I don't have to rely on plugins being available I can use any node module.

------
afloatboat
Lately the decline in popularity of Grunt has been more and more noticeable
for me. When adding new packages there are always usage instructions for Gulp,
sometimes webpack and alternatives as well but Grunt seems to be notably
absent. I'm contemplating switching to one of the more popular task runners,
but that would mean having to rebuild a working flow.

The question also remains what happens when you have to revisit an existing
site in x years. Will all the packages still be available, do I have to go
back to node version x and will everything still work on Windows/Mac OS
version y?

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

~~~
Jean-Philipe
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).

~~~
CraigJPerry
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!

~~~
foldr
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.

~~~
sciurus
Can you share any of those tricks?

~~~
foldr
[https://news.ycombinator.com/item?id=10543908](https://news.ycombinator.com/item?id=10543908)

------
neeel
I spent a minute scanning that website and I still don't know what it does. Is
it that hard to have a link along the top leading to an ELI5 blurb

~~~
Jgrubb
It's a build tool, written in node, so it was the first front end build tool
that saw wide usage 3-4 years ago. Used for things like concatenating and
minifying your CSS and JS for production.

It was succeeded by Gulp, which was succeeded by Browserify, which was
succeeded by Webpack, and then I moved to the backend because fuck this shit.

------
koolba
I have yet to find a use for Grunt that would not be better served with either
a more modern replacement or, more commonly/simply/pleasantly, an older
replacement like plain old 'make'.

------
avolcano
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...](https://github.com/thomasboyt/monotron/blob/master/Gruntfile.js)

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.

------
moron4hire
People keep saying "every grunt package makes its own way of doing things." I
have not found that to be the case at all. Grunt has a lot of ways to specify
groups of files, and many packages only show example usage for one of them,
but they are actually largely interchangeable.

I'm a little incensed at the speed of it. It is very slow, for no apparent
reason. But now I'm also wondering if it's not grunt's fault and actually the
NPM ecosystem's fault for being way too dependency happy. I got a complaint
from Windows about file name lengths being too long. Not in 20 years of using
Windows have I seen this error but on corporate copy-folder-as-version-control
network drives and NPM packages. So I'm concerned it might be spending most of
its time just crawling my node_modules folder, because I only just now thought
of this wrinkle and haven't stopped posting long enough to go do anything
about it.

~~~
DCoder
The "file name too long" was an issue in npm v2, where each module installed
its dependencies inside itself, recursively, leading to enormous
node_modules/foo/node_modules/bar/node_modules/baz/node_modules/quux/node_modules/...
chains.

npm v3 was an attempt to fix this so it now tries to install all modules and
their dependencies in the top level directory, unless there's a version
conflict, in which case it falls back to the old behaviour. npm v3 also got
slower, because to fix the folder chains it changed how the packages are
downloaded and installed.

It sounds like your node_modules were installed by npm v2 – you can try nuking
your entire node_modules folder, ensuring you have npm v3, and letting it
install your dependencies again. If your guess about grunt's performance
problems is correct, this might improve your build experience.

~~~
moron4hire
It cut it some, but not enough. Only about a 33% savings, i.e. went from 15 to
10 seconds, meaning it's still too long.

Uuuuugh, extremely vexing.

------
msimpson
Well since this has seemly turned into a forum for build tool gripes, I'd like
to note that no build tool is the best build tool. It simply comes down to
what's maintainable for you and your team.

------
gidan
you don't need grunt [https://medium.com/@julesbou/you-don-t-need-
grunt-a486059153...](https://medium.com/@julesbou/you-don-t-need-
grunt-a48605915319)

------
xmlninja
brunch.io ftw. its been out there the whole time, way easier than grunt and
gulp.

~~~
mikewhy
Brunch is great but last I used it there was no support for NPM modules. So I
built Parched on top of Gulp to mirror the Brunch experience.

------
bwd1992
Versioning at it's best

------
kdabir
better late than never :)

~~~
lox
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?

------
ckissi
Something I use daily, one of my favorite tools.

