Why Guard?

Kieran Mesquita edited this page Dec 30, 2016 · 5 revisions

Here are problems Guard helps avoid (compared to other scripts or tools like inotify-wait):

1. Easier to run, manage and extend/maintain:

  • just generate and edit a Guardfile (once) and run guard
  • nice, readable DSL for setting complex rules
  • in Ruby
  • simple example templates are generated for you
  • well documented, lots of simple examples
  • fantastic community support (just file an issue and see...)
  • built-in support for logging and notification (Growl, etc.)

2. more efficient:

  • allows efficiently talking with servers (connect once on startup, then make a request every change)
  • scans large directories only once on startup
  • no "sleep" code needed - changes can happen either immediately, or they can be "accumulated" and "compressed" (to avoid running the command too frequently)

3. more robust and "correct":

  • properly handled cases when files are changed while the command is running
  • no inotifywait/inotifywatch errors to deal with
  • watches the files directory, so it supports file adding, renames (which is what editors do - they rarely just "modify" a file in place)
  • interactive console to rerun, simulate and debug events
  • Guard itself reloads when you change its configuration
  • a single instance of Guard can handle many directories (instead of running many unmanageable "instances" of inotify_wait scripts running)
  • more than 7 million gem downloads and almost no open issues
  • handles moving whole files and directories

4. more portable:

  • supports multiple platforms (Linux, OSX, BSD, Windows)
  • supports multiple backends (inotify, kqueue, polling)
  • polling for network drives and VM shared dirs (which don't support inotify)
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.