I will be saying this until I die, but WebObjects, originally created in Objective-C and then ported to Java, made Java web app development fun back in the days (late '90s early '00s) when people were killing themselves with Struts, Servlets, and J2EE. Even in its current, unsupported form, WebObjects runs circles around most web frameworks. Given that WO is not supported by Apple, I am really glad to see frameworks like Grails (awesome framework) and Play! gaining traction in the mainstream! So, yes, Java web app development should not be hard, doesn't have to be hard, and, actually, was never really hard at all (if you used the right framework in the first place).
The WebObjects sites I've encountered in the wild all seem to have completely garbage URLs - is that a requirement of WebObjects, part of the culture surrounding it or just an unfortunate coincidence?
Unfortunate coincidence. WebObjects was created a good decade before your average programmer thought of REST being related to the web and not a nap. Similarly, template generation in WebObjects relied on layout tables, because it was created in a time before CSS. Ultimately, this is what did it in, but Enterprise Objects...oh, man! I still haven't met an ORM as capable or well designed as Enterprise Objects!
EOF was one of the key components of making NeXT such a powerful OS, and why it was so heavily used on Wall Street. When they created WebObjects, they, of course, put EOF behind it, and yes, it is by far the most impressive ORM I have ever used. Thankfully, a well known WO developer, Andrus Adamchik, has developed Cayanne using the same principals behind EOF: http://cayenne.apache.org/
I have used Play! on a few projects (my experience coming from the last 10 years of JSP/EJB, JSPX/EJB3/JPA, Struts, Spring, JSF, attempted suicide, etc.) and really enjoyed it.
It does a lot of magic and doesn't follow normal Java patterns, but you can look under the covers and the different programming style it uses is easy to grok.
If you are a Java dev that is sick of the architect-itus that Java developers typically suffer from, Play will feel great to you.
If you are coming from Spring MVC, JSF, Struts2 and any other large-scale framework with a lot of configuration and complex concepts, you will appreciate Play quite a bit more.
You can tell the creators are Java devs that played in the Rails arena for a while and brought a lot of that back to the Java world.
The mailing list is also quite active and releases are very methodical.
Play also works on Google App Engine, (obviously) AWS Elastic Beanstalk, Zenexity's own Playapps cloud hosting[1] and now Heroku... nice to see innovation!
Good to see they started from scratch instead of trying to simplify another heavier framework. It's a desperately needed reboot of Java web app development, very refreshing.
The no-compromise "fix-the-bug-and-hit-reload-devlopment"-culture that Play enables has changed the way I work. I cannot go back to the old style of developing Java web apps. To hell with unnecessary self-imposed complexity.
Awesome! For some types of applications, relying on PAAS for scaling out, logging, etc. is easier than dealing with containers like Java EE 6, etc.
Play! is great. I have used it on my own projects and easily running on Heroku is a nice bonus.
I am not an entrepreneur, instead spending most of my work time consulting (and writing) and I generally go with what customers want but I have been disappointed a few times when I could not convince customers to use a PAAS like Heroku or AppEngine in cases where it probably made the most sense to outsource platform, admin, etc.
Play! applications are meant to be deployed, not packaged and distributed. This allows developers to throw away deeply nested Java package structures, control flow in XML, forget about packaging WAR files, and instead structure projects for optimal clarity and developer productivity.
Can anyone explain what this means in practical terms? Particularly the "meant to be deployed, not packaged and distributed" part.
Play! Framework does away with the Java EE convention of packaging application artifacts as a single file, for easy distribution, in compressed archive formats (WAR/EAR) for ease of distribution(Although you can still 'war' the artifacts and deploy it on some other EE servers like Glassfish). Play! ,in a manner similar to Django or Rails, creates a folder hierarchy as the skeleton for the application ,which can easily be added as a new project in an IDE, and Play!'s server(Play! ships with an inbuilt server) recognizes the same hierarchy for deployment. This takes a sometimes time-consuming step ( that of building the war/ear using something like Ant) out of the equation; usually shortening the development time;but on the other hand complicating the distribution part.
I'd imagine they mean the heroku style of tight coupling between the app and its environment, rather than the WAR file style of generating a package that can be deployed by somebody with no knowledge of its inner workings.
Play uses a shared nothing architecture. That means that you can run a number of app servers and any one of them can receive any request and deal with it. Basically there is no server-based session state. The web server it uses is asynchronous too.
I've been running a fairly busy application for a couple of years with Play and have yet to encounter any of the standard JVM nightmares you get with Tomcat, e.g. Permgen space etc.
Play is awesome. I'd been out of the Java biz for a couple years but I did a bit of work for a friend recently and took the opportunity to give Play a try. I prefer it over Rails.
I found Play easier to grok, it runs out of the box (and didn't require a bunch of dependencies that fubar'd my Ruby), and I really like how routes are defined in a text file:
play kicks serious ass -- if I were to write any webapp in java/scala I'd most definitely use play -- see that they've been coming along a lot in the past year
