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

Why we should stop using Grunt and Gulp

blog.keithcirkel.co.uk

Post reply on HN
Print view View original

91–100 of 108 posts

Re: Why we should stop using Grunt and Gulp

#91

Post by zahary »

I'm still waiting for the day when the JS community will discover tup [1]. Tup's greatest strength is that is can discover build dependencies automatically by file I/O monitoring in any kind of compiler or build script.

Many source formats eventually gain the capability to include other files (e.g. jade partials) or reference them in other ways (e.g. you can check the size of an image while you are generating a Sprite CSS fragments) as part of the build process and this is where Grunt or Gulp or any other naive build system will fail immediately. Specialized build systems can handle the dependency checking for particular build targets (e.g. Cmake for C++), but tup makes it extremely easy to have proper minimal re-builds with any kind of compiler.

There is also an automatic re-build mode that's triggered as soon as you save the source file in the editor and it's a joy to use in web projects.

[1] http://gittup.org/tup/

Re: Why we should stop using Grunt and Gulp

#93

Post by fit2rule »

xrstf wrote: post #60
fit2rule wrote: post #59

Earlier quoted context omitted.

And its different for Windows users who want to use Grunt, how exactly?

It's different in the way that it's trivial to use npm to install grunt and run builds on Windows, but not trivial to get a Makefile to run (if you don't want to resort to running cygwin bashs all the time).

You can't use make to install grunt on Windows?

Re: Why we should stop using Grunt and Gulp

#94

Post by Already__Taken »

fit2rule wrote: post #93
xrstf wrote: post #60

Earlier quoted context omitted.

It's different in the way that it's trivial to use npm to install grunt and run builds on Windows, but not trivial to get a Makefile to run (if you don't want to resort to running cygwin bashs all the time).

You can't use make to install grunt on Windows?

You have to install make some how. That's the problem. You're tying all these cross platform tools together with something that isn't cross platform. Grats.

Re: Why we should stop using Grunt and Gulp

#95

Post by WorldWideWayne »

kenneth wrote: post #30

I simply use Make for all my web projects, whether it's a Ruby JSON API, or a React front-end. It's reliable, pre-installed everywhere, and can wrap anything in one consistent CLI. Why have to remember whether to type lein repl , pry , or rails console , when make repl will do everytime? Ditto, bundle install , npm install , lein deps => make deps . make server can easily wrap whatever command launches the server, ma…

> Why have to remember whether to type lein repl, pry, or rails console, when make repl will do everytime?

This is why I don't think the CLI is a very efficient interface for operating the computer. There are more commands than you can remember so, you're forced to take the commands that you can't remember or be bothered to type in and stick them into a file, thereby creating new commands that must be identified, understood and remembered by the next developer who should really only use them if they know all of the original commands in the file.

Re: Why we should stop using Grunt and Gulp

#96

Post by edraferi »

plingamp wrote: post #3
thesnider wrote: post #2

This article seems super weird -- do people actually use Grunt/Gulp to run a single command at a time? Most uses that I've encountered are along the lines of 'we've got this huge build process involving compass, sass, uglify, ng-annotate, and 13 other things', and Grunt/Gulp allow you to do the whole thing, automatically re-running on file changes, with a single command.

No, like you said Grunt/Gulp is useful when you are automating multiple tasks that are done repeatedly. The title of this article is total click bait.

The author's argument is actually "NPM is a better build tool than Grunt or Gulp."

He followed up with an extensive tutorial on how to do complex builds with NPM [1]. The tutorial concludes with an example where NPM is used to:

* Take my JS and lint, test & compile it into 1 versioned file (with a separate sourcemap) and upload it to S3

* Compile Stylus into CSS, down to a single, versioned file (with separate sourcemap), upload it to S3

* Add watchers for testing and compilation

* Add a static file server to see my single page app in a web browser

* Add livereload for CSS and JS

* Have a task that combines all these files so I can type one command and spin up an environment

* For bonus points, open a browser window automagically pointing to my website

He accomplishes this with ~20 lines in the "script" object of package.json. The whole process is initiated with a single npm run dev command. He asserts that "to do the equivalent in Grunt, it'd take a Gruntfile of a few hundred lines, plus (my finger in the air estimate) around 10 extra dependencies."

[1] http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

[2] https://github.com/keithamus/npm-scripts-example

Re: Why we should stop using Grunt and Gulp

#97

Post by reitoei »

likeclockwork wrote: post #66

No. I refuse. I use CoffeeScript and SCSS and often install components via bower. I like grunt watch+serve+livereload to drive my development server environment. I like continuous testing with karma. Grunt helps me manage all of this centrally. npm simply does not have the functionality to be a legitimate replacement.

Agreed.

Re: Why we should stop using Grunt and Gulp

#98

Post by edraferi »

Fannon wrote: post #35

What NPM can't do is the async workflow of Grunt watch (or serve) and dynamically trigger specific (sub)processes in real-time. Turns out, this is the main way I'm using Grunt. Also some plugins are complicated (or dynamically) to configure. His examples were very simple, he could just put it into a batchfile aswell.

The author addresses this issue directly in his follow up post [1]. He describes two ways to get watch functionality when using NPM as a build tool.

First, "most tools facilitate this option themselves - and usually are much more in tune with the intricacies of the files that should be listened for. For example Mocha has the -w option, as does Stylus, Node-Sass, Jade, Karma, and others." These options are simply invoked when the tool is called from NPM.

Second, "not all tools support this, and even when they do - you might want to compose multiple compile targets into one task which watches for changes and runs the whole set. There are tools that watch files and execute commands when files change, for example watch, onchange, dirwatch, or even nodemon."

[1] http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

Re: Why we should stop using Grunt and Gulp

#99

Post by cheshire137 »

Dude's big example was running a single tool with their Grunt/Gulp setup. Who does that? I kept expecting the article to explain why using Grunt or Gulp was a bad thing when I want to do multiple things at once without running multiple scripts. What if I want my JavaScript to be hinted/linted, concatenated into one file, and minified every time I save a JavaScript file, plus tests should be run, plus I want the final JavaScript file to be saved in my build/ directory?

Re: Why we should stop using Grunt and Gulp

#100

Post by _Marak_ »

If you actually need to maintain well-used JavaScript projects, tools like Gulp are extremely important and time-saving.

Here is what the build process looks like for the faker.js project:

return gulp.src('../index.js')

  .pipe(browserified)
  
  .pipe(rename('faker.js'))
  
  .pipe(gulp.dest('build/'))
  
  .pipe(gulp.dest('../examples/browser/js'))
  
  .pipe(rename({ extname: ".min.js" }))
  
  .pipe(uglify())
  
  .pipe(gulp.dest('build/'))
  
  .pipe(gulp.dest('../examples/browser/js'))
  
  .pipe(rename('../examples/browser/js/faker.min.js'));
});

https://github.com/Marak/faker.js/blob/master/build/gulpfile...

If you ask me, Gulp provides a pretty elegant syntax. Before using Gulp we had a custom script to build the project. Using Gulp has been much better.

His comments about the Gulp ecosystem not fully supporting streaming is true. The onus of implementing streaming correctly in plugins is on the plugin author. Unfortunately, there are a few plugin developers who are making bad plugins. You have to understand which libraries you are installing before blinding running npm install.

Something which is very interesting about Gulp is it's underlaying Virtual File System (Vinyl) https://github.com/wearefractal/vinyl The entire ecosystem is now improving as more Gulp plugins are being decoupled into vinyl virtual file system adapters ( think sftp / http / ftp / webdav )

Post reply on HN