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

Why we should stop using Grunt and Gulp

blog.keithcirkel.co.uk

Post reply on HN
Print view View original

81–90 of 108 posts

Re: Why we should stop using Grunt and Gulp

#81

Post by pjmlp »

rbanffy wrote: post #77
pjmlp wrote: post #76

Earlier quoted context omitted.

Because it isn't portable, not even across UNIX/POSIX systems. Each make has it own set of extensions outside of what POSIX requires. Additionally, for almost every task you need to call out to external tools that also have their own set of compatibility issues across UNIX/POSIX systems. Ideally everyone writing a Make script would need to read the POSIX standard and only use common features, but since that isn't the…

> Because it isn't portable, not even across UNIX/POSIX systems. How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?

You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-Kernel/POSIX, LynxOS...

There are lots of POSIX systems out there.

Re: Why we should stop using Grunt and Gulp

#82

Post by lerouxb »

Daiz wrote: post #71

The author has a follow-up post that addresses a lot of things that are also popping up in the comments here: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... EDIT: Also a HN submission by the author himself: https://news.ycombinator.com/item?id=8721929

Looks like he just traded grunt/gulp for browserify which is also a build tool with lots and lots of configuration and plugins and I'd rather be using webpack in that category.

Just switch to webpack and you don't have to bend npm or browserify to your will either.

Relevant presentation: http://adrianrossouw.github.io/webpack-uber-alles/

Re: Why we should stop using Grunt and Gulp

#83

Post by lerouxb »

Kiro wrote: post #38
skrebbel wrote: post #21

tl;dr: The author meant to say "Use Browserify instead of Grunt/Gulp" but then got all confused and wrote some unrelated stuff about how npm has a case..esac statement built in. While we're at the subject, might I suggest using webpack instead of browserify? It's roughly the same, but less buggy.

How is Browserify/Webpack a replacement for Grunt/Gulp? Genuine question.

It isn't a replacement for Grunt/Gulp. It is a replacement for browserify or perhaps require.js.

It builds your javascript and css (and images!) into one or more bundles which does overlap with what people often use grunt for. In my experience it generally obviates the need for grunt because what's left to do once you've packaged and minified your js, css and images and you have your source maps, etc.?

I suppose the rest can be done with npm scripts, but simple tasks like running tests could even be done from bash or a makefile anyway.

Here's a good recent presentation on webpack: http://adrianrossouw.github.io/webpack-uber-alles/

Re: Why we should stop using Grunt and Gulp

#84

Post by rbanffy »

pjmlp wrote: post #81
rbanffy wrote: post #77

Earlier quoted context omitted.

> Because it isn't portable, not even across UNIX/POSIX systems. How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?

You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-Kernel/POSIX, LynxOS... There are lots of POSIX systems out there.

I know people who develop (and use make) on BSD and OS X (I do), but, seriously, is any OS on our lists (OS X, (Open)Solaris-derivations and *BSD excepted) likely to be the target for the kind of software Grunt is used to develop?

Re: Why we should stop using Grunt and Gulp

#85

Post by rbanffy »

nraynaud wrote: post #64
xrstf wrote: post #60

Earlier quoted context omitted.

