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:
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.
Are you saying Java deployment is complex? WAR files have been easiest to hot deploy for at least a decade - that too directly from your IDE with the click of a button. PHP deployment simplicity definitely beats everything - and Ruby will come last :(
No. I'm saying that the infrastructure that comes along with Java is more complicated than what many PHP devs are used to (mod_php under Apache).
It's almost like you're intentionally missing the point just so you can talk about Java infrastructure. I'm not here to throw rocks at Java. I'm a big fan of the TorqueBox project, which brings a lot of the power and flexibility enjoyed by Java devs to Ruby. "Complexity" isn't necessarily a bad word. More options means more complex, but sometimes you need those options.
If you don't want too much infrastructure complexity in Java - go for Tomcat or Jetty - If you want advanced enterprise functionality go for JBOSS or another J2EE server. If you want asynchronous io, go for netty. Javaland is full of options that offer best performance.
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.