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

The Ultimate Frontend Build tool: make

algorithms.rdio.com

Post reply on HN
Print view View original

111–120 of 121 posts

Re: The Ultimate Frontend Build tool: make

#111

Post by Offler »

rjd wrote: post #58
jeffbr13 wrote: post #40

Earlier quoted context omitted.

They've used Grunt for builds for a while now[0]. It seems most of the twitter-style web developer community who happily replaced `make` with `rake` when developing for Rails simply followed that with `grunt` when they moved to JavaScript. [0]: https://github.com/twbs/bootstrap/commit/0d33455ef486d0cf06c...

Cool, I've read good things about grunt but haven't had the time to look into it. Its direct access to the CLI thats the killer for me with make ... and to be frank ... if I was going to script in a third party language it would probably be python and not javascript but each to there own.

Don't rely too much on Grunt, only use Grunt/Gulp when npm scripts doesn't do the trick. npm scripts has the same direct command invocation that make has so no need for plugins.

Re: The Ultimate Frontend Build tool: make

#112

Post by Offler »

antihero wrote: post #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…

I would use npm scripts as the first way to execute build steps in a package and only fall back to Gulp when it's not powerful enough https://www.npmjs.org/doc/misc/npm-scripts.html

Re: The Ultimate Frontend Build tool: make

#114

Post by auvrw »

gkya wrote: post #103
shadowmint wrote: post #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…

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've spe…

i was going to say something in response to the article about dependencies from a positive standpoint for grunt, but i think it makes sense to put it here.

rather than having a unix development environment for the browser platform, thanks to lighttable, grunt, and others, it's possible to use node/web-browsers as a development environment as well. i guess node isn't as venerable as unix or even the jvm for that matter, but is "infant" really a fair characterization? i've heard that node can actually do some types of string processing faster than the jvm.

i totally agree on starting with shell scripts, though. i tend to put short scripts all throughout repos, even if they just run a single command with a few arguments. sometimes they grow into longer scripts, and sometimes they get changed to run different programs (e.g. gruntmake), but having a few consistent names for tasks like build, run, test, and deploy (.sh) across projects and languages goes a long way to cut back on cognitive load.

Re: The Ultimate Frontend Build tool: make

#115

Post by shadowmint »

gkya wrote: post #103
shadowmint wrote: post #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…

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've spe…

    grunt uses a JSON file
Actually grunt uses a javascript file you can drop node code into (not a stupid DSL, an actual programming language no less).

    I'd rather rewrite a 4-LOC shell script in my new project...
Anyway, if you want to throw away your precious developer hours writing yourself a new makefile build system for every project and throw away the nice principles of code reuse, you can.

...just maybe don't tell who ever is paying you that you're doing it that way.

(or wait, you can reuse code with make can't you? It's called autoconf or something like that...)

Re: The Ultimate Frontend Build tool: make

#116

Post by WickyNilliams »

andrey-p wrote: post #84
lowboy wrote: post #76

Earlier quoted context omitted.

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

I've only used Grunt briefly so I could be completely wrong, but I was under the impression you still need to create a node module for your task if it doesn't exist? You need to package it up somehow, link it in the gruntfile and so on. In my use case, I was using a CLI utility called xcf2png. Writing a wrapper module seems like loads more work than a bash one-liner that calls xcf2png, no?

grunt-shell let's you call out to the shell. Very easy to set up

https://github.com/sindresorhus/grunt-shell

Re: The Ultimate Frontend Build tool: make

#117

Post by r0muald »

mysteriousllama wrote: post #21
forrestthewoods wrote: post #19

God I hate make. I hate make so very, very much. Compiling code isn't that hard. I swear to the programming lords on high it isn't. Here's a wonderfully useful open source project - Google gperftools [1]. It includes TCMalloc amongst other things. The Makefile.in is 6390 lines long. Configure is 20,767 lines long. Libtool is 10247 lines long. That's fucking insane. Compiling OpenSource is such a pain in the ass. Part…

What you are describing is autoconf, not make. Make by itself is actually a very handy tool for performing tasks that have a dependency graph. Autoconf.. Well, I can't disagree. It's a hack built on top of a hack and should probably be rethought. Once autoconf is done generating Makefiles, make itself is generally trouble-free. http://freecode.com/articles/stop-the-autoconf-insanity-why-...

mk-configure is a "lightweight" autotools replacement

" rel="nofollow">http://sourceforge.net/projects/mk-configure/>

Re: The Ultimate Frontend Build tool: make

#118

Post by catenate »

pedrocr wrote: post #32

redo[1] is almost never mentioned in these discussions. Has anyone tried it in anything significant? It looks good and is a djb design. [1] https://github.com/apenwarr/redo

Inspired somewhat by redo, I wrote "credo" as a set of small command-line build tools, so build description files are in the shell language rather than a standalone DSL.

https://github.com/catenate/credo

(I don't like how makefiles have so many features that reimplement what you can do in the shell. I also don't care for big languages with build-tool DSLs--though you could say credo is a build-tool DSL for the shell, like git is a version-control DSL for the shell. With only language directives, no constructs.)

I wrote it in the Inferno shell to take advantage of some nice OS features and its cleaner shell language. One of these days I should port it to bash, so other people might use it.

Re: The Ultimate Frontend Build tool: make

#119

Post by gkya »

auvrw wrote: post #114
gkya wrote: post #103

Earlier quoted context omitted.

There are other benefits to make. First, you'll need to ask users to install grunt, whereas make is standard and is just there (except for Windows, probably). Second, make provides a language that is optimised to express the information it needs, whereas grunt uses a JSON file. It gave me headaches when I needed to edit grunt config at my last job, and I never touched grunt ever since. Third, all the tasks you've spe…

i was going to say something in response to the article about dependencies from a positive standpoint for grunt, but i think it makes sense to put it here. rather than having a unix development environment for the browser platform, thanks to lighttable, grunt, and others, it's possible to use node/web-browsers as a development environment as well. i guess node isn't as venerable as unix or even the jvm for that matte…

> ... but is "infant" really a fair characterization?

The point I wanted to make was that one needs to install node to run grunt; I don't believe there's any OS that distributes node in the base distribution, whereas make and sh is a part of the POSIX standard, and perl/python is available by default on most OS's.

Also, node is indeed infant and young, don't consider that a bad characterisation, I do enjoy playing with node. My plea is that one should not need to install some software to run the build scripts in a project they download.

Post reply on HN