Live data from Hacker News

The Ultimate Frontend Build tool: make

algorithms.rdio.com

71–80 of 121 posts

Re: The Ultimate Frontend Build tool: make

#71
The problem with make is not that it's bad, it's that's it's only really good at doing two things:

1) mapping a source pattern to an output pattern

2) managing dependencies between rules

To be fair it's good at those, and often the sorts of things you can do with a rule are quite complex (being basically shell scripts).

However, the problem is that 1) it's an obscure DSL and 2) that it is really rubbish at doing more complicated things.

For example, grunt-contrib-clean lets you: delete any files that match a regex, not leave alone any files that match a different regex. Grunt also has a built in templating language that can be used to expand configuration files from submodule into local build scripts without copying the entire gruntfile. grunt-open launches a browser to a dev url cross platform. The list goes on and on and on.

Make is terribly terribly bad at complex tasks like this, that's the problem.

You can write a custom shell-script / ruby-script / python-script for these tasks, but why would you? Someone else already has. Dont repeat all the things every time with your own code.

If all you need to do is map .c to .o, or .scss to .css and .coffee to .js, use make, totally. It's good at that.

Otherwise, stay away.

Re: The Ultimate Frontend Build tool: make

#73

Earlier quoted context omitted.

And yet most contemporary hipster build systems are all just shiny make reinventions.

My preferred hipster build system (CMake) actually leverages make on UNIX platforms and nmake on Windows :). It just replaces the most of the autoconf mess.

> It just replaces the most of the autoconf mess.

With a non-standard mess on its own ...

CMake is pretty bad at doing things (standard paths, install targets etc.) that the GNU folks solved a long time ago. Yes, the Autotools are a royal PITA but at least a pain that one knows how to deal with.

Re: The Ultimate Frontend Build tool: make

#74
post #62

It's shit like this, HN. Why you guys make this nonsense end up on the frontpage is honestly beyond me. So this guy re-implemented the most useful grunt tasks in his own language. Grats. You've wasted time instead of using Grunt. Saving time and not re-implementing things was the point all along. Very few people want to write "small programs" to chain together build tasks. They should be readily available, just work,…

Making small shell scripts and the appearance of the syntax is a matter of taste, I guess. I personally quite enjoy knowing exactly what a script does but the appeal of make to me is that I can use it in non-JS projects, too.

I recently had the need to automate batch of converting XCF files to PNG files. Writing and publishing a Grunt module just for that seems a bit over the top, and it would end up a wrapper for a few lines of bash anyway.

Re: The Ultimate Frontend Build tool: make

#75
post #34

Is anyone familiar with SCons? I stumbled across it the other day when I was playing with gpsd.[^1] [^1]: ESR lovefest: http://esr.ibiblio.org/?p=3089

I last used it 7 years ago. It was nice, but extremely slow, and required more tweaking than originally seemed. I don't know if either thing improved in the last 7 years.

Re: The Ultimate Frontend Build tool: make

#76
post #62

It's shit like this, HN. Why you guys make this nonsense end up on the frontpage is honestly beyond me. So this guy re-implemented the most useful grunt tasks in his own language. Grats. You've wasted time instead of using Grunt. Saving time and not re-implementing things was the point all along. Very few people want to write "small programs" to chain together build tasks. They should be readily available, just work,…

Making small shell scripts and the appearance of the syntax is a matter of taste, I guess. I personally quite enjoy knowing exactly what a script does but the appeal of make to me is that I can use it in non-JS projects, too. I recently had the need to automate batch of converting XCF files to PNG files. Writing and publishing a Grunt module just for that seems a bit over the top, and it would end up a wrapper for a…

You can use Grunt and gulp for any sort of projects, not just ones involving JS.

Re: The Ultimate Frontend Build tool: make

#78
The thing I like about Gulp is that all it needs is NPM to install all its stuff. Make you have to worry about different system libraries, etc. Also, with gulp I can leverage other node based libraries, so for one project, I can get frontend guys set up using a dev server which automatically both proxies API requests to a backend server, and also watches and livereloads files (as they like), with three damn commands - npm install && bower install && gulp dev. Bam. Working dev server running on port 8000 that does all that they need it to.

Re: The Ultimate Frontend Build tool: make

#80
post #18
post #8

With the theme of ageism and NIH being brought up a lot lately, I'm glad to see that the neck-bearded unix philosophy (tm) of composition and single purpose are winning over these complicated object oriented frameworks.

I'm not sure I would go as far as calling Grunt a complicated OO framework, but the first thing that crossed my mind when looking at Grunt was 'why not use make?' It may not be perfect, but at least you get incremental builds.

incremental builds are possible with Grunt using grunt-newer: https://github.com/tschaub/grunt-newer
Post reply on HN