12 ms·

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

208 points by codecurve 13y ago

skrebbel 13y ago
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.
- jonpacker 13y ago
  Well, source maps are usually the solution for me. And yes, browserify supports source-mapping all the way back to coffeescript files using browserify-middleware. In the off case that I need to debug something in a browser that doesn't support source maps, you can turn minifying off and usually it is pretty easy to recognise the code you're inspecting, even if it comes from coffeescript. I've never had a case where I've been completely out of luck (usually this case only happens in IE).
- indolering 13y ago
  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.
  - WickyNilliams 13y ago
    sourceURL? You can even do it with functions in the console: function hello() { console.log("hello world"); //# sourceURL=hello.js } This will then appears in the sources panel under the name "hello.js". Which is great for debugging little scripts you're putting together in the console as you can set breakpoints, watches etc
  - pyre 13y ago
    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.
sheetjs 13y ago
... 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
- joemaller1 13y ago
  Well (taking cues from the article) it has been a couple of weeks. This is the first I've heard of Gulp though. Looks promising.
- tomByrer 13y ago
  There is an entire range of build tools. some devs still use `make`, bash &/or hand-written node scripts. Once you have them set up, & keep same folder & msc patterns, they can all be satisfactory. The advantage of Grunt is that it has a huge ecosystem. But Gulp has many of Grunt's heavy-hitters building plug-ins for it. So you can look at Gulp as front-end-build-tools v3.0 (Addy & Paul Irish were pushing Ant before Grunt).
- STRML 13y ago
  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 13y ago
untog 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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
emil0r 13y ago
Seems like it will be an awful lot of work to support older work?
argonaut 13y ago
I wouldn't say that. RequireJS vs. Browserify is still a very contentious issue that is up to a developer's preferences.
- STRML 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - argonaut 13y ago
    RequireJS allows for asynchronous loading. Browserify doesn't. That alone is a huge reason for why people use RequireJS.
akbar501 13y ago
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 13y ago
  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.js https://github.com/jjt/dramsy/blob/master/client/Gruntfile.j... [2]: https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js
- tomByrer 13y ago
  If you want to compare build time, it would be best to add plug-ins that trigger only the tasks that deal with changed files: https://github.com/osteele/grunt-update https://github.com/osteele/grunt-update https://github.com/goodeggs/grunt-skippy https://github.com/goodeggs/grunt-skippy https://github.com/aioutecism/grunt-diff https://github.com/aioutecism/grunt-diff https://github.com/sindresorhus/gulp-changed https://github.com/sindresorhus/gulp-changed
cheapsteak 13y ago
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/
Q_the_Novice 13y ago
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.
Maxious 13y ago
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 13y ago
  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 13y ago
    > 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.
mjackson 13y ago
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.
pfrrp 13y ago
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 13y ago
  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 13y ago
    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.
emilis_info 13y ago
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.
- jonursenbach 13y ago
  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.
  - skrebbel 13y ago
    Oh, how I long for the days when condescension was a thing reserved for Lisp programmers.
  - emilis_info 13y ago
    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.
    - shadowmint 13y ago
      Really no. The makefile syntax is obscure and hard to maintain. We've been there. We don't need to go there again. The stories of 'recursive makefile dependency hell' deserve to stay back in the dark ages of the 90s where they belong. There's a reason lots of people are inventing new systems for doing these sorts of tasks (for example, spawning a local webserver to work with after compiling less and coffee files and parsing the output for errors and displaying them nicely, then watching the filesystem for changes and recompiling on demand). It's not because make is evil, it's because make does a poor job of some of these sorts of tasks. ...if all you're doing is turning .coffee files into .js, it's file, but it's not a solution for complex website builds.
      - 13y ago
ahallock 13y ago
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 13y ago
  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.
tlrobinson 13y ago
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.
- contrahax 13y ago
  You can totally use gulp plugins outside of gulp. Since they are just streams, you can do some really cool stuff. I would love to see an http wrapper so you can do wrap(req).pipe(uglify()).pipe(res)
- eknkc 13y ago
  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 13y ago
    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
AndyKelley 13y ago
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 13y ago
  Clever setup.
integricho 13y ago
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.
noname123 13y ago
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?
jondot 13y ago
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!.
- nailer 13y ago
  +1. I have spent more time reading about grunt than I have spent investigating + converting to + using gulp in production.
- brokenparser 13y ago
  I'd say Grunt is Maven because IDEs have no way to figure out beforehand what the build process will do.
  - lmm 13y ago
    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.
- tieTYT 13y ago
  I agree with you that "Grunt is ant". But when I look at that code example it seems like "Gulp is ant", too. It's just less verbose. I think that Lineman is the Maven equivalent in the JS world.
indolering 13y ago
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…
contrahax 13y ago
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 13y ago
  Many thanks from one who fought through the outdated source in the OP.
Kiro 13y ago
How often do you have so many dependencies in a web app that you actually need something like RequireJS or Browserify?
- Cthulhu_ 13y ago
  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.
- CWIZO 13y ago
  http://bladerunnerjs.org/blog/large-scale-complex-javascript-apps/ http://bladerunnerjs.org/blog/large-scale-complex-javascript...
- joelhooks 13y ago
  100,000 lines of JS is best divided into smaller parts.
ing33k 13y ago
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 ).
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
ilaksh 13y ago
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.
prottmann 13y ago
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.
- potomushto 13y ago
  Typical build may look like this: Task 1 passing many files to Task 2, then to Task3, concatenate and so on. It's all about Disk I/O performance. Streams piping reduce files reading/writing.
