
Grunt and RequireJS are out, it's all about Gulp and Browserify - codecurve
http://www.100percentjs.com/just-like-grunt-gulp-browserify-now/
======
AndyKelley
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.

~~~
Raphael
Clever setup.

------
contrahax
Author of gulp here. I've rewritten the example from the blog post to follow
gulp best practices.
[https://gist.github.com/Contra/8780398](https://gist.github.com/Contra/8780398)

The code from the post is misleading/outdated.

~~~
blezek
Many thanks from one who fought through the outdated source in the OP.

------
mjackson
On a project that I'm working I recently converted a ~260 line Rakefile into
~150 lines of gulp ... and our build is now almost instantaneous (took a few
seconds to do with Ruby, mainly because we had to shell out to things like the
less compiler). Oh, and we were also able to build our gulpfile.js in just a
few hours after hearing about it for the first time.

I never went the Grunt route because I just can't get used to programming with
massive, multi-tiered object literals. If you've ever seen a Gruntfile, you
know what I mean. It's all configuration, very little real code.

With gulp, code trumps configuration. And the result is incredibly concise and
fast. I would definitely encourage anyone who has been looking for a decent
build system for JavaScript to give gulp some serious consideration. We were
pleasantly surprised with the community support as well. There is already a
wide array of community plugins for gulp that support many common use cases.

------
jondot
And again I'll remind people what happened in Java land:

ANT -> Ivy/Maven -> Gradle

I'll state it clearly: Grunt. is. Ant. It's a mess to follow a build script
and a ritual to make it work in a real life project.

I expected a tool like gulp to come sweeping in and it did, I'm extremely
happy about that and started migrating away from the horrible tooling that is
Grunt.

I never understood how people can tolerate Grunt. Long live gulp and common
sense!.

~~~
brokenparser
I'd say Grunt is Maven because IDEs have no way to figure out beforehand what
the build process will do.

~~~
lmm
That's the opposite of Maven. IDEs know exactly what a maven project will do
(unless you're using plugins the IDE doesn't know about), because a maven
build only does a very limited set of things (it mostly just compiles the
source in src/main/java into target/). Which is what makes it great.

------
skrebbel
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.

~~~
indolering
Unable to find the link/name at the moment but there is a method (it isn't
vanilla source-map) for this which basically wraps the modules into self-
executing functions and it shows up in Firefox and Chrome as distinct files.
It was related to source-map but not

However, I have found Chrome and Firefox's support to be buggy.

~~~
pyre
Maybe you're thinking of webmake. The sourceURL lines that it uses in the
eval() sections resolve correctly on Chrome, but Firefox+Firebug don't seem to
work for me.

The webmake site references a bug in Firebug that was resolved ~1 year ago,
but I still have issues it with. I end up swapping back and forth between
Firefox+Firebug and Chrome to get all of the debugging features that I want.

------
mehulkar
This post reminds me of the joke about the Native Americans getting ready for
winter[1]

[1]
[http://voices.washingtonpost.com/capitalweathergang/2008/11/...](http://voices.washingtonpost.com/capitalweathergang/2008/11/winter_weather_joke.html)

~~~
blowski
That's great - I can use that whenever the topic of 'the echo-chamber' comes
up.

------
emilis_info
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.

~~~
chubot
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.

~~~
noir_lord
Your post just punched me in the gut.

I've spent the last couple of weeks playing the "front end build tool dance"
(primarily a back end dev) to find a system I like and it simply _never
occurred_ to me I could write my own as a quick bash script or python if I
think it'll grow.

That's an embarrassing oversight.

~~~
chubot
Good :) Shell scripts will be around for a lot longer than any of those tools.

Shell is also significantly _easier_ and _faster_ , if you just want to say
run jslint, then minify, etc.

I program in lots of languages, so shell is the first tool I reach for.
Learning the language is enough; I don't have time for all these quirky build
and deploy tools.

~~~
noir_lord
The embarrassing part is I automate everything with the shell and still never
thought of it :).

------
noname123
This is a tangential question, but how do front-end people feel about the
constant change in the field?

