Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Left Gulp and Grunt for Npm Scripts

medium.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Why I Left Gulp and Grunt for Npm Scripts

#31

Post by jakub_g »

The `cross-env` used by the author seems useful, I didn't know about that, and for this reason I'd usually write a separate bash script when I wanted to execute something like

  FOO=1 some-command
because this syntax doesn't work in `package.json` on Windows.

BTW. If you're not into bash for writing long scripts, it's pretty easy to write shell scripts in nodejs. Node 0.12+ has native `execSync` that is nice to have to write build code in JS in synchronous way. I wrapped it with two helper functions to have sth like `execAndPrint` and `execAndReturn`:

https://gist.github.com/jakub-g/a128174fc135eb773631

It's not as powerful as bash script (doesn't support | syntax for redirecting etc) but if you need that, you can extract it away to a helper bash script.

See also https://github.com/shelljs/shelljs

Re: Why I Left Gulp and Grunt for Npm Scripts

#32

Post by jessaustin »

punkbit wrote: post #2

Why don't they provide a good working example, using Browser Sync or LiveReload, Sass, etc ? I haven't found a good build process using npm as a task manager or build tool; I haven't seen any good example on any article I've read so far; gulp was built for, and it's much clear in my opinion!

Here's something I've been using recently:

  $ jq .scripts package.json 
  {
    "start": "npm-run-all --parallel client server live",
    "client": "beefy client/index.coffee:index.js $npm_package_config_beefy_port --cwd client -- --transform coffeeify --extension '.coffee'",
    "server": "BEEFY_PORT=$npm_package_config_beefy_port LIVE_PORT=$npm_package_config_live_port PORT=$npm_package_config_port nodemon --watch server --watch template --ext coffee,jade server/app.coffee",
    "live": "live-reload --port=$npm_package_config_live_port --delay=3000 client server template"
  }
No sass in there, but one can see it could easily be added.

Re: Why I Left Gulp and Grunt for Npm Scripts

#33

Post by gotchange »

pjmlp wrote: post #23

I am so happy to have left the web back into native, just about when gulp, grunt, npm, yeoman and friends were picking up steam. It is not enough to jungle DOM libraries, CSS generation, JavaScript frameworks, browser compatibility headaches, one also needs to use the build tool of the day.

If you're using any of those tools above just because they're en vogue, you're doing it wrong. You use those tools because they solve specific problems that you're facing and to make your job easier and not because the "cool kids" on the block are using them.

I'd say that nearly all the tools listed in your comment serve a purpose and solve specific problems and ease certain pain points that I deem them useful and assets in my workflow.

Re: Why I Left Gulp and Grunt for Npm Scripts

#34

Post by untog »

I was struggling to integrate Webpack, Browsersync, hot reloading, Mocha and much more using Gulp

I'm a little unclear on why you'd try to integrate Webpack into Gulp - Webpack is more than sufficient by itself. And I've tried using NPM-only scripts, but they haven't yet matched the dev server, hot reloading, production-readying functionality inside Webpack.

Webpack configuration files are absolutely gross, though.

Re: Why I Left Gulp and Grunt for Npm Scripts

#35

Post by talmand »

I may not have been in the node and npm space long enough to fully understand the point of this, but it sounds like the endless argument of "stop using jQuery and go with raw Javascript instead".

The argument goes that modern Javascript has moved far enough along that a library like jQuery is not as necessary. But the majority of the examples I've seen of how to avoid jQuery means essentially coding your own custom version of jQuery.

This argument of dropping Grunt/Gulp seems the same to me. "Don't use a pre-coded builder or task runner, just build it yourself". I'm not sure I agree that's necessarily the best route for every project and/or coder.

Right now I've been playing with node and gulp, just for fun. So far I've found the most comfortable route for me is to have gulp kick off the process and then use non-gulp packages when it feels right. For instance, I don't use a gulpified version of Handlebars, I just use the actual npm package. I can't say this is the "best standards" way to go about it, but it feels right for me.

Re: Why I Left Gulp and Grunt for Npm Scripts

#36

Post by gotchange »

> I’ve found Gulp and Grunt to be unnecessary abstractions. npm scripts are plenty powerful and often easier to live with.

The main problem with this line of reasoning is that as things get more complex and expansive over time (and they will do as night follows day) on the npm scripts front, the developer would likely resort to build abstractions to hide all the tangled wires and simplify the dev process and then we're back to square one.

Abstractions are necessary evil but they should be built and also managed efficiently and wisely to avoid the common pitfalls and pain points and make the development process easier and less annoying.

Re: Why I Left Gulp and Grunt for Npm Scripts

#38

Post by pjmlp »

gotchange wrote: post #33
pjmlp wrote: post #23

I am so happy to have left the web back into native, just about when gulp, grunt, npm, yeoman and friends were picking up steam. It is not enough to jungle DOM libraries, CSS generation, JavaScript frameworks, browser compatibility headaches, one also needs to use the build tool of the day.

If you're using any of those tools above just because they're en vogue, you're doing it wrong. You use those tools because they solve specific problems that you're facing and to make your job easier and not because the "cool kids" on the block are using them. I'd say that nearly all the tools listed in your comment serve a purpose and solve specific problems and ease certain pain points that I deem them useful and as…

We don't choose our tools, the customer's IT does it, so are the wonders of consulting when you work on existing projects.

And they choose them, because they follow fashion.

Re: Why I Left Gulp and Grunt for Npm Scripts

#39

Post by gotchange »

talmand wrote: post #35

I may not have been in the node and npm space long enough to fully understand the point of this, but it sounds like the endless argument of "stop using jQuery and go with raw Javascript instead". The argument goes that modern Javascript has moved far enough along that a library like jQuery is not as necessary. But the majority of the examples I've seen of how to avoid jQuery means essentially coding your own custom v…

Yeah there's some Not Invented Here (NIH) sentiment to this behavior and it's holding back the community from moving forward and exploring new frontiers and solutions than reinventing the wheel or tearing down structures to rebuild them only to tear them down shortly again and so on and so forth.

Re: Why I Left Gulp and Grunt for Npm Scripts

#40

Post by gotchange »

pjmlp wrote: post #38
gotchange wrote: post #33

Earlier quoted context omitted.

If you're using any of those tools above just because they're en vogue, you're doing it wrong. You use those tools because they solve specific problems that you're facing and to make your job easier and not because the "cool kids" on the block are using them. I'd say that nearly all the tools listed in your comment serve a purpose and solve specific problems and ease certain pain points that I deem them useful and as…

We don't choose our tools, the customer's IT does it, so are the wonders of consulting when you work on existing projects. And they choose them, because they follow fashion.

Do your customers really dictate that you use grunt or gulp in your build process in their project?

I seriously find this to be very implausible.

Post reply on HN