Live data from Hacker News

Gulp.js: The streaming build system

gulpjs.com

41–50 of 53 posts

Re: Gulp.js: The streaming build system

#41

Earlier quoted context omitted.

You can skip. I get that front end stuff can be intimidating. My recommendation is to learn the basics and when it comes to libraries fight the intimidation and take a few minutes to try out new technology when you encounter it. If you find it too hard in those few minutes of actually trying it, don't use it. You can still use script tags if you want. Your site will run just fine. Do what feels comfortable. These too…

I practically live and die by the 5 Minute Rule, and as a counterpoint, I've always found Grunt intuitive, if verbose. In particular, I love that its files API is so flexible. I frequently find myself asking questions that look like "I wonder if I can do this X way", and things just work. Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling. [edited…

> Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling.

I'm speaking from personal experience and time lost trying to just get things to work so I can focus on building the application, not making a hobby out of building the frontend tooling. What I said may be harsh, but it's the truth. Have you tried gulp?

Re: Gulp.js: The streaming build system

#42

Grunt isn't worse than Gulp. It may take longer to set up, but it is way more powerful if you do it correctly. Maybe Gulp has evolved, but the last time I used it (~4 months ago) it had its fair share of issues. If you're doing simple tasks (uglify all of this folder to this folder) it works well. When I used it there was no simple way to copy files from one dir to another. Instant no for me there.

Something like this? IIRC this would've worked 4 months back:

  gulp.task('copy', function() {
    return gulp.src('src/foo/**/*').pipe(gulp.dest('dest/foo'));
  });

Re: Gulp.js: The streaming build system

#43

I credit gulp with finally making me 'get' streams, even though I had tangled with them before. It's API is one of the [1] biggest inspirations to code I write nowadays and it also helped me come to grips with the fact that code > config in almost every eventuality. All of that said, webpack is so very far ahead of everything else in the field that there is almost no way I would use anything else. It also has the sid…

Was there any particular intro to Gulp that provided this revelation about streams? As far as I know, I 'get' streams, but now you're making me wonder. :)

Re: Gulp.js: The streaming build system

#44

I've switched most of my projects to Gulp from Grunt as I prefer code over config. One thing that I wish Gulp did out of the box though would be not to terminate on errors but rather beep without having to write .on('error', ...) handlers.

Adding gulp-plumber will fix this, but I agree, it should be available out of the box.

https://www.npmjs.org/package/gulp-plumber

Re: Gulp.js: The streaming build system

#45

Earlier quoted context omitted.

I practically live and die by the 5 Minute Rule, and as a counterpoint, I've always found Grunt intuitive, if verbose. In particular, I love that its files API is so flexible. I frequently find myself asking questions that look like "I wonder if I can do this X way", and things just work. Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling. [edited…

> Saying Grunt is "very bad" is harsh and only serves to amplify hyperbole that causes much of the churn around JS tooling. I'm speaking from personal experience and time lost trying to just get things to work so I can focus on building the application, not making a hobby out of building the frontend tooling. What I said may be harsh, but it's the truth. Have you tried gulp?

I have, and I'd even be up for using it on a production project. I'd go so far to say I like it even. But the fact stands that the current project I'm working on has a Gruntfile that just flat out wouldn't work in Gulp - which is a combination of things that I'm doing that don't have an analogue in Grunt, likely mixed with a few that I simply wasn't able to figure out.

If Grunt makes sense on some projects, and Gulp makes sense for others, why the need for all the value judgements? I still stand by the assertion that such claims add nothing to the conversation and muddy the waters for everyone.

Re: Gulp.js: The streaming build system

#47
A little OT:

People here are mostly saying to use webpack. Webpack is not a replacement for all of gulp but does work well with it (as do the other JS builders).

I recently did a tour-of-duty looking for the best JS build system. I settled on gulp early (over grunt) because grunt files were just too big to do the same thing. But Gulp is not the best for some aspects of JS building (bundling for multiple-pages). For those, I looked at RequireJS, Browserify and Webpack. Here's my overview opinion:

- RequireJS - a great starter and very powerful. Since it's old and not well-liked in the NodeJS community, people seem to not give it the credit it is due. Documentation could use some updating (some of the nuances of RequireJS take some googling). The one feature that this has that others don't is that you don't need a server to take advantage of it so you can start actually coding now and optimize as your project grows. - Browserify - great for building libraries that you expect to run on NodeJS and in the Browser. But it really falls short on building multiple bundles and dynamically loading resources (it's possible, just annoying). Watchify (auto-building) is nice. - Webpack - The cream of the crop. Multiple pages, dynamic loading, auto-bundling, built-in dev-server to monitor changes. If you have a project that is more than one-page, use webpack.

When using any of these with gulp, I would not use the gulp plugins. Rather use the NodeJS APIs alone. It may be a tad more cumbersome, but the gulp plugins mostly just try to shoe-horn gulp's streaming into a file-based API (and it's limiting).

Re: Gulp.js: The streaming build system

#48
post #32

Earlier quoted context omitted.

Even though they are clearly related, Gulp and Grunt are fulfilling different purposes. You should carefully examined your needs before choosing one over another. I recently switched to Gulp for several projects, and I'm thinking of switching back to Grunt. Gulp lacks of some important features. For instance, it does not allow to sequentially execute tasks: everything is done in parallel. This could for sure be emula…

> it does not allow to sequentially execute tasks: everything is done in parallel There's a package[1] for Gulp which does exactly that. [1]: https://www.npmjs.org/package/run-sequence

I didn't know about it! Thanks

Re: Gulp.js: The streaming build system

#49

Earlier quoted context omitted.

Even though they are clearly related, Gulp and Grunt are fulfilling different purposes. You should carefully examined your needs before choosing one over another. I recently switched to Gulp for several projects, and I'm thinking of switching back to Grunt. Gulp lacks of some important features. For instance, it does not allow to sequentially execute tasks: everything is done in parallel. This could for sure be emula…

We're adding the ability to handle sequential tasks (and other cool combinations) in Gulp 4. See bach[1] for some ideas. [1]: https://github.com/phated/bach

I remember some discussions on Gulp's issues tracker where maintainers were reticent about integrating sequential tasks execution.

But that's great if you are going to do it. This may make me come around and give a second chance to Gulp.

Re: Gulp.js: The streaming build system

#50

I've switched most of my projects to Gulp from Grunt as I prefer code over config. One thing that I wish Gulp did out of the box though would be not to terminate on errors but rather beep without having to write .on('error', ...) handlers.

This is being fixed in gulp 4 - check github issues for more info
Post reply on HN