- jonheller 13y ago
  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.
mehulkar 13y ago
This post reminds me of the joke about the Native Americans getting ready for winter[1] [1] http://voices.washingtonpost.com/capitalweathergang/2008/11/winter_weather_joke.html http://voices.washingtonpost.com/capitalweathergang/2008/11/...
- blowski 13y ago
  That's great - I can use that whenever the topic of 'the echo-chamber' comes up.
mehulkar 13y ago
This post reminds me of the joke about the Native Americans getting ready for winter[1] [1] http://voices.washingtonpost.com/capitalweathergang/2008/11/winter_weather_joke.html http://voices.washingtonpost.com/capitalweathergang/2008/11/...
antihero 13y ago
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.
namuol 13y ago
I think I'll wait 24 hours before changing over my entire workflow...
namuol 13y ago
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.
mkaito 13y ago
Can we get python in the browser already.... please?
mrcactu5 13y ago
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?
JanJanJan 13y ago
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
homborg 13y ago
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).
stefan_kendall 13y ago
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 13y ago
  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.
mikewhy 13y ago
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 13y ago
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 13y ago
  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.
- acjohnson55 13y ago
  If only someone would Make something like that. Boy, that would really Make my day...
justinph 13y ago
Oooh, look at the shiny keys.
ballard 13y ago
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.
parris 13y ago
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?

208 points by codecurve 13y ago

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.

