12 ms·
Grunt 1.0.0 released
- afloatboat 11y agoLately 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 11y agountil the new shiny thing comes and replaces that. I still don't understand what's wrong with grunt (or whats better with gulp).
- onion2k 11y agoThe 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).
- Jean-Philipe 11y agoI 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 11y agoYou 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 11y agoI 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.
- cristianpascu 11y agoI 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!
- codebeaker 11y agoThis 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.
- maxo123 11y agofor less it's a pretty easy fix: .pipe(less()) .on("error", function (err) { console.log(err); this.emit("end"); }) I presume, something similar will work for sass too.
- tangue 11y ago(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
- romankolpak 11y agoOne 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.
- tragic 11y agoIME, with enough dependencies in enough tasks, it can get very slow to start.
- kdabir 11y agobetter late than never :)
- lox 11y agoIs 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?
- igl 11y agoObsolete 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.
- chadscira 11y agoTotally agree, the key was loaders...
- scotty79 11y agoI 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.
- nailer 11y agoOne 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?
- Ciantic 11y agoMarkets 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.
- nailer 11y agoYou 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. You should also check out https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- avolcano 11y agoI 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.js 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.
- dereke 11y agoI 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 11y agoFor 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 11y agoI'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.
- thegayngler 11y agoI like the idea of npm run for scripts. I just added something to automatically run tests for specific products at work.
- Touche 11y agoA 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).
- dimgl 11y agoSame. It's really easy to do everything I need just using plain old CLI.
- neeel 11y agoI 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 11y agoIt'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 11y agoI 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'.
- bwd1992 11y agoVersioning at it's best
- xmlninja 11y agobrunch.io ftw. its been out there the whole time, way easier than grunt and gulp.
- mikewhy 11y agoBrunch 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.
- hoodoof 11y agoI feel sorry for the developers after reading all these comments. Why would they continue with such a project that gets such little love?
- TheLogothete 11y agoSupply and demand holds true for everything.
- progx 11y agoI like and use grunt, but i use other tools too.
- mikegioia 11y agoThe 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.
- Cthulhu_ 11y agoBecause 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.
- deleted 11y ago[deleted]
- sakopov 11y agoI 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 11y agoHonestly 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 11y ago> 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 11y ago> 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.
- vladikoff 11y agoHey! 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.
- voltagex_ 11y agoKeep doing what you're doing - competition is a good thing.
- maxo123 11y agoI don't personally use Grunt, but your attitude is highly commendable.
- alistproducer2 11y agoThanks for your hard work. I used your project for a little while and it was very helpful.
- ericwood 11y agoThank you so much for your work and dedication. Don't listen to the haters, Grunt is a fantastic tool <3
- hauschi 11y agoWell done, been using Grunt since end of 2012
- kdamken 11y agoThank 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.
- 11y ago
- moron4hire 11y agoPeople 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 11y agoThe "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 11y agoIt 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.
- ckissi 11y agoSomething I use daily, one of my favorite tools.
- deleted 11y ago[deleted]
- msimpson 11y agoWell 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 11y agoyou don't need grunt https://medium.com/@julesbou/you-don-t-need-grunt-a48605915319 https://medium.com/@julesbou/you-don-t-need-grunt-a486059153...