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.
Thank you for your hard work! Don't listen to the haters. A lot of hackernews seems to be hipsters who dislike anything that's not the latest, most obscure technology to be using.
Grunt is solid, and does a great job at helping front end devs do their work. For people just getting into using a task runner, there are a lot of tutorials and S/O questions out there to help them learn as well.
Thank you for making my life as a developer so much better.
I did not know about the "hate" before visiting this thread... and I don't get it and now feel a bit sad reading all this. I was using Makefiles, npm commands and custom scripts for quite a while, and they were a pain to maintain! With Grunt I can just throw in a couple of plugins and I'm good to go! I'm using it for more than just building my apps.. I do all configuration and generation of new source-files etc with it, and it is awesome.
Started using Grunt 2 years ago, still doing it: simple CLI, neat documentation, lot of plugins. Thank you for working on it, I don't know what are the current trends but Grunt is still doing its job perfectly for what I'm working on so I'll continue to use it.
Thanks a lot for your hard work and keeping the project stable. The Infor CRM mobile team added grunt to our project back in July of 2013. I have probably written about a dozen plugins and custom tasks internally. The plugin API docs are a great resource. I love the configuration first approach with the ability to fall back to code if needed. It has really treated us well.
I also gave a presentation at our partner conference a year and a half ago on using grunt for development. Keep up the great work!
Congrats on the release! Grunt has saved me tons of time over the years. One of the things I admire about Grunt is the docs. They are well organized and clear.
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.
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
I went through this in the last couple of weeks. After about a week of infuriating behaviour trying to get gulp/grunt working even remotely how I wanted (eg vendor stuff split so builds don't take 10 seconds) I decided to give webpack a shot.
For anyone else in this position, sorry to the gulp/grunt guys, but skip them - go straight for webpack. It's still taken a lot of work to get a config that works nicely for my usecase, but all in all the experience was really good and I was 80% of the way there in no time at all.
Grunt was nasty as hell, and clearly didn't learn any of the lessons from, say, proper Makefiles from the UNIX world over the past 30 years.
Gulp is a looooot better, especially when I have things like Foundation 6's zurb-template, which is basically configured out of the box how I setup my Foundation 5 era projects.
I don't care how big a Gulp file is if I'm not the one having to do major maintenance on it.
Holy crap! I left a company 6 months ago and we were using Gulp there, and it was, as far as I am aware, the hot thing to use (I'm no front-end dev). Now you're telling me it is obsolete?! Javascript world is silly.
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.
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?
The 800 lines are you or your team's own fault; it's just a file run in NodeJS, it's trivial to separate it in task-specific files and load them with either `require` or one of the `loader` projects. Build tooling (what Grunt is) configuration, maintenance and maintainability is also the responsibility of developers.
Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.
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.
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.
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.
Because haters are always more vocal than the average user; complaining is easier (and easier to trigger) than praise.
The Grunt team compares the complaints with the actual amount of users and realizes it's a small (but vocal) minority, and that besides those, tens of thousands of projects use and depend on Grunt existing and staying maintained.
My previous project used Grunt because at the time it was the only tool existing (besides maybe using NPM directly, but using that for web projects wasn't hip yet at the time). We looked at Gulp for a while, realized that yes it would be a more compact configuration and such, but at the same time that it'd cost two weeks to convert the project to gulp without much advantages - builds were a few times a week, so no reason to move to Gulp to speed that up by a few seconds.
A very simple thing that Make does is when you run `make` it will only run the recipe if something has changed. Using npm scripts eliminates this (as I'm guessing gulp does as well).
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?
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'.
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.
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.
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.
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.
[+] [-] vladikoff|10 years ago|reply
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.
[+] [-] kdamken|10 years ago|reply
Grunt is solid, and does a great job at helping front end devs do their work. For people just getting into using a task runner, there are a lot of tutorials and S/O questions out there to help them learn as well.
[+] [-] andersevenrud|10 years ago|reply
I did not know about the "hate" before visiting this thread... and I don't get it and now feel a bit sad reading all this. I was using Makefiles, npm commands and custom scripts for quite a while, and they were a pain to maintain! With Grunt I can just throw in a couple of plugins and I'm good to go! I'm using it for more than just building my apps.. I do all configuration and generation of new source-files etc with it, and it is awesome.
<3
[+] [-] ArmandGrillet|10 years ago|reply
[+] [-] ericwood|10 years ago|reply
[+] [-] paulojreis|10 years ago|reply
May whatever supernatural entities you believe in be with you, man. I deeply, deeply thank you for your work.
[+] [-] skeeterbug|10 years ago|reply
I also gave a presentation at our partner conference a year and a half ago on using grunt for development. Keep up the great work!
[+] [-] voltagex_|10 years ago|reply
[+] [-] alistproducer2|10 years ago|reply
[+] [-] steveax|10 years ago|reply
[+] [-] hauschi|10 years ago|reply
[+] [-] igl|10 years ago|reply
Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames... Looking forward to whats coming next.
[+] [-] rkwz|10 years ago|reply
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
[+] [-] aidos|10 years ago|reply
For anyone else in this position, sorry to the gulp/grunt guys, but skip them - go straight for webpack. It's still taken a lot of work to get a config that works nicely for my usecase, but all in all the experience was really good and I was 80% of the way there in no time at all.
[+] [-] DiabloD3|10 years ago|reply
Gulp is a looooot better, especially when I have things like Foundation 6's zurb-template, which is basically configured out of the box how I setup my Foundation 5 era projects.
I don't care how big a Gulp file is if I'm not the one having to do major maintenance on it.
[+] [-] uhtred|10 years ago|reply
[+] [-] scotty79|10 years ago|reply
[+] [-] nailer|10 years ago|reply
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?
[+] [-] Cthulhu_|10 years ago|reply
Of course, the async thing (and such) is something I agree with, newer tooling has iterated and improved on Grunt.
[+] [-] drinchev|10 years ago|reply
Webpack is amazing tool, but it's not a task runner like gulp.
[+] [-] chadscira|10 years ago|reply
[+] [-] sakopov|10 years ago|reply
[+] [-] BinaryIdiot|10 years ago|reply
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.
[+] [-] hoodoof|10 years ago|reply
[+] [-] mikegioia|10 years ago|reply
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.
[+] [-] Cthulhu_|10 years ago|reply
The Grunt team compares the complaints with the actual amount of users and realizes it's a small (but vocal) minority, and that besides those, tens of thousands of projects use and depend on Grunt existing and staying maintained.
My previous project used Grunt because at the time it was the only tool existing (besides maybe using NPM directly, but using that for web projects wasn't hip yet at the time). We looked at Gulp for a while, realized that yes it would be a more compact configuration and such, but at the same time that it'd cost two weeks to convert the project to gulp without much advantages - builds were a few times a week, so no reason to move to Gulp to speed that up by a few seconds.
[+] [-] progx|10 years ago|reply
[+] [-] TheLogothete|10 years ago|reply
[+] [-] dereke|10 years ago|reply
[+] [-] progx|10 years ago|reply
Depending on the kind of project and tasks i use grunt / gulp or webpack.
[+] [-] Touche|10 years ago|reply
[+] [-] dimgl|10 years ago|reply
[+] [-] afloatboat|10 years ago|reply
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|10 years ago|reply
[+] [-] neeel|10 years ago|reply
[+] [-] koolba|10 years ago|reply
[+] [-] avolcano|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] msimpson|10 years ago|reply
[+] [-] gidan|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] xmlninja|10 years ago|reply
[+] [-] mikewhy|10 years ago|reply
[+] [-] bwd1992|10 years ago|reply
[+] [-] kdabir|10 years ago|reply
[+] [-] lox|10 years ago|reply
[+] [-] ckissi|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]