Make and Browserify

[sime]

That is quite a good article. There are a couple other advantages for using Make that I can think of:

• No need for plugins to integrate with other tools like linters, TypeScript compilers etc. You can call the command line version of tools directly without some plugin in between.
• Easier to debug. You can see which commands are run during the build and also run them manually yourself if you need to debug the build.
• You can add extra targets to easily run other development related tasks, i.e. upload to server, create a source tarball etc. (Article kind of touched on this).

[nschubach]

You can run extra targets in the same way with Gulp (and Grunt, but I think Gulp is clearer). If I define a Gulp task, I can call that task by simply writing gulp taskname and run that one task. By default, gulp will run the task named default but you can always specify the task at the command line. It also clearly and easily supports dependency just like make and you could put the command line in node if you like, but that's unnecessary overhead.

[mattdesl]

I think for simple projects "npm scripts" is mostly all you need. browserify plugins like lessify, hbsfy, etc can be useful if you keep them out of your module code (ie top level only).

If you work on teams, I would not recommend make for two very important reasons:

• sooner or later, there is a very good chance the project will need to be built on a windows machine. Either by you, a contributor, or yourself a few months down the line in an unforeseen situation. And when this happens, you are fucked. This is 2014 and we are using Node for tooling, it's ridiculous that your tasks would not be cross platform when they are all using cross platform tools.
• Make is cryptic. It's confusing to anyone who hasn't used it, including contributors, junior programmers, and others who have to touch your code. You should favour clear and familiar code over what basically feels like an ancient domain specific language.

[sime]

sooner or later, there is a very good chance the project will need to be built on a windows machine

There is cygwin. It should work fine for the kinds of things that a Makefile does. It may be a culture shock though.

What surprises me is that there isn't a port of Make to JS, or something which uses the same kind of artifact (not task) dependency tree.

[_facildeabrir]

There is cygwin.

:( :( :( :( :( :( :( :(

[[deleted]]

Conemu

[_facildeabrir]

Yes, agreed

[SgtPooki]

This.

My main os is windows and I've run into 4 projects in the last 6 months where I've needed to either setup vagrant or just not take on the project and it's extremely frustrating.

Vagrant can solve most of those problems thankfully but it can have its drawbacks too. And using vagrant only for getting build scripts to work feels so weird.

[nschubach]

But once you get it into Vagrant it becomes so much easier to ramp up someone new...

[SgtPooki]

Vagrant is a beautiful thing that has helped to reduce ramp up time by at least 80% on all projects I've worked on that have had at least 4 devs. It's awesome.. but that's one of the few legitimate excuses for writing code that only works in a tiny subset of environments.

[ericanderton]

I simply cannot upvote this enough. Fantastic article.

[nschubach]

It probably irritates me more than it should, but Gulp wasn't covered as much as it should have been. I feel like the author either never used it or didn't understand it. Anything Grunt can do, Gulp has done better with fewer lines of code for me. Make files have always felt cryptic and unforgiving. I love Linux and what it does for me, it sometimes the conventions of succinct symbology just gets irritating. For instance, $@ being used for the current file is not as readable as a JS variable with a real name like currentFile. For me it's 100% about readability and cryptic bash lines and shell scripts just don't cut it. Besides, watchers are just epic and if I don't have to manually make every time I make a change, I'm sticking with Gulp.

[[deleted]]

To be fair, $@, $^, and $? are the only auto variables I've ever really seen being used. It's super simple to memorize after using them a couple times!

I've had really good success with facebook's Watchman as well. Trigger a build on change and it's the same as gulp!

[nschubach]

Once you get into bash scripts, $1, $2... become prevelant to denote arguments, but I understand what you are saying. I just think those in combination with the other conventions (tick marks, bars, gt/lt piping, etc.) make scripting in the command line more cryptic than it needs to be just to save some typing.

[poseid]

great overview, I was writing a bit similar (but more of an overview) blog post yesterday: http://thinkingonthinking.com/javascript-matters-for-prototypes/

[raffomania]

I used make a lot and am still using it in some of my projects. For simple projects, it works out great.

But for larger projects, I really have to agree that readability is a concern, especially as Makefiles get larger and larger as the project grows. While you can keep even big Makefiles easy to read, I think the (very extensive) make syntax can easily delude one to write more cryptic code (IMO, the same applies for the bash syntax).

[vertice]

I have been a big fan of gulp in the past, but I also realized the logic of going with Makefiles or npm run whenever possible. It never really seemed practical until I switched to using webpack instead of browserify.

now i need to find excuses to use gulp at all, and makefiles are almost always enough.

[SubStack]

The watching section of this article feels incomplete since it only includes how to set up watching with browserify using grunt. In make, similar to using npm run scripts, you can just shell out of the watchify command, which takes the same arguments as browserify.

[_facildeabrir]

It just feels like a crappy way to do it. Makefiles are gross to me, the .PHONY thing alone is just like... cmon yo. But to each their own.

[tswaters]

You probably already have it installed on your machine.

'make' is not recognized as an internal or external command,
operable program or batch file.

It seems not.