Live data from Hacker News

Grunt and RequireJS are out, it's all about Gulp and Browserify

100percentjs.com

21–30 of 163 posts

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#22

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#23
The main issue I have with Grunt and other frameworks/build tools is plugin authoring. Can't we just put this stuff in Make files and be done with it? I know, I know, Windows. But it seems like an awful lot of time is wasted building plugins that are just dumb wrappers for CLI options. Or worse, the tool's options get buried deep within the framework, ramping up the learning curve. As a recent example, I stopped using the Grails' resource plugin, and just compiled my static assets outside of Grails. The workflow became simpler because they didn't know about each other--I could use each tool to its full potential instead of relying on often incomplete plugins.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#24
I've been using a different strategy lately: no explicit build process at all, just use middleware (like browserify) to automatically compile/compress/concatenate, and an HTTP cache in production to store the results (either middleware, or external such as nginx/Varnish/CloudFlare/whatever).

This helps with the principle of minimizing divergence between development and production environments.

It's worked well for me for small projects, but maybe there are issues scaling up? Has anyone else tried this approach?

One interesting possibility is make use of the Gulp ecosystem. You could imagine "gulp-middleware" that lets you use any Gulp compatible module on the fly.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#25

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.

Believe it or not there are people in the world who aren't technical enough to use Grunt or Gulp, because they are much more complicated than Make... Mindblowing, I know.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#26
I like to set up my node apps such that no matter what the build setup is, no matter what the dependencies are, you can execute `npm run dev` to get started.

Inside package.json, this will look something like:

    scripts: {
        "dev": "npm install && make && node lib/server.js"
    }
The cool part about putting this in package.json is that it will install first so you get all the dependencies and devDependencies, and then npm sets up the PATH so that you can use all the binaries from all the dependencies you have installed. So you could replace `make` with `grunt` or `gulp` or whatever. And the `npm install` step only makes external requests if you're missing dependencies; when you already have everything you need, it quickly exits.

Then getting new developers up and running, even if the build setup changes is the same one and only step. In addition, if you pull new code and the dependencies change, you don't have to remember to run `npm install` because you're doing it every time the server starts.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#27
post #3

Gulp looks very interesting. Browserify vs. RequireJS seems more complex to me, though - it isn't difficult to use RequireJS in the CommonJS pattern. When I tried Browserify it was incredibly slow to build - but that might have been me setting it up wrong in Grunt...

I just started using browserify after using RequireJS for a while, and also got annoyed at how slow builds were. Then I searched around and found watchify, and it's great! Build time during development isn't painful at all anymore.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#28

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Why even use Make? I just use shell scripts for automation.

The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#29
The one thing that keeps me from using browserify or webpack or the likes, is dev time debugging. It's not very useful to find that line 13729 of script.js threw an exception.

Source maps may help, but many browsers don't support them, and I want to be able to debug everywhere. Plus, when the browserified js actually came from Coffeescript or TypeScript or the likes, I already have source maps in place. Can browserify source map my source maps?

Is there a solution to this? How do browserify fans do this?

I guess what I'd like is for browserify to have a mode that removes the require()s from my .js files and generates a bunch of script tags in the right order.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#30
post #7

There have been numerous posts stating that Gulp is faster than Grunt. However, the "faster" argument needs to be qualified with "under these conditions ____". Even better, here's my configuration. Here's the processing time of x and of y. With JavaScript builds in particular, it's important to separate when the task running is used. At least in my workflow, I have two distinct times: 1. Development time 2. Build tim…

I've used Grunt for most projects in the last year, and just tried Gulp for my newest.

Gulp seems snappier overall to me for tasks that watch a source directory with coffeescript or sass files in it. Maybe it's grunt-watch vs gulp.watch().

I think Grunt touches the filesystem more than Gulp which could potentially be a bottleneck. The creator (IIRC) of Gulp made a slideshow[0] .

Here's an example Gruntfile[1] generated with Yeoman and generator-angular. And a Gulpfile[2] which does fewer things (no production build yet).

[0]: http://slid.es/contra/gulp

[1]: https://github.com/jjt/dramsy/blob/master/client/Gruntfile.j...

[2]: https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js

Post reply on HN