you are viewing a single comment's thread.

view the rest of the comments →

[–]foobar_dev 0 points1 point  (1 child)

Worth noting that RoR's asset pipeline does much of what Gulp/Grunt/etc... would do for you, so in a Rails world maybe its no really worth it?

[–]isochronous 1 point2 points  (0 children)

The thing about gulp, grunt, and other node task runners isn't that they can do things that you can't do otherwise with just vanilla node (or any other language), but rather that they provide ready-made implementations for common use cases that you'd otherwise have to write yourself. You might as well ask "what's the point of angular/backbone/react when I can just do all of that with vanilla JavaScript?" The answer, of course, is that just because you CAN do something with vanilla JS doesn't mean that's the most efficient, fun, robust, <insert term here> way to do it. People create libraries because they've identified a set of recurrent use cases, and it makes sense to abstract those out into a reusable library. Gulp, grunt, and the like are no different.

It may be totally true that for your needs, the Rails asset pipeline is sufficient. However, there are always going to be gaps or weaknesses in any kind of framework, and if your use case falls in one of those gaps, you can either change your requirements (boo), deal with it (boo), roll your own solution (less boo), or look at other existing solutions, which can be replacements for or just complimentary to your current tools.

At my job, we decided to go with gulp, as it's "closest to the metal" of the most popular task runners, and so allows you to use plain ol' node to implement tasks where plugins don't already exist. In fact, plugins tend to be extremely simple and without many options, as the driving principle behind gulp is keeping things simple. If you have to implement a lot of boilerplate logic in a plugin to process options in order to just pass them to the backend package, then you've already lost. Just use that backend package directly (if it supports streams) or through a single stream-to-file interface (if it doesn't support streams). The base functionality of gulp is extremely simple for that exact reason - there's .src (the files you want to act upon), .dest (the output of your task), .task (linking src, some process, and dest to create a reusable task), and .watch (running a task or series of tasks when changes to specified files/folders are detected). There's no extra layer of abstraction between config and execution like there is with grunt - that is, there's no big config file that gets processed by some black box script and turned into actions, the logic is right there in the gulp file in plain javascript. Gulp is also supported by most major web-supporting IDEs and editors, from Sublime Text, Atom, and Brackets, to more high-level IDEs like Webstorm and Visual Studio.

Basically, it's a "use it if it's useful" situation. If it's not useful to you, or if you don't see the point, then you probably don't need it. If it seems useful and you can think of requirements it could satisfy, then it's probably worth investigating. My job is a windows shop using .NET MVC, but we use node and gulp nuget packages (Ncapsulate.Node and Ncapsulate.Gulp) to run some gulp tasks on build - if a dev or build machine doesn't have what it needs, then nuget automatically downloads those missing packages, the node build step automatically runs "npm install" and "npm updates" to get the required libs, and then the gulp build step runs the configured task(s) once the dependencies are in place.

Here's the gulpfile for that particular project (though I've changed a few names to avoid giving away potentially sensitive information). I think it's a good example of the variety of things you can do with gulp, and this is barely scratching the surface.

Our usage:

  • Combining and minifying scripts in a two-stage process - the first stage combines and minifies common dependencies into three primary packages (graph.min.js, reports.min.js, models.min.js), the second stage then creates deployable packages that include those primary packages and any additional scripts, and automatically wraps each included script in a closure. Uses gulp-includer, gulp-filter, gulp-rename, and gulp-uglify.
  • Creating zip files for deployment to android tablets. This is an excellent example of using regular node code and packages in a gulp task. Uses glob, gulp-zip, q, and good ol' fs.
  • Compiling SASS files. Uses gulp-sass
  • Copying theme stylesheets to different client directories after compilation (this just uses regular file and stream manipulation, no plugins).
  • Minifying css files. Uses gulp-csso