The issue with these systems is that they lie in between something like Python's SimpleHTTPServer and a complete frontend development tool like Grunt or Gulp. They're great for small projects, but have trouble scaling up.
Devd has a simple job: it just serves files and triggers livereload when files change, and is completely agnostic about the build process. That means it works very well as a complement to Gulp - in fact, this is one of my primary use cases for devd. My gulp setups are simpler now: I've ditched Connect and node livereload libraries, and instead gulp JUST renders files to disk. It's early days, but having two sharp tools each doing what they do best seems to work well.
I should add that I definitely don't think there's one "right way" to do this stuff. I love the fact that we're free to explore variations to see what works and what doesn't. The more things we try the merrier!
It serves files and does livereload as well. Can be used programatically or as a CLI: `reloadify -f static -p 8080`.
For instance, here's a devd command-line from the docs (https://github.com/cortesi/devd) that handles proxying local services, with a static directory overlaid. Gulp would be rendering assets into that static directory, the change would be noticed by devd, and liverload would be triggered.
devd -l \
-w ./src/ \
/=http://localhost:8888 \
/api/=http://localhost:8889 \
/static/=./assetsThe live-reload functionality is there as a development workflow tool, to automatically reload the page to see the results of the latest code change, rather than manually switching to the browser and hitting ⌘R/F5.
I'm pretty sure it's intended for quickly spinning up small projects, not fully-fleshed front end systems with package management, build tools etc.
I use node-static myself for quickly bootstrapping experimental front end projects
With devd, I like how you can quickly map a proxy and get live reloading out of the box.
Tidy.