Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe stop using Grunt?

medium.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Maybe stop using Grunt?

#21

Post by acdlite »

jdlshore wrote: post #17
greggman wrote: post #8

I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.

Grunt doesn't do dirty-file dependency checking. Gulp does, sort of, but it's awkward. There are many, many build tools in JS-land. Grunt and Gulp happen to be the most popular. (This isn't really due to technical merit. They're popular mostly because they're popular.) My personal favorite is Jake, which is a classic Rake-like (or Make-like) tool.

Or instead of a Make-like tool you could just use Make itself :) Works really well.

Re: Maybe stop using Grunt?

#22

Post by MichaelGG »

How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem.

I hack around it by keeping node_modules around as a special resource on a custom build server and symlinking it in, but that wouldn't work with a proper "start from zero" build system.

Re: Maybe stop using Grunt?

#23

Post by jessaustin »

nostrademons wrote: post #18
jessaustin wrote: post #6

...I would like the task system to provide an abstraction for pipelining tasks. (Perhaps gulp helps with this?) Hmmm, perhaps someone needs to look at any gulpfile ever written, anywhere. gulp.src('src') .pipe(this()) .pipe(that()); Maybe it's frustrating for anyone who spent "18 months" hacking grunt, but gulp really is better. Both tools are built on node for Pete's sake; async really shouldn't be that hard.

There is also the 'scripts' section of your package.json, 'npm run', and UNIX pipes: scripts: { "do_something": "this | that" } $ npm run do_something See also http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt...

Yes while gulp > grunt, in many cases npm by itself is what you want. gulp.watch(), in particular, seems more difficult to use than the watch facility built into many (but not all) node modules. Also something like Browserify must be somewhat shoehorned into gulp. It might be worth it to look at what gulp has that npm run is missing? Maybe it doesn't need to worry about streaming files, but the notion of some tasks depending on arbitrary sets of other tasks (a generalization of npm's "pre-" and "post-") seems pretty handy.

Re: Maybe stop using Grunt?

#24

Post by digitalzombie »

greggman wrote: post #8

I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.

You can do dependency check via Bower + NPM.

Your grunt or glup file can run a command to check for those dependency and update it via bower and npm.

Bower are for front end dependency check and NPM are for the backend dependency check.

Grunt and Glup are more of a task management system where you run tasks. Such as transpiling your jade/haml/sass, minifying your js, running your test cases. You can run these tasks in specific orders.

There's also gruntfile too but it's been a while since I've use these things. I think gruntfile are for grunt specific module for tasks though, so it'll dependency check grunt modules?

I'm a recovering frontend guy, well at least I did front end in a few gigs that were suppose to be fullstack.

Re: Maybe stop using Grunt?

#25

Post by mike_hearn »

I feel I must be missing something here, but ...

The inability to specify config asynchronously turned into a disaster. Our primary need for async config was specifying temp directories for tasks to operate in. We used tmp, which does not have a synchronous api ...... I would like the task system to provide an abstraction for pipelining tasks

Is this abstraction not normally just called a program? Where you can do something like:

val tmp = makeTempDir()

generateFoo(outputDir = tmp)

generateBar(inputDir = tmp)

etc?

How much of this complexity is fundamental and how much is people attempting to work around Node's inherent limitations and fully asynchronous APIs? Perhaps the author should check out something like Gradle instead?

Re: Maybe stop using Grunt?

#26

Post by andrewchambers »

Maybe I am missing something, but it seems like most of theses tools are working around the fact the windows doesn't come with make by default.

They are essentially reinventing the wheel for web developers who have never worked from the command line before.

Re: Maybe stop using Grunt?

#27

Post by woah »

mike_hearn wrote: post #25

I feel I must be missing something here, but ... The inability to specify config asynchronously turned into a disaster. Our primary need for async config was specifying temp directories for tasks to operate in. We used tmp, which does not have a synchronous api ...... I would like the task system to provide an abstraction for pipelining tasks Is this abstraction not normally just called a program? Where you can do so…

Gulp has no temporary directories.

Re: Maybe stop using Grunt?

#28

Post by lucaspiller »

MichaelGG wrote: post #22

How are all of you using any npm-based system combined with a continuous integration or clean build environment? It seems that a simple yeoman/grunt setup that just preprocesses some HTML and JS takes... a very long time. A minute or two just for the actual work. Plus 5-15 minutes for npm to make a thousand requests and write 10K+ files to the filesystem. I hack around it by keeping node_modules around as a special r…

Why does it matter if your build system takes a while? You shouldn't be pushing it to there until you are happy it works locally, at which point you can move on to the next task and forget about it.

Re: Maybe stop using Grunt?

#29

Post by Arnavion »

digitalzombie wrote: post #24
greggman wrote: post #8

I probably just don't have enough experience. I like the idea that Grunt and Gulp are written in JS so using JS to build JS seems like a win. But...., aren't build systems supposed to do dependency checking and just built the minimal amount of stuff? Maybe few JS projects are big enough for it to matter or maybe I missed where the dependencies are checked but AFAICT the default is to build everything always.

You can do dependency check via Bower + NPM. Your grunt or glup file can run a command to check for those dependency and update it via bower and npm. Bower are for front end dependency check and NPM are for the backend dependency check. Grunt and Glup are more of a task management system where you run tasks. Such as transpiling your jade/haml/sass, minifying your js, running your test cases. You can run these tasks i…

greggman is talking about dependencies between build targets (such as files or directories or projects), eg: "lib.js depends on lib.coffee" + "lib.coffee's last modified time > lib.js's last modified time" = "must run task that regenerates lib.js"

Re: Maybe stop using Grunt?

#30

Post by tieTYT »

falcolas wrote: post #19

I keep seeing people mention "a mess of shell scripts", and then use replacements which are dozens if not hundreds of lines of custom-configuration files. Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated. Not to mention that the ability to chain disparate tools and subshells can be incredibly elegant and powerful.

> Shell scripts, when you're not dealing with autotools generated script, aren't really that big, or even that complicated.

They're not always portable. Some people develop on windows.

Post reply on HN