jonpacker 13y ago
Well, source maps are usually the solution for me. And yes, browserify supports source-mapping all the way back to coffeescript files using browserify-middleware. In the off case that I need to debug something in a browser that doesn't support source maps, you can turn minifying off and usually it is pretty easy to recognise the code you're inspecting, even if it comes from coffeescript. I've never had a case where I've been completely out of luck (usually this case only happens in IE).
indolering 13y ago
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.
- WickyNilliams 13y ago
  sourceURL? You can even do it with functions in the console: function hello() { console.log("hello world"); //# sourceURL=hello.js } This will then appears in the sources panel under the name "hello.js". Which is great for debugging little scripts you're putting together in the console as you can set breakpoints, watches etc
- pyre 13y ago
  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.

sheetjs 13y ago

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

joemaller1 13y ago
Well (taking cues from the article) it has been a couple of weeks. This is the first I've heard of Gulp though. Looks promising.
tomByrer 13y ago
There is an entire range of build tools. some devs still use `make`, bash &/or hand-written node scripts. Once you have them set up, & keep same folder & msc patterns, they can all be satisfactory. The advantage of Grunt is that it has a huge ecosystem. But Gulp has many of Grunt's heavy-hitters building plug-ins for it. So you can look at Gulp as front-end-build-tools v3.0 (Addy & Paul Irish were pushing Ant before Grunt).
STRML 13y ago
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 13y ago

untog 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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

emil0r 13y ago

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

argonaut 13y ago

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

STRML 13y ago
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.
- deleted 13y ago
  [deleted]
- argonaut 13y ago
  RequireJS allows for asynchronous loading. Browserify doesn't. That alone is a huge reason for why people use RequireJS.

akbar501 13y ago

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 13y ago
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.js https://github.com/jjt/dramsy/blob/master/client/Gruntfile.j... [2]: https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js https://github.com/jjt/LUXTRUBUK/blob/master/gulpfile.js
tomByrer 13y ago
If you want to compare build time, it would be best to add plug-ins that trigger only the tasks that deal with changed files: https://github.com/osteele/grunt-update https://github.com/osteele/grunt-update https://github.com/goodeggs/grunt-skippy https://github.com/goodeggs/grunt-skippy https://github.com/aioutecism/grunt-diff https://github.com/aioutecism/grunt-diff https://github.com/sindresorhus/gulp-changed https://github.com/sindresorhus/gulp-changed

cheapsteak 13y ago

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/

Q_the_Novice 13y ago

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.

Maxious 13y ago

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 13y ago
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 13y ago
  > 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.

mjackson 13y ago

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.

pfrrp 13y ago

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 13y ago
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 13y ago
  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.

emilis_info 13y ago

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.

jonursenbach 13y ago
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.
- skrebbel 13y ago
  Oh, how I long for the days when condescension was a thing reserved for Lisp programmers.
- emilis_info 13y ago
  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.
  - shadowmint 13y ago
    Really no. The makefile syntax is obscure and hard to maintain. We've been there. We don't need to go there again. The stories of 'recursive makefile dependency hell' deserve to stay back in the dark ages of the 90s where they belong. There's a reason lots of people are inventing new systems for doing these sorts of tasks (for example, spawning a local webserver to work with after compiling less and coffee files and parsing the output for errors and displaying them nicely, then watching the filesystem for changes and recompiling on demand). It's not because make is evil, it's because make does a poor job of some of these sorts of tasks. ...if all you're doing is turning .coffee files into .js, it's file, but it's not a solution for complex website builds.
    - 13y ago

ahallock 13y ago

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 13y ago
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.

tlrobinson 13y ago

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.

contrahax 13y ago
You can totally use gulp plugins outside of gulp. Since they are just streams, you can do some really cool stuff. I would love to see an http wrapper so you can do wrap(req).pipe(uglify()).pipe(res)
eknkc 13y ago
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 13y ago
  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

AndyKelley 13y ago

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 13y ago
Clever setup.

integricho 13y ago

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.

noname123 13y ago

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?

jondot 13y ago

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

nailer 13y ago
+1. I have spent more time reading about grunt than I have spent investigating + converting to + using gulp in production.
brokenparser 13y ago
I'd say Grunt is Maven because IDEs have no way to figure out beforehand what the build process will do.
- lmm 13y ago
  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.
tieTYT 13y ago
I agree with you that "Grunt is ant". But when I look at that code example it seems like "Gulp is ant", too. It's just less verbose. I think that Lineman is the Maven equivalent in the JS world.

indolering 13y ago

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…

contrahax 13y ago

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 13y ago
Many thanks from one who fought through the outdated source in the OP.

Kiro 13y ago

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

Cthulhu_ 13y ago
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.
CWIZO 13y ago
http://bladerunnerjs.org/blog/large-scale-complex-javascript-apps/ http://bladerunnerjs.org/blog/large-scale-complex-javascript...
joelhooks 13y ago
100,000 lines of JS is best divided into smaller parts.

ing33k 13y ago

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

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

ilaksh 13y ago

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.

prottmann 13y ago

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.

potomushto 13y ago
Typical build may look like this: Task 1 passing many files to Task 2, then to Task3, concatenate and so on. It's all about Disk I/O performance. Streams piping reduce files reading/writing.
jonheller 13y ago
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.

mehulkar 13y ago

This post reminds me of the joke about the Native Americans getting ready for winter[1] [1] http://voices.washingtonpost.com/capitalweathergang/2008/11/winter_weather_joke.html http://voices.washingtonpost.com/capitalweathergang/2008/11/...

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

mehulkar 13y ago

antihero 13y ago

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.

namuol 13y ago

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

namuol 13y ago

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.

mkaito 13y ago

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

mrcactu5 13y ago

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?

JanJanJan 13y ago

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

homborg 13y ago

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

stefan_kendall 13y ago

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 13y ago
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.

mikewhy 13y ago

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 13y ago

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 13y ago
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.
acjohnson55 13y ago
If only someone would Make something like that. Boy, that would really Make my day...

justinph 13y ago

Oooh, look at the shiny keys.

ballard 13y ago

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.

parris 13y ago

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?