I worked in the front-end and followed the trends for years and have found the
changes difficult to follow. In 1997, the rage was VB and lots of cottage
companies set up and advertising custom ActiveX widgets, on the web one had to
learn ColdFusion and HTML/CSS. In early 2000's, VB6 was retired in favor of
.net and a painful migration/learning-curve followed. Meanwhile, PHP was
gaining traction so as a front-end person, one had to also start learning the
LAMP stack in addition to asp and also CSS hacks to get different browsers to
render mocks. Then around 2005ish is when AJAX/Web2.0 started gaining
traction, one suddenly had to learn the burgeoning frameworks of the time,
jQuery/Mootools/Prototype/Dojo/YUI/Sencha (at the time, no one knew which
framework was going to win. I spent a lot of time on Dojo before moving to
jQuery which started to gain the most traction); at the same time, web sockets
still wasn't secure enough so there was also a lot of demand for
Flex/Flash/Silverlight. Then around 2008-2009, when HTML5 started becoming
more popular, Flex/Silverlight became obsolete; JS mobile frameworks such as
PhoneGap and jQuery Mobile grew in favor but later in 2010-2011, they fell out
of favor due to "responsive design" frameworks such as Bootstrap. Not to
mention native mobile tech stack such as iOS and Android. In addition, around
the same time, next-gen JS MVC built on top of jQuery have popped up such as
Backbone.js, AngularJS and Ember.js and it's not certain who is going to win
out this time in the year of 2014. On top of those, there are now JS AMD
loaders (Require.js) and build/integration tools, Grunt that one needs to set
up for a project which it seems may also be falling out of favor. Finally, new
video/sound/web-socket standards revolving around HTML5 standards is demanding
new learning bandwidth.

I'm frankly overwhelmed of learning and being exposed to new technologies. The
physical draining feeling of learning new keywords to fulfill the same urges
is as if I have watched 15 years of porn following from the grainy days of
Jenna Jameson on VHS to the heady-days of Internet dial-up gonzo porn of the
early 2000's that really explored anal (Gauge, Taylor Rain) to the streaming
flash videos of Web 2.0 (Sasha Grey) to the now completely splintered and
social-mediafied porno-world with all the mind-numbing categories under the
sun (reality, high-art, webcam etc). I'm simply drained and spent.

There certainly has been changes in the field in back-end, from Java applets
to Spring and Struts to now Scala and Clojure on JVM or transitioning the
scripting language from Perl to Python, and adoption of Boost in C++. But I
didn't have to re-learn old concepts and the changes were incremental instead
of revolutionary; and the whole shift from declarative programming to
functional languages is not new as you've learned Haskell/Lisp in undergrad
anyways. Whereas what I had learned as a 9 year old on Turbo C doing DOS
programming would still apply today, what I learned then for VB4 and
HTML/Frontpage is now completely useless.

I'm scared for my brain as I get older as I may not have the time nor the
energy to devote myself every year to relearn all of these new tech. I'm
wondering for people who are above the age of 30, how do you deal with it?

~~~
peter_l_downs

        I'm frankly overwhelmed of learning and being exposed to new technologies.
        The physical draining feeling of learning new keywords to fulfill the same
        urges is as if I have watched 15 years of porn following from the grainy
        days of Jenna Jameson on VHS to the heady-days of Internet dial-up gonzo
        porn of the early 2000's that really explored anal (Gauge, Taylor Rain) to
        the streaming flash videos of Web 2.0 (Sasha Grey) to the now completely
        splintered and social-mediafied porno-world with all the mind-numbing
        categories under the sun (reality, high-art, webcam etc). I'm simply
        drained and spent.
    
    

Uh...

~~~
n1ghtmare_
The man really knows his porn.

~~~
ElongatedTowel
Moral of the story is, if you spend the time you're watching porn on
programming instead you would be a master of all these technologies.

~~~
stuff4ben
you could also say he would be the "master of his domain".

------
Maxious
One tiny benefit of Gulp - Grunt wasn't packaged on Debian because of JSHint
which relied on JSLint which had the "The Software shall be used for Good, not
Evil." licence clause
[http://en.wikipedia.org/wiki/JSLint](http://en.wikipedia.org/wiki/JSLint)

~~~
STRML
The people in that Debian thread[1] completely misunderstand how Node packages
work - the 'jshint' dependency is in the 'devDependencies' section of the
package, which means it is _not_ installed by default when `npm install
--production` is used, which is how it should be packaged in the first place.

Refusing to package Grunt for Debian because it has a devDependency on JSHint
is like saying that Node can't be packaged because one of the contributors
used a non-free IDE to develop it. No actual non-free software is distributed
as part of the code.

Regardless, it's not a big deal to `apt-get install nodejs; npm install -g
grunt`.

[1] [http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=673727](http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=673727)

Additionally, I'd like to take this moment to remark that dcrockford is being
completely pigheaded by not removing the "for good, not evil" part of the
license of JSLint. It is completely divorced from reality and detrimental to
free software in general. I understand that he thinks he is being an idealist,
but there are better ways to promote doing good in the world than assuming
that somehow, somewhere, evil-doers are writing evil Javascript (and they
would get away with it too!) if only they weren't blocked by your license and
could lint their code.

~~~
pilif
_> Regardless, it's not a big deal to `apt-get install nodejs; npm install -g
grunt`._

Unless of course you have automated the installation of software on your
systems. At this point it's somewhere between confusing, mildly annoying and
terribly annoying, depending in what route you go.

You could make a Debian package yourself, or you use your configuration
management system to install the npm package (assuming it supports npm or
there is an npm plugin)

Both have disadvantages: there are tools to automatically create debs from npm
packages, but I've seen bugs with them causing various levels of pain. Or you
make the package yourself and get blasted by full-on bureaucracy that is the
Debian package build tool chain.

Going the configuration management route has the disadvantage that now
multiple pieces of software are used to install packages which is a bit
inconsistent and might be confusing to other users.

Yeah. Not a big deal, but getting stuff directly from your OS vendor is VERY
convenient.

I agree with your reasoning about the devDependency though. That makes not
much sense.

------
untog
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...

~~~
akbar501
I think the author oversimplified the choice of Browserify and RequireJS. They
have some overlap, but are not 100% replacements.

Both have the concept of modules, and they overlap in this area.

Browserify allows you to use Node style modules in the browser.

RequireJS allows you to asynchronously load parts of your app, while
Browserify bundles all JS into a single file.

~~~
cheapsteak
To further clarify, RequireJS also allows you to bundle all JS into a single
file via the r.js build step.

If you're planning on going that route with RequireJS, you should also look
into AlmondJS:
[https://github.com/jrburke/almond](https://github.com/jrburke/almond)

~~~
STRML
If you do end up using RequireJS, using r.js is practically a requirement.
Declaring asynchronous dependencies in a production build is murder for
performance.

Grunt's grunt-contrib-requirejs[1] does a good job of traversing your
dependency graph with r.js and building out a single bundle, but it is not
especially quick; it takes about a full 3-5s on my current build. But it's a
hell of a lot better than the alternative.

Of course, if I were to start over, I'd run browserify and either build the
files in a build step with Grunt or Gulp, or just use browserify-middleware[2]
and skip the build step entirely (with something like node-sass for styles).

[1] [https://github.com/gruntjs/grunt-contrib-
requirejs](https://github.com/gruntjs/grunt-contrib-requirejs) [2]
[https://github.com/ForbesLindesay/browserify-
middleware](https://github.com/ForbesLindesay/browserify-middleware)

~~~
leobelle
Well you are right for most front-end application, but what is nice to have is
modules, and you don't want almond for that. And by modules I mean you have
major pieces of application code that you don't want to load until the user
triggers an intent to need that stuff. If you have a single page application
and most of your users are just consuming content, why load all the config and
editing tool JavaScript? Make modules for pieces of your app, and then if
needed load the JavaScript for those things. User clicked edit? Ok now load
the JavaScript for that stuff.

Browser caching is nice, but if you're doing a continuous
integration/deployment type, you're probably invalidating your cache often. If
you use a single build you may be invalidating all of your JavaScript for each
tiny deploy even though maybe 1% of your JavaScript changed. Another reason to
want modules.

I don't know if Browserify can do that.

------
tlrobinson
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.

~~~
eknkc
This worked fine for us for a year or so.

Now, I sometimes need to change stuff when there are a couple thousand online
visitors on one of our sites. Their requests gang up on middlewares and causes
duplicate compilations. We already have reverse proxy servers to keep
duplicate requests waiting for the first one but that still leaks due to
different browser capabilities and stuff.

Having everything prebuilt makes more sense at this point.

~~~
judofyr
Just FYI (and anyone else listening): this is called "dog-piling" if you want
to look around for solutions:
[http://en.wikipedia.org/wiki/Cache_stampede](http://en.wikipedia.org/wiki/Cache_stampede)

------
ahallock
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.

~~~
harlanji
I agree exactly, and have ignored Grunt and now Gulp in favor of Make. Gulp
looks to be basically reinventing Std I/O, when we should just be shipping
these NPM-based tools with a bin that works via Make or spawn/exec in any
other build tool. It makes all the more sense now too, with the early trend
toward virtualizing devel environments in Linux VMs.

------
pfrrp
Skip the require vs browserify debate and use
[https://github.com/webpack/webpack](https://github.com/webpack/webpack).

Allows for amd commonjs and almost any other format around. With gulp and
grunt plugins!

~~~
pedalpete
I've been messing around with require.js and browserify all day, but I don't
really LOVE either solution for a large angular app. I'm going to give webpack
a try. Thanks

~~~
mikewhy
Our team is using Brunch on an Angular app and the proper module system on top
of Angular's "module" system does indeed feel wrong.

------
indolering
Ahh, finally, a flow-based build system for Javascript. Now if they would just
port it to NoFlow and hook it up to a GUI…

------
namuol
I think I'll wait 24 hours before changing over my entire workflow...

------
JanJanJan
One fact that has not been mentioned yet is that gulp plugins (i.e. simple
object streams) are very easy to unit test. (With grunt there still is not an
easy way to unit test plugins.) Also by way of their nature as streams they
tend to be small and composable, again making them easier to maintain.

Also, there is already an effort going on towards finding a generic API for
node task runners at [https://github.com/node-
task/spec/wiki](https://github.com/node-task/spec/wiki)

------
akbar501
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 time

"Development time" is when the task runner is used during development, such as
running livereload to update the app with saved changes to source files. Speed
during development time is very important.

"Build time" is the time used when building a production package. With build
time, if one task runner is 5 sec. vs. 10 sec. it makes little difference.

Is one task runner always faster?

What are the differences in performance?

And are these development time or build time differences?

I'm all for new tooling, but let's have measurements in place so that people
can make intelligent decisions about when one vs the other is right/wrong for
a given project.

As for configuration complexity, it would be great to see a large production
configuration of Grunt and Gulp.

~~~
lowboy
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](http://slid.es/contra/gulp)

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

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

------
parris
Gulp seems more like a feature and less like a build system. In fact:
[http://blog.evanyou.me/2013/12/29/gulp-
piping/](http://blog.evanyou.me/2013/12/29/gulp-piping/) and
[https://github.com/wearefractal/vinyl-
fs](https://github.com/wearefractal/vinyl-fs)

Grunt works just fine. Make is probably ok once you learn it. It is a shame
that we as a community don't take time to create amazing tutorials for our
older tools like we do with our newer ones.

I think the main issue ends up being that github has created a double edged
sword in open source dev land. You have people creating projects just so they
can earn stars and thus resume fodder. This ends up creating packages with no
maintainers and multiple projects that do the same thing. I mean really, how
many different string parsing npm libraries do you need?

------
cheapsteak
Wonder why the website hosting the tutorial mentioned in the article is "on
vacation"?

Here's a rather ugly google cache'd version: [http://robo.ghost.io/getting-
started-with-gulp-2/](http://robo.ghost.io/getting-started-with-gulp-2/)

------
mrcactu5
At least the guy admits he is a first-adopter.

All I really get from this blog is that some influential guys approve of these
two new JS libraries.

For someone who still builds website HTML, what are Grunt vs Gulp originally
supposed to do? And why does Grunt do it better?

And a similar questiion for RequireJS / Browserify?

------
integricho
I have no intention to throw out Grunt or RequireJS, just because there's a
new hype about some new tools. It takes time to adjust things, and I'm
perfectly satisfied with them as they perform now. Also I somewhat doubt that
they are a 1:1 replacement.

------
mkaito
Can we get python in the browser already.... please?

------
sheetjs
... and now we have fez:
[https://github.com/fez/fez](https://github.com/fez/fez)

[https://news.ycombinator.com/item?id=7090479](https://news.ycombinator.com/item?id=7090479)

~~~
STRML
To be honest, I wish people would stop mentioning this project until it
actually usable for real projects. I have attempted to build a sass task for
Fez and failed when I realized that the core project simply does not have the
ability to be configured to do very simple things. In the case of the sass
plugin, Fez does not support globs, making it difficult/hacky to properly
ignore files prefixed with "_", a well-known sass convention.

I agree that Grunt syntax is not fantastic. It has improved since 0.4 but the
reality is that the average "long" Grunt build has a whole ton of
customization thrown into the mix that is simply not possible with newer tools
such as Gulp or Fez.

Additionally I really don't think that the comparisons are fair. Yes, it's
nice to declare a fileset and define transformations on it, rather than
defining transformations and declaring which files you want to use with each
one. But I could easily show you an easy-to-read Grunt configuration that is
just as simple as the ones you see in Fez or Gulp marketing.

I applaud what these tools are attempting to do, but we need to keep the
comparisons fair.

~~~
spion
Indeed, fez is not quite completely ready yet - its still in the development /
experimental stage.

------
prottmann
Hmm, i don't see much difference in configuration between grunt and gulp. Both
do the job.

And Performance? Which Performance? They call tasks that do something, and the
task need performance.

~~~
jonheller
Agreed. Honestly I had little to no experience with configuration files like
those used in Grunt before a year or so ago, but I don't find anything more
intuitive with what I've seen so far with Gulp, than Grunt.

------
Q_the_Novice
Gulp is written in a way I've always wished Grunt could be used and I have
already started using it in new projects. RequireJS is still my front-end
module loader of choice.

------
namuol
Seems like it's only a matter of time before the "de-facto" status of our
build tools will fluctuate as rapidly as Bitcoin's valuation.

------
homborg
It's seems many people are comparing Grunt to Gulp, without considering the
subtitles:

Grunt is the "JavaScript Task Runner" and Gulp is "The streaming build system"

There is not much point in using grunt for building or gulp for running tasks,
IMHO.

My team is moving towards using gulp for js/css builds and make for tasks. We
used grunt before. We probaby should use npm for tasks, though (cross-
platform).

------
Kiro
How often do you have so many dependencies in a web app that you actually need
something like RequireJS or Browserify?

~~~
Cthulhu_
I have an anecdote for that. I work at a bank and in the past two years we've
built a front-end for investment banking using BackboneJS and some other
frameworks. This application has close to 200 views, 26 routers, and probably
200-300 models/collections, totaling at about 30K lines of front-end code. You
really have to use RequireJS or Browserify for a project of that scale, or
even for any non-trivial project.

New projects (and the one I'm working on atm) are built in AngularJS, which
has a built-in dependency system. We're not going to use RequireJS as a script
loader anymore; in practice, it'll just load all the files on application
load, which doesn't really add anything. I like Angular's simple approach of
just loading a bunch of scripts using script tags. The existing application is
going to get rewritten in Angular too, it's expected that it'll need a lot
less code.

------
antihero
I'm still not sure what browserify really adds over concatenation. Never
noticed any speed increases, I guess the one thing would be explicit
dependencies, but I've always found you can do that with module patterns
anyway, and it breaks half the libraries you want to use.

------
mikewhy
For front-end apps it's hard to not recommend Brunch[1]. It gives you the
module system of Browserify and some of the build power of Gulp/Grunt with
much less configuration.

[1]: [http://brunch.io/](http://brunch.io/)

------
tootie
Is the world ready yet to get a cross-platform build tool? One that can
compile Java, lint Ruby and concatenate JavaScript? Seems like there's a core
set of tasks that are pretty common across platforms.

~~~
lmm
There's not really a lot that's common, and most devs seem to prefer to have
their build tool written in the same language they're writing.

------
ilaksh
I still prefer bash scripts.

And I think Gulp is much more complicated than necessary for 90% of the builds
out there.

My 'bild' module is simpler for most things. Although I will stick with bash.

------
ballard
This story comes off as the emperors' new clothes.

As long as minified compressed HTML, CSS and JS are served up with the least
amortized dev and support time, it's all good.

------
argonaut
I wouldn't say that. RequireJS vs. Browserify is still a very contentious
issue that is up to a developer's preferences.

~~~
STRML
Is it really, though? Aside from RequireJS's subjectively awful syntax (I have
built a few non-trivial applications with it, and find it generally very
noisy) - it simply does not do many of the very useful things that Browserify
does. Browserify is much more than just a simple dependency management
toolkit, it allows you to easily write node-style code and use npm
dependencies in the browser. It's practically apples and oranges.

~~~
argonaut
RequireJS allows for asynchronous loading. Browserify doesn't.

That alone is a huge reason for why people use RequireJS.

------
emil0r
Seems like it will be an awful lot of work to support older work?

------
ing33k
what ! I just started using Grunt in a project .

on a side note: I realized some time ago that I really can't be using the
latest thing always ( at least with JS ).

------
justinph
Oooh, look at the shiny keys.

------
stefan_kendall
Yay. Another week to waste rebuilding all the builds and fixing all the
continuous integration jobs.

Is anyone else thoroughly unexcited about all this playing in the sand? We're
building products; why do we spend so much time and money on build tool churn?

I avoid build tools whenever possible (using built-in build commands and
things like compass), but when I do need a build, I just use Rake. My
toolchain stays the same so I can get shit done.

~~~
kevincennis
I'm not sure anyone is seriously suggesting that you take an existing project
that's already using Grunt and convert it to Gulp.

But if there's a new build tool that I've heard good things about next time I
start a new project, I think it's worth a bit of investigation to see whether
or not it might serve my needs better than what I've been using.

