| I think the genesis if this problem is due mostly to the fact that programmers from a PHP background are used to not thinking about their server stack. That is changing though. In languages like PHP, it's possible (again, this is becoming less common) to run an ad-hoc PHP application by simply requesting the URL to the file. For example: * Drop myapp.php in to your httpd doc root * Request http://myserver.tld/myapp.php * Great success! Rails doesn't work this way at all, and I don't know of an equivalent in the Ruby ecosystem. There is ERB, but no one runs a bare server that just maps myapp.rb to a URL; e.g., http://myserver.tld/myapp.rb. There's always some sort of router in between. Sinatra is probably the most basic Ruby app framework in common use and it still has a router. There are good reasons for this. In Ruby, everything is an object, so if you're writing good Ruby code, you need a way to map URLs to your objects. Rails is somewhere between Java and mod_php in terms of application infrastructure complexity. The most important distinction is that you have an app server that is separate from your web server, and you have to do, at least, some basic configuration (even with Passenger). Many PHP devs never put any thought in to their server stack. PHP is part of their base Apache install on whatever shared host they're using, and everything "just works". I'm trying really hard not to paint PHP devs in a bad light. All of this arrises from the circumstances you "grow up" in. There are plenty of PHP stacks that distinguish app worker processes from the web server, so please understand I'm not claiming some kind of superiority. To the contrary, the Ruby community recognizes the complexity penalty taken here, and is making efforts to develop easier ways to jump in to Ruby on Rails development. This seems like a good topic for a blog post. I might write something up. |