I’ve used the Pow for a quite long time so it become de-facto standard way for running all kind of Rack based applications(Sinatra/Rails/etc) for me.
Perhaps it could be good idea to share my experience now :)
Alternative to hosts with ability to run multiple projects at once is something intuitively comes to the mind and Pow really does it great, but not limited to.
Advantage no.1: Good Bye “rails s” and port 3000
With Pow we can easily spawn any number of applications as simply as requesting it’s URL in the browser, e.g. http://foobar.dev, http://shoppingcart.dev, http://blog.dev, etc. you can even run thouse simultaneously, i.e. no more localhost:3030, localhost:8080, localhost:9090
Advantage no.2: Managing Applications
Pow automatically spawns a worker process for an application the first time it’s accessed, and will keep up to two workers running for each application. Workers are automatically terminated after 15 minutes of inactivity.
Where my favorite is:
Workers are automatically terminated after 15 minutes of inactivity
Any processes can go mad especially in development, you probably faced the problem when ruby process related to rails s starts heating your laptop like a crazy?
Adventage no.3: Access your application from other devices
As per documentation:
Sometimes you need to access your Pow virtual hosts from another computer on your local network — for example, when testing your application on a mobile device or from a Windows or Linux VM.
The .dev domain will only work on your development computer. However, you can use the special .xip.io domain to remotely access your Pow virtual hosts.
Construct your xip.io domain by appending your application’s name to your LAN IP address followed by .xip.io. For example, if your development computer’s LAN IP address is 10.0.1.43, you can visit myapp.dev from another computer on your local network using the URL http://myapp.10.0.1.43.xip.io/
sorry for copy/pasting :)
Adventage no.4: Environment Variables
Pow lets you customize the environment in which worker processes run. Before an application boots, Pow attempts to execute two scripts — first .powrc, then .powenv — in the application’s root. Any environment variables exported from these scripts are passed along to Rack.
Conclusion
Those was most interesting things, IMHO, more details in http://pow.cx/manual.html