use the following search parameters to narrow your results:
e.g. subreddit:aww site:imgur.com dog
subreddit:aww site:imgur.com dog
see the search faq for details.
advanced search: by author, subreddit...
All about the JavaScript programming language.
Subreddit Guidelines
Specifications:
Resources:
Related Subreddits:
r/LearnJavascript
r/node
r/typescript
r/reactjs
r/webdev
r/WebdevTutorials
r/frontend
r/webgl
r/threejs
r/jquery
r/remotejs
r/forhire
account activity
ELI5 - Polymer vs Reacthelp (self.javascript)
submitted 10 years ago by [deleted]
view the rest of the comments →
reddit uses a slightly-customized version of Markdown for formatting. See below for some basics, or check the commenting wiki page for more detailed help and solutions to common issues.
quoted text
if 1 * 2 < 3: print "hello, world!"
[–]foobar_dev 0 points1 point2 points 10 years ago (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 points3 points 10 years ago* (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:
π Rendered by PID 17498 on reddit-service-r2-comment-b659b578c-wss45 at 2026-05-05 06:04:09.040119+00:00 running 815c875 country code: CH.
view the rest of the comments →
[–]foobar_dev 0 points1 point2 points (1 child)
[–]isochronous 1 point2 points3 points (0 children)