And just like that Grunt and RequireJS are out, it’s all about Gulp and Browserify now

In a demonstration of how insane the Javascript world is, a revolution happened last week and it looks like Grunt was dethroned as the go-to task -runner. But wait you may say, wasn’t the Node and Grunt revolution just beginning? After all Grunt had just managed to find its way to job descriptions. Apparently we weren’t done revolutionizing.

This is how it happened from my point of view. I got linked to this:

Screen Shot 2014-01-06 at 11.39.27 AM


When I saw that first post I knew Addy Osmani is always way out on the front lines so I thought there are still some months of using Grunt before Gulp takes over.

But then when Hage Yaapa, who wrote a great book on Express and who always posts great resources, praised it so much I realized it’s probably awesome.

Screen Shot 2014-01-06 at 11.40.34 AM


And finally when Sindre Sorhus, also on the yeoman team, major Javascript innovator and leading NPM contributor, posted a quick tutorial about it, I had to look.

Screen Shot 2014-01-06 at 11.40.48 AM

And what I saw was that it is indeed much better, much more intuitive to Node.js devs and simpler to use. And that concluded it for me.

So now  instead of Grunt’s harder to understand syntaxes and laborious pre-config, we have this:

var gulp = require('gulp');  
var browserify = require('gulp-browserify');  
var concat = require('gulp-concat');  
var styl = require('gulp-styl');  
var refresh = require('gulp-livereload');  
var lr = require('tiny-lr');  
var server = lr();

gulp.task('scripts', function() {  

gulp.task('styles', function() {  
        .pipe(styl({compress : true}))

gulp.task('lr-server', function() {  
    server.listen(35729, function(err) {
        if(err) return console.log(err);

gulp.task('default', function() {'lr-server', 'scripts', 'styles');'src/**', function(event) {'scripts');
    })'css/**', function(event) {'styles');

Then while taking a look at the link Sindre Sorhus posted, I noticed Browserify. I took a look at that and realized it gives you the Node.js module dependency on the client which essentially eliminates the need for RequireJS or any of its analogues.

Screen Shot 2014-01-06 at 11.49.53 AM

I love it. So much better. And just like that I’m a convert. I’m always using Gulp and Browserify… Until next week!

79 thoughts on “And just like that Grunt and RequireJS are out, it’s all about Gulp and Browserify now

  1. dam

    January 6, 2014 at 11:27pm

    It gets even more exciting when you take it one more step.
    Atomify and Resin allow you “require” css.
    One more step towards a less terrible workflow.

    • newtriks

      January 7, 2014 at 7:34am

      Webpack is well worth a look as an alternative to Browserify as it uses loaders so css is supported out the box :)

      • Marshall

        February 17, 2014 at 2:22pm

        Thanks for showing this. I’ve found it superior to browserify in every way.

  2. Paul

    January 6, 2014 at 11:48pm

    While I never used Grunt, you are right with Browserify. It’s the single true way to do front-end JavaScript.

  3. Anderson Vaz

    January 7, 2014 at 3:20am

    When I started to use Grunt I’ve some difficulties with it, with Gulp the begin was a way faster and simple!
    Very nice tip!

  4. Wallace Sidhrée

    January 7, 2014 at 9:08am

    Grunt totally changed the way I maintain applications and I’m very grateful for that. Looking forward to testing Gulp, with an ominous feeling I’ll be spending the next days upgrading my apps to it! Cheers for the article!

  5. Jonathan

    January 7, 2014 at 4:21pm

    Am I the only one that finds this article a bit ridiculous?

    First of all, he complains about spending a “whole day”…a single day…to learn about a new technology. Next, he states that gulp is “mind blowingly intuitive” of which gulp and grunt have NEARLY THE SAME SYNTAX. I’m willing to bet, had he learned gulp first, THEN grunt, he would have just as much of a ramp up time learning gulp.

    That said, from a glance, seems like gulp is just a more prepackaged version of grunt with all of the most used plugins ready out of the box, we’ll see who wins out.

    • Paul

      January 7, 2014 at 6:41pm

      First of all, he complains about spending a “whole day”…a single day…to learn about a new technology. Next, he states that gulp is “mind blowingly intuitive” of which gulp and grunt have NEARLY THE SAME SYNTAX. I’m willing to bet, had he learned gulp first, THEN grunt, he would have just as much of a ramp up time learning gulp.

      That came to my mind, too, but I had to accepted it, cause I never used Grunt or Gulp. (I’m still using good old makefiles, btw.)

      • Jonathan

        January 7, 2014 at 7:44pm

        Bah, posted my reply to the wrong person, but I agree with you.

        • Paul

          January 7, 2014 at 7:55pm

          Hehe, I nearly made the same mistake. Reply buttons in the upper right corner, that’s great UX.

      • Salem

        February 4, 2014 at 2:51am

        I think the fact that it uses streams gives it a bit of an edge in the “better” department, over some simple change like semantics. We’ll see, though.

    • Rob

      January 7, 2014 at 10:03pm

      I’m with you Jonathan.

      Grunt did take me more than a day to figure out, but it was well worth it. I happen to like the configuration-over-code approach, and enjoy the large number of contributions available for almost any conceivable task.

      I’m not about to change my task runner because some new kid arrives on the block :)

      P.S. the Gulp plugins page just keeps loading, and loading and loading…

      • naman

        January 11, 2014 at 6:16pm

        The plugins page works just fine for me, and there are lots of plugins. So its not behind grunt in anyway.
        Also, there is a plugin that lets it run Grunt Plugins. Rather than seeing it as an all new thing, we should see it as the next version of Grunt.

    • Declan

      January 9, 2014 at 6:38pm

      Jonathan, Gulp is way more than “just a more prepackaged version of grunt”. Have you ever needed to perform more than one operation on a single file? The solution to this problem in Grunt is to utilize temporary files. In Gulp, there is no solution because there is no problem. It’s a streaming API – you just pipe the streamed source of the file down to the next operation and that’s it. You’re done. Simple. No need for temporary files. It’s also faster. I think the only thing left to improve in the task runner world is running multiple tasks on multiple files at the same time without relying on temporary files.

      • Hans Czajkowski Jørgensen

        May 30, 2014 at 8:58am

        You can actually do that with gulp too. Have a look at the streamqueue and event-stream modules.

        • Hans Czajkowski Jørgensen

          May 30, 2014 at 9:03am

          oops. That should say merge-stream, not event-stream

          Example code here

  6. Owen

    January 7, 2014 at 6:11pm

    This looks awesome – much more intuitive syntax for a Node.js developer IMO. Anything on requiring templates? If you could require templates, in addition to CSS with node-style syntax, and have the bundling and de-duplication handled by Browserify then that would be really awesome!

    • Jonathan

      January 7, 2014 at 7:43pm

      Well at least I wasn’t the only one, haha.

      Long and short of it to me, it feels like pick one and stick with it, otherwise you’re wasting time just joining the “next big thing” bandwagon.

      • Mude

        January 8, 2014 at 11:55am

        I think what you all guys are looking for is component/component. CommonJS (node-style) module loading, and components are not just js. They can be CSS, templates, fonts, images …

        Component is basically browserify, but more flexible, faster installs without garbage, and not sharing the registry with node modules is imo a plus. I don’t know how would I feel about submitting a font into npm. I know they don’t mind, but it just feels weird. Especially in a name-snatching environment that is npm registry.

  7. Mickey

    January 8, 2014 at 2:08pm


    I could not make it work with CoffeeScript sources. Same code in JavaScript works ok, but in CoffeeScript + gulp-coffee throws an error.



    App =
    start: () ->
    console.log "app started"

    module.exports = App


    App = require './app'


    var gulp = require('gulp');
    var browserify = require('gulp-browserify');
    var concat = require('gulp-concat');
    var styl = require('gulp-styl');
    var coffee = require('gulp-coffee');
    var less = require('gulp-less');
    var refresh = require('gulp-livereload');
    var lr = require('tiny-lr');
    var server = lr();

    gulp.task('scripts_coffee', function () {

    running ‘gulp scripts_coffee’
    gives the following:

    throw er; // Unhandled stream error in pipe.
    Error: module "./app" not found from "/Users/mickey/Projects/nodejs/gulp_test/src/fake_87c578d8.js"
    at /Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/index.js:570:23
    at /Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-resolve/index.js:183:24
    at /Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:36:22
    at load (/Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:54:43)
    at /Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:60:22
    at /Users/mickey/Projects/nodejs/gulp_test/node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:16:47
    at Object.oncomplete (fs.js:97:15)

    • Shuhei Kagawa

      January 14, 2014 at 2:54pm

      Hi Mickey,

      You can use coffeeify transform of browserify instead of gulp-coffee. Also, if you want to do require('./app') instead of require('./'), you need to set extensions option to browserify, which is not supported in gulp-browserify 0.2.5. However, since extensions support is already merged into its master, it will soon be available. At this moment, the following gist would serve as an example.

    • Kirk

      February 3, 2014 at 7:47pm

      coffee files require instead of just app like:

      var gulp = require(‘gulp’);
      var browserify = require(‘gulp-browserify’);

      gulp.task(‘coffee’, function() {
      gulp.src(‘src/coffee/’, { read: false })
      transform: [‘coffeeify’],
      extensions: [‘.coffee’]
      go to Languages that compile to JavaScript section


      If you forget { read: false }, gulp-browserify will passes the contents stream of a incoming file to node-browserify. Then node-browserify names the stream as fake_xxx.js and process it. Some transforms such as coffeeify determines whether to transform files with extensions. That is why you need { read: false } for AltJS.

  8. Rafinskipg

    January 8, 2014 at 2:48pm

    Yeah, browserify looks great. The next tools to use, until the next week .. XD

    • Jake

      February 5, 2014 at 11:35pm

      This. A thousand times this.

      This is the big problem to me with the JavaScript community, especially (and I mean no disrespect) the Node.js folks. People seem to like to discard best practices or popular and well-tested libraries “just like that”, because something else cool comes along. The thing is: these practices exist for a reason, these libraries are popular for a reason, and abandoning them just to use the sexy new thing to me shows a lack of foresight.

      • Chase Adams

        February 17, 2014 at 1:42pm

        I totally get this sentiment and I’ve struggled with it, but I think it’s one of the really cool things about the NodeJS community. In general, they’re pushing on the edges to see what works and what doesn’t. They’re challenging the old guard to try and build things that work better.

        If you walk to work every day and it takes 30 minutes, but you find a path that only takes 10, you’d take it, right? If you knew there was a chance it’d shave off 20 minutes, you’d at least try it once and if you found out it didn’t work, you now have good evidence for why.

        Most things that exist and are popular are that way because they had a particular benefit, and if something that has that benefit, but faster, more performant, smaller, etc, then why not try it out?

        If you can’t try it out, that’s the beauty of the internet: Most likely someone else will or has and is willing to talk about it, so the overhead of research is minimal at best.

        Hope that provides an alternative perspective, not one I think anyone needs to take, but certainly one to consider.

  9. Robert Agthe

    January 8, 2014 at 5:19pm

    If you´re using coffeescript you can skip the whole require/include part. Most of the times i create a, and a lib folder with some *.coffee classes. All you need then is a Gulp/Grunt task and concatenate all files “**/*.coffee”.

    “” first, then all lib coffee files and at last the Build then one JS file out of it.

    * no require code
    * no path issues
    * rename files or create sub-dirs without changing code oder configs

    • J.C.

      March 29, 2014 at 9:08am

      The Node.js community is an embarrassment. It’s original author has completely disowned it and claims to no longer use it at all. Joyent execs have been overheard, on multiple occasions, saying that their business model is essentially “selling crap to idiots”. So using this shit at all and falling for their spiel shows a complete lack of “foresight”.

      I want to feel sorry for all these helpless little lemmings, who keep spamming the internet about how ‘effing great Node.js is, but their smugness and irritability cancels out any pity I had for them.

      • BillTrik

        April 23, 2014 at 9:27am

        Epic flaming is epic

      • Thomas Dickenairy

        July 14, 2014 at 3:17pm

        Seeing that they aren’t selling node.js, they must have been referring to other “crap” in your particular allegory. Out of curiosity, did Ryan Dahl mention what he uses now, in lieu of node.js? Or, would it be too much trouble for you to add some value to your post?

    • John Pancoast

      November 3, 2014 at 9:16am


      IMO we’re not talking about different paths to walk. We’re talking about different ways to walk. And if that’s the case (who knows. it’s late and I’m rambling) then we need to standardize how walking works, not reinvent walking over and over again.

      I like new tools just like the next guy but this seems to be a problem that needs to be resolved… soon. I think it honestly demonstrates the state of programmer’s inabilities to refactor something that already exists vs. rewriting something from scratch. The former is harder.

  10. Dan Glegg

    January 9, 2014 at 3:16am

    One thing to note is that Browserify, although a great tool, does not have the client-side flexibility of requirejs when it comes to tasks like breaking applications into discrete, lazy-loadable modules. It’s more of a thing for when you want to run code at both ends of the wire or package a small node.js library for use in the browser – as always, YMMV on a per-project basis.

      • Dan Glegg

        February 10, 2014 at 6:30pm

        Possible, sure, but given that the CommonJS API is inherently synchronous, you do end up with some odd patterns starting to form – not least of which is turning simple dependency injection into a mixture of business logic and build targets.

        Ideally you’d have one mechanism for loading code (i.e. code would not need to be written with specific build targets baked-in) and from there be able to build either fat or thin script files using config in your build tooling, not your business code.

        But of course, YMMV!

        • Matthias

          February 17, 2014 at 9:06pm

          Pretty sad we bring JS to the server and then end up with people creating incompatible code via incompatible module definitions. I think we have to wait for ES6 modules to solve this dilemma and to get rid of all interim (requirejs/commonjs/homemade) solutions.

  11. Tony

    January 18, 2014 at 12:23am

    Browserify is the bomb, I have to look into gulp a bit more

  12. Christian Bartels

    January 23, 2014 at 12:43pm

    Yay guys, go ahead and revolutionize everything. I’ll stick with solutions that work :-)

    “Bah, you can do almost the exact same thing from the terminal with these 5 bundles, 87 commands and an impossible sense of superiority.” =)

    • cat

      February 17, 2014 at 2:32am

      It’s obvious you haven’t tried either.

      I’m glad you would rather spend money on proprietary software than support the open source community.


      Gulp is awesome

  13. Pit A

    February 3, 2014 at 7:28am

    What is a competition of Grunt?

  14. Jorik Tangelder

    February 3, 2014 at 7:51am

    Browserify? Please check webpack..!

    • Marshall

      February 17, 2014 at 2:24pm

      Ditto. Webpack is everything included in browserify and more, but simpler to use for noobs.

  15. fibo

    February 3, 2014 at 9:21am

    Grunt is great and everyone used it should say thank you to people wrote it, but, for dkme tasks you realize it is not ok. Gulp is really good if you want flexibility and need to customize you tasks. I switched to gulp for my project mainteinance but grunt is still a super valid piece of software and i’m sure will be useful in the future. Hey, you can also use both!!!!

  16. Alex

    February 3, 2014 at 3:27pm

    I do love how “Con-catting” Javascripts and CSS is now so prevalent. Personally I have been doing this for years and it’s good to see that it’s now in the minds of creators of tools like gulp/grunt.


  17. Luke

    February 3, 2014 at 3:55pm

    You might want to take a look at this PR by the creator of Gulp. He pointed out the error in not returning your stream, which tricks the task system into thinking these are simple synchronous tasks, not the asynchronous tasks that they are.

  18. Cory

    February 3, 2014 at 6:56pm

    So with Browserify you have to rebuild/bundle all of your files every single time you modify your code. I’m not sure I like that too much.

    • Jo

      April 4, 2014 at 7:16pm

      I still prefer requireJS since I can just throw my app source in the browser and it work, for debugging it does wonders. If I need to build every minute, why not develop in Haxe, Java or another fashionable IDE empowered language that ports to javascript? Gulp seems nice tho, but once you learn how to make custom tasks in Grunt it’s hard to turn your head 😉

  19. Harry Pujols

    February 28, 2014 at 4:26pm

    I never liked Grunt. Setting up a Grunt file for me was not worth the time nor the effort. I never managed to make it do what I intended, so I stuck with Codekit. My experience with Gulp was completely different. In almost no time I was able to set up a workflow exactly how I wanted. Now I know why you guys were raving about these Node-based task runners.

  20. […] And just like that Grunt and RequireJS are out, it’s all about Gulp and Browserify now – In a demonstration of how insane the Javascript world is, a revolution happened last week and it looks like Grunt was dethroned as the go-to task -runner. But wait you may say, wasn’t the Node and Grunt revolution just beginning? After all Grunt had just m […]

  21. David

    March 17, 2014 at 8:20pm

    Now you can include css (and optionally templates) along side your JavaScript using parcelify, which uses the browserify dependency graph to output bundles of other asset types. It also supports transforming sass/less to css, etc, using transform streams, just like those in browserify:

  22. mikekidder

    March 18, 2014 at 11:36pm

    And just like that… I’m hooked!

  23. […] the blogosphere recently became alive with talk about Gulp, a new JS build tool. This blog post ‘And just like that, Grunt and RequireJS are out – its all about Gulp and Browsify now’ and this Twitter post felt like the shifting of alliances in 1984. This is something […]

  24. David Colwell

    March 21, 2014 at 3:12pm

    Can you provide a working link to the PR you mention? It doesn’t seem to be working….you managed to just get empty anchor tags with no href or URI reference.

    Gulp is looking promising. Haven’t been convinced to tell the team we should switch away from grunt for the enterprise app where I work yet, but for my personal use I’m starting to think this could be taking grunts place as my default build system!

  25. J.C.

    March 29, 2014 at 8:57am

    What is this? Brown-nose driven development? Do you make all your decisions based on the opinions of a bunch of mediocre JavaScript developers?

  26. harry

    April 21, 2014 at 8:25pm

    Any update on that gulp tutorial. The link errors out.

  27. Bradley

    May 7, 2014 at 6:22pm

    Fucking hipsters.

  28. Dave Shapiro

    May 30, 2014 at 6:46am

    What’s with all the “blacklisted” plugins at the bottom of …with messages like “duplicate” or “your programming is not up to our elitist standards”???

    Contributions to the open-source community are done on people’s own time, and for free. I do not understand the attitude from the Gulp team about publicly ridiculing developers trying to contribute, and requiring them to respond and explain why their code should not be “blacklisted”. Perhaps communicating problems regarding a plugin privately would be a bit less alienating? I, for one, will not be wasting my spare time contributing to Gulp.

  29. Doug

    June 9, 2014 at 8:04pm

    No mention of Brunch?

  30. Getting Started with Browserify

    June 10, 2014 at 7:00pm

    […] And just like that Grunt and RequireJS are out, it’s all about Gulp and Browserify now – Martin Genev talks about his sudden conversion to Browserify and Gulp with an example. […]

  31. Andre

    June 12, 2014 at 11:00pm

    Firstly, I admit I haven’t read every comment in the thread, but I think a few people might be missing a few key points in comparing this to Grunt… If not for the days and weeks I’ve spent “playing” with gruntfiles, I definitely wouldn’t have understood the intro to Gulpjs nearly as well as I did.

    It is awesome, it’s easy, it makes sense… Because we’ve already learnt about the ideas of project structures and JS-based build workflows. :) I think this makes for an awesome alternative to Grunt, in the right projects. Heck, imagine this Gruntfile in Gulpjs..? They would both be just as much of a monster in their own way. But everybody has their own taste, so I have a feeling both of these will inspire and challenge devs from the other, not unlike the way Maven and Gradle currently do.

    That said, I’m quite happy to use both.. Each of them will most definitely have their place in my environment arsenal. :)

    • Andre

      June 12, 2014 at 11:28pm

      Well, a short while later… Having delved deeper into Gulpjs earlier, I’m looking at my Gruntfiles in a new light now. It really does help when you see both sides of the same code-vs-configuration coin…


    June 15, 2014 at 2:00am

    Good day! I just wish to give you a big thumbs up for the great
    information you’ve got here on this post. I’ll
    be coming back to your website for more soon.

  33. Joseph Gabriel

    June 17, 2014 at 1:59pm

    Bah….Grunt, Gulp….I can’t wait to try Burp….it is the next big thing, you know.

  34. jason

    July 12, 2014 at 10:43pm

    I’m not against using the latest-and-greatest but seriously? “gruntjs took me a whole day to figure out”…wow. Took me about idk 5 minutes my first time. Maybe we should improve as developers and stop bitching that we have to *gulp* (pun intended) work a little.

  35. Yellow

    July 22, 2014 at 4:57am

    This JS world is nutz!

    I’ve made mountains of virtual servers with Chef and Puppet, remote configured Cisco routers, wrote impossible software, recoved gigs of lost data from log files, bounced message queues around the world…. yet installing a few CSS files is a steeper learning curve?

    I imagine if Git had an SVN externals equivalent, this whole need of re-copying files out of repos would never have existed.

    Seems to work well enough in the end, but so very verbose.

  36. Totty

    September 26, 2014 at 1:55pm

    I’ve been developing with require.js for a time, then tried browserify. Was amazing! Until the require(“../../../myModule”) relative hell came back, ok, I really hate that stuff. Require makes it so easy to do just require(“myModule”). It might be more verbose, but I’m still using it.

    Also the browserify misses fast changes. Now I change a file, it starts to build app the new compiled.js, while this is doing the task, I edit another thing, the browserify ends the task and the old version is ran. Missed my changes. Require.js is a lot faster and never misses a change.


    October 8, 2014 at 8:07pm

    TRY AMIGA CODING this is kids play what a joke pfft.


  38. Manas N

    December 8, 2014 at 6:35am

    And, Browserfiy is out now too.

Comments are closed.