Live data from Hacker News

The Ultimate Frontend Build tool: make

algorithms.rdio.com

61–70 of 121 posts

Re: The Ultimate Frontend Build tool: make

#61

Earlier quoted context omitted.

If you're managing dotfiles with Make (which I attempted once...) then may I direct you to GNU Stow instead? It's much easier to manage a bunch of files centrally and just symlink to them all: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

The problem I seem to be having with various dotfiles tools is they seem to be doing too much, where a script with a bunch of calls to ln -s would do.

May I introduce you to dircombine? Take multiple directories full of dotfiles and symlink them all into another directory.

http://git.kitenet.net/?p=joey/home.git;a=blob_plain;f=bin/d...

Re: The Ultimate Frontend Build tool: make

#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, be continously updated, and work cross platform. I don't want to go look into the intricacies of compiling Handlebars templates just to do that shit.

Also, a make file syntactically looks like garble compared to a well honed Gulp / Broccoli file.

Re: The Ultimate Frontend Build tool: make

#63
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

Thanks for pointing this out! I've been hoping djb would get around to releasing redo, but this is the next best thing.

Re: The Ultimate Frontend Build tool: make

#64

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…

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

Most new things are inspired by something else to the extent that they can be viewed as reinventions. So that's a moot point, and doesn't contribute at all.

Re: The Ultimate Frontend Build tool: make

#65
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.

Exactly my thoughts too, after reading the ageism article. An "old guy" (like me) would not even think twice and just "make" great use, as he has always been and with great success nor the time-consuming need of learning a possibly "unpolished" tool that does not have all the bells and whistles. This is very similar to the NoSQL trap, and countless other technology short-cuts you have to run into before fully understanding why they might be a trap for your org. And its the same reason why we old guys are sometimes disliked - for being critical about all these shiny, new "reinventing the wheel" tools. A tool that is not a decade old in many cases simply isn't battle proof. The problems with us "old ones" maybe starts if we make this a rule rather than a principle of caution, though...

Re: The Ultimate Frontend Build tool: make

#66
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.

Exactly my thoughts too, after reading the ageism article. An "old guy" (like me) would not even think twice and just "make" great use, as he has always been and with great success nor the time-consuming need of learning a possibly "unpolished" tool that does not have all the bells and whistles. This is very similar to the NoSQL trap, and countless other technology short-cuts you have to run into before fully understanding why they might be a trap for your org. And its the same reason why we old guys are sometimes disliked - for being critical about all these shiny, new "reinventing the wheel" tools. A tool that is not a decade old in many cases simply isn't battle proof. The problems with us "old ones" maybe starts if we make this a rule rather than a principle of caution, though...

Re: The Ultimate Frontend Build tool: make

#67
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,…

That's because, I may presume, you have never (really) used make. For somebody who does, exactly the opposite will be true.

Re: The Ultimate Frontend Build tool: make

#68
post #67
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,…

That's because, I may presume, you have never (really) used make. For somebody who does, exactly the opposite will be true.

No, read his comment carefully.

Grunt comes with a set of existing (and maintained by the grunt authors) plugins for many common tasks that lets you get away with having someone else do all the complex shell-script-custom-language-scripting you need to do with make for the 'complex logic bits'.

Writing those by hand is a terrible and tedious burden in using make.

Re: The Ultimate Frontend Build tool: make

#69

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…

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.

Re: The Ultimate Frontend Build tool: make

#70
post #50

I'm glad to see the resurgence in make's popularity among front-end developers. It really is a great tool for not just building apps, but generating files that depend on other files in a declarative way. I manage my website with just make, pandoc, and rsync; and I manage my various ssh configurations with make and m4 (ssh config doesn't have an include directive!). A while ago I wrote an article to help out some fron…

It's also very handy for anything you write in LaTeX: add figures etc. as dependencies, make targets that run R or gnuplot to produce the figures in the right format, etc.

make is great for a lot of build tasks.

Post reply on HN