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.
Thank you so much! I appreciate all the work you've put into Grunt even though I personally prefer Webpack, configuration, HotModuleReloading and I've been able to make it work with webcomponents and reactjs. At work we use Grunt so maybe this will help me at work but I am actively trying to convince my team to switch to Webpack.
don't listen to the haters, without grunt gulp would've never been possible. I still use grunt the majority of my legacy projects, and I appreciate grunts maintainability
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
> 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.
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.
Yeah I agree with most of the sentiment but I let it by when you go to the github repo and check out contributor statistics. Pretty much it's just sokra doing everything and he does it in his free time last I heard. I think webpack is missing the support it needs in regards to how much it's actually getting used.
I could not for the life of me get Webpack to bundle '.json' files that were require()d by some library code I was using. Of course, this functionality comes out of the box with Browserify.
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.
Do authors of these build tools actually sit down for a couple of months looking at things like Makefiles that have been around forever, perhaps even Maven, etc. Take all these things together and go "This is what sucks in all of them, and here's how we can do it better" and still cater for all the use cases that these tools are brilliant at.
It's like there's no thought put into these tools and nothing is built on computer science foundations. Like why are you using Json as the syntax? Ant build files were an abomination and Json really isn't offering anything better (actually way less), except a slightly more readable syntax for trivial use cases.
I think not even Node or NPM learned any lessons from older tools. Look at the recent leftpad fiasco. A decent part of it could have been avoided with namespacing (hello Maven groupIds!). npm didn't have it from day 1 and even now it's optional and basically unused.
When I saw that LiveScript was using Makefiles[0] to build, I was baffled. To me they were ancient and complicated C/C++ stuff. But when I looked into them, everything seemed rather straight forward, even a bit nicer than Gulp, because of the syntax.
Makefiles have some glaring issues that can't be easily fixed.
The big one is that they break if there are spaces in file or directory names.
Sure, you can argue spaces are bad practice. But they are common on OS X and windows. It's a little silly to use a build system that doesn't support them.
I don't get it, what part of Makefiles are missing in Grunt? I've set up a project pretty simply through Grunt without too many headaches (after grocking how to properly write base tasks)
The simplicity, plus Grunt has an entire ecosystem of already made tasks that none of them really work the same, so you have to learn the quirks of other people's code.
Its basically the NPM problem all over again, but as a build system, while also using NPM which doesn't make not not the NPM problem.
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.
It isn't obsolete. Webpack just reduces task runners even more, since webpack takes care of taking your source, copying your source to your build/dist/whatever directory, minifying everything, creating hashes in filenames, being able to update html with those hash names, etc.. Basically, if you can use `import` on a file in Webpack 2 or `require` in either Webpack 1/2 you don't need Gulp/Grunt to do that work.
I personally work on things that still need other aspects of the task runners.
I am sorry but if someone told me that the product which came out yesterday is obsolete then I'd understand that Javascript world is silly, but if at your company a product which was popular 3 years ago cool, then it's your company's fault.
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?
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.
You misunderstand what I meant. Nobody has written or suggested that webpack outputs script tags or AMD. I simply stated that webpack markets itself as using script tags and AMD as input, which is true: from the meta description on webpack.github.io:
"Webpack is a module bundler. It packs CommonJs/AMD modules i. e. for the browser"
If you use AMD as input you have to get updates to your libraries separately, and your libraries are bloated since AMD modules tend to use dependencies less.
Where does it say it uses script tags for input? The quote you mention says CommonJS/AMD. CommonJS is the de-facto standard these days. Typically, people write in ES6 imports, which then gets transpiled to CommonJS anyway.
It accepts AMD as an option, but honestly, I've been using webpack for about a month and I haven't come across a single library that recommends using AMD. It's just there as an option for those who need it. Most of the world has moved on from AMD due to its issues, so I can't really see your point.
You admit most of the world had moved on from AMD, but don't see why advertising AMD support as a main feature - to the point it's mentioned in the sites description - would dissuade people?
Being able to shim script tag libraries is mentioned in various places through the docs (and used to be even more prominent than it is now).
I'm responding out of charity here: you made an angry response, were shown to have misread the post, and haven't apologised. Be civil.
Mr. that was not my reply, and I didn't made a angry response... If you thought my characters conveyed angryness I apologize, I just critcized your points.
Re your original post, the 'damned' and 'what are you talking about' and not reading my post charitably (that I was lying rather than just reading the site description) seemed rude. Thank you for apologising.
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.
> 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.
> 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.
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.
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.
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?
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, and an additional point of failure (eg your own code).
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).
The bash script is easier for such a trivial job. Gulp and Grunt aren't better if that's all you're doing. They come in to their own when you have a large number of tasks to run. But even then, if you (and your team) prefer make then it's better to use make.
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!
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.
If that's all you want to do (concat, minify, convert es6/sass), then by all means, I do agree make is the simpler albeit slightly less maintainable and non-cross-platform solution. I use make for my quick static sites too.
But when you need more features like bundle splitting (app code and libraries live in separate files, for caching), cache-busting, lazy-loading, separate configs for production and development, etc. make doesn't quite cut it IMO.
One huge advantage is speed - Grunt relies on disc I/O and copying files to temp folders, while Gulp is based on streams and all your file transformations are done in memory.
(Just a personnal feeling) Gulp commands are more standardized, while in Grunt every plugin seems to develop its own way of doing things. And Gulp tends do do things faster.
But as you said, nothing wrong with Grunt. Indeed feeling the Javascript build tool fatigue , I'm seriously hesitating to do everything in a makefile
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 it was before the error. Dunno!
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.
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.
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.
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.