Interestingly enough, I tried using Makefiles for a web project yesterday, and it was a success.

    SOURCES = index.pug layout.pug style.styl main.coffee privacy.md
    OBJECTS = index.html style.css main.js privacy.html

    all: $(OBJECTS)

    watch:
    	http-server &
    	while true; do \
    		$(MAKE); \
    		inotifywait -qq $(SOURCES); \
    	done

    %.html: %.pug
    	pug -P $^

    %.css: %.styl
    	stylus $^

    %.js: %.coffee
    	coffee -c $^

    %.html: %.md
    	markdown $^ > $@

    clean:
    	rm -rfv $(OBJECTS)

This could be extended to produce an out-of-source build by using `-o "$(PUBLIC)"` on the command line generators, but I didn't need it for this project.

Do you know about the ; style for rules that have only one line of commands? It helps reduce the number of tabs.

    %.html: %.pug ; pug -P $^

I find it super useful for compact Makefiles:

    %.html: %.pug    ; pug -P $^
    %.css:  %.styl   ; stylus $^
    %.js:   %.coffee ; coffee -c $^
    %.html: %.md     ; markdown $^ > $@
    clean: ; rm -rfv $(OBJECTS)

Also, worth making clean .PHONY since it's not a file.

Sure, that's the traditional way of doing things, and I like its simplicity and the fact that the 40 years old core concept is still so useful.

But most of us want to require() modules also in the browser, so you'll anyway need browserify or other bundler, which already have cross-platform watch mode & plugin ecosystem, and are expected to be run continously, and suddenly the Makefile feels rather redundant, especially with npm scripting.

I'd recommend adding:

.PHONY: watch .PHONY: clean

In the appropriate places.

The data model of makefiles is perfect for watching and rebuilding. All you need to add is something that monitors the source files for any changes and runs 'make'.

You lose incremental builds of modern bundlers/transpilers, which makes your build time too slow for bigger projects. People nowadays expect to see changes almost in realtime using hot module replacement etc.

That's because those tools aren't designed to play well with others. It's not due to the design of make.

I would say it's partly because of the design of make.

A Makefile consists of separate commands¹ and is heavily file-based¹, which makes it rather slow and doesn't allow to keep state (in memory) between re-runs. Traditionally this hasn't been bottleneck, because compiling C code was relatively slow operation, but modern web development tools prefer to work with in-memory streams instead of invoking executables for tiny files on disk.

I'm not saying you cannot do things with make, but in NodeJS/web ecosystem it just doesn't feel as natural/flexible as the "native" NodeJS-based toolchain.

[1] Great for interoperability, but sometimes more tailored solution is worth it.

Launching a process on Linux only takes about 2ms, and make only needs to do it for parts that change. There is no reason you couldn't use a make-based system to get incremental rebuilds with under 100ms latency, which is about as good as most people get with native JS systems.

For js code you often want hot module reloading which is probably very hard to get with make.

That sounds like a great idea. Does anything like that exist already?

Easy enough (assuming $SRC is your list of source files and 'all' is top level target) 'make watch' could do this

   watch:
        while ! inotifywait -e modify $(SRC) ; do time -p make all; done

If you care for it, fswatch is cross-platform:

https://github.com/emcrisostomo/fswatch

something along the lines of inotify:

http://man7.org/linux/man-pages/man1/inotifywait.1.html

or just use tup

http://gittup.org/tup/

Also, entr

http://entrproject.org

There's "when-changed" in pip.

    pip install when-changed
    when-changed *.tex -c "make all && echo 'done'"

Then you can make rule in your make file called "watch" or "build-server" which calls that command, so you just need to write "make watch".

It's trivial to roll your own: https://github.com/gall0ws/watch