Have you tried Phusion Passenger (http://www.modrails.com/)? It is trivial to install and makes Rails deployment a snap.
Having developed both Java EE applications and Rails applications, Rails to me was much more easier to deploy, without having to deal with installing Tomcat and going through the extensive server configurations.
I usually run Jetty behind nginx and don't generally need to configure Jetty to do anything.
The whole Tomcat and connectors for apache configuration from a few years ago is well and truly behind me.
I think the parent is talking about living in a chmod 777 world. Or maybe he is tired of crazy symlink hacks so that sftp becomes an option. Some appservers put class cache in WEB-INF by default, etc.
Play is seriously, seriously good. We used to build on top of a fairly heavy but powerful stack of Spring, Hibernate and Struts2/Wicket (depending on the app). Although there's a lot of power there there's also a lot of tangled XML and you need to do a fair amount of gymnastics to get through it all. Server restarts are common and painful. Getting exception stacks that run 200 classes deep are IMHO a bad sign.
Play is a total breath of fresh air. REALLY well thought out, clean, simple, fast:
- almost no server restarts needed, - runs very very quickly in production - stateless, so zero downtime deployments are trivial - great community - extendable with modules
Then there are all the little things. Libraries to do things like encryption and image resizing are built in and just work. Everything just works.
I can't recommend it enough. It really does liberate Java from the Enterprise shackles.
I've got to agree that Play is a breath of fresh air. It doesn't hide/automate as much as RoR, which I appreciate. It's really easy to get going with and it's made writing web apps feel quite natural.
Using exceptions for flow management doesn't prevent you from adding more boxes. If you're thinking it can cause performances problems, I have an app in prod; here are some numbers: * With a single box, we can do about 500 req/s for a dynamic page, accessing the database * It appears that the bottleneck is the template engine. If we cache the result (thus serving a "pseudo static" page) the exceptions-based control flow is still there but we serve up to 1000 req/s. (That's more than Apache can do to serve static content on the same machine).
So yes, Play does scale!
Enlive and Fleet are other options and I've briefly explored both at certain points, but I personally just found them both unwieldy and unnatural, with other disadvantages as well. I'm sure they suit the needs of some people but I dismissed them before I got past the minimal learning curve.
The same goes for StringTemplate. It seems really cool and everything, but I just don't want to have to learn (and use half the time) a whole new different syntax just to stick dynamic strings in a page.
PHP just makes it so damn easy that it's hard for me to pass up when it comes to churning out webpages.
You can certainly write web applications in Java. They're harder to deploy than PHP but easier to deploy than Rails, in my experience, depending heavily on how experienced you are at administering systems and how much Java enterprise coffee you want to drink.
Java is a mature language. Libraries exist for almost any task you reasonably want to accomplish. There are skilled Java-speaking programmers in your area. Whatever you doing has almost certainly been done in Java already, and it has probably already been documented extensively. Java is an opinionated language: it is of the opinion that your workflow should resemble IBM's more than it does 37Signals', and if that is true, you and Java will get along nicely together.
There, mandatory praise out of the way. Java is horrifically maladapted to certain classes of problems and certain classes of users. One class of problem is expressively operating on strings to produce other strings. One class of users is anybody with a team size less than ten. Many web startups have a small team which is primarily interested in turning strings into other strings: if this is you, Java is going to fight you every step of the way.
99% of web application development for a certain type of business is turning strings into other strings. Many web development languages/frameworks popular with startups give you very expressive options for churning out certain types of strings quickly and with little cognitive load. For example, in Rails, there is very vanishingly little work in taking a bunch of strings from the blog_posts table and turning them into strings which encode a blog post into HTML. And if you want to add special strings that cause comments to be loaded in an AJAXy fashion, that is quick, too. Want to make sure that the strings the user is commenting with include certain strings which look like email addresses? Add one line to your program, and bam, if someone puts in a bad string they get a red string telling them how to make it a good string. It is all string rainbows and string unicorns. If you fat-finger your one line, it is very possible that large portions of your site will instantly break, but that is OK because if you program like everyone else using Rails programs, your magic guardian angel strings will get your attention before you deploy, and after you fix your typo everything is rainbows and unicorns again.
There are many Java frameworks. They can all operate on strings and produce other strings. However, the experience of actually doing this is maddening: pulling off the above you-give-me-bad-strings-I-give-you-red-strings can be a matter of touching six files or more, often written in painstaking configuration formats. The frameworks assume you are guilty of incompetence and force you to repeatedly prove you are otherwise, the better to prevent idiots like you from taking the site down.
This is a problem for startups because web startups are not about turning strings into other strings: that is just what they do. Web startups are about finding a problem people will pay money to solve. That is where they ideally spend most of their efforts. Sometimes, those explorations require code to be written, and when code gets written it should be quick to write, quick to test, quick to deploy, and quick to rip out when you discover your users don't respond the way you thought they would.
Java as it is practiced in the real world looks at that list of requirements and sees Very Scary Things.