It's different in the way that it's trivial to use npm to install grunt and run builds on Windows, but not trivial to get a Makefile to run (if you don't want to resort to running cygwin bashs all the time).

my recollection from my windows times, is that cygwin is a pain to install and slow too, so there is no free lunch.

> is a pain to install

They have a setup.exe that downloads the components you select. I gather it's not as painless as "apt-get install cygwin" would be, but it's as painless as installing Windows software is.

> and slow too

They are painting a Linux-environment on top of a Windows OS. That's no small feat. In return you get a sensible file space, a decent command line and all the development tools you'd need on Linux. It's slower than a Linux box running on the metal, but it's as fast as a VM would be and has direct access to the host operating system (and, for me, a working Python environment where I can simply say "pip install ipython" and everything just works. I would not even consider working from Windows without it.

Re: Why we should stop using Grunt and Gulp

#86

Post by rbanffy »

I have some similar feelings about buildout (http://www.buildout.org). Both Grunt and Buildout (and Maven and so many others) can do many things beyond running commands based on their dependencies and that's what makes me uncomfortable with them: they violate the do-one-thing principle. They try to do everything, be The One Tool To Do It All.

I am myself guilty of somehow abusing make (https://github.com/rbanffy/testable_appengine) and convince it to do things it was not really designed to do, but that's only because make is so easy (and because it's already there on every machine I touch - or shortly after I touch them).

Re: Why we should stop using Grunt and Gulp

#87

Post by icantthinkofone »

Too wrote: post #19

I found all build systems for all platforms to be a total PITA and eventually i just resort to using a shell or python script to invoke the commands i want. With this method you can very easily add user promting (do you want to build debug or release?), database reporting of build and test results, source control integration etc. Whatever i learn here can be applied and reused for new things in the future instead of…

It's interesting to watch the commentors to your post say the way to fix the problems with tools is with a tool to fix the tool which is at least one of the issues outlined in the article.

Re: Why we should stop using Grunt and Gulp

#88

Post by pjmlp »

rbanffy wrote: post #84
pjmlp wrote: post #81

Earlier quoted context omitted.

You left out HP-UX, Aix, Tru64, Solaris, BSD, QNX, Mac OS X, IBM i, z/VM, eT-Kernel/POSIX, LynxOS... There are lots of POSIX systems out there.

I know people who develop (and use make) on BSD and OS X (I do), but, seriously, is any OS on our lists (OS X, (Open)Solaris-derivations and *BSD excepted) likely to be the target for the kind of software Grunt is used to develop?

Most likely not, my point was just to pass the information specially to those stuck in GNU/Linux, that it isn't as portable as many think it is.

Re: Why we should stop using Grunt and Gulp

#89

Post by lhnz »

As long as you're not trying to make the world's most complex build file do not feel that you need to use overly complex build tools.

A better approach is to learn the basics of writing Makefiles.

Simple tools are good.

And Make is reusable.

Make also has the benefit that you can copy-paste lines into your shell to test them. This is something that is very awkward to do with Grunt or Gulp and it makes it a lot easier to debug problems.

Generally when I say it to people they say "but if you have a complicated build process you need these tools!", and my response is "what business value did your 400+ line build process create and will it be worth the inevitable problems you will have to debug later?"

It might be unpopular advice but if you create a project with far less dependencies then there is less that can break later on.

Re: Why we should stop using Grunt and Gulp

#90

Post by joshstrange »

I can fully understand not liking Grunt, it's configuration is impossible to read and doesn't make a ton of sense to me. Gulp on the other hand is VERY easy to read and I haven't have any issues with my colleagues adding/editing the gulpfile.

Is running `gulp jshint` similar to running `jshint .js`? yes but this is not a fair comparison. First of all one of those can be run in the root of the project while the other needs to be run in the right location (or have the folder in the path) so that we don't jshint libs we didn't write. Also the author glosses over the fact that people rarely run `gulp *` and in fact will run `gulp build` (or similarly named task) that will call ALL of the other tasks you need to run. Also the author doesn't mention how wonderful `gulp watch` (or similarly named task) is for watching files for changes and then running tasks when certain files change.

I can tell you with 100% certainty that without gulp we would not be jshint-ing our code, we probably will still be using regular CSS and not SASS (SCSS-style), would still have a large gross master.js file instead of multiple js files with logic cleanly separated out, etc. Could we use make? Yes but having worked at a company that used make to build various parts of their web app I can tell you that this get really gross really fast, feel free to disagree with me but after seeing how bad it can get I won't touch make for web projects again.

Gulp (I won't argue for Grunt, I don't like it at all) is easy to write and easy to read and running the programs/tasks Gulp does for us individually would have been a non-starter. As far as npm/make goes it would have been harder to do everything we are doing and I'm not even sure `gulp watch`-type features would have been possible without escalated privileges to install other software.

Post reply on HN