Play on Heroku(blog.heroku.com)
blog.heroku.com
Play on Heroku
http://blog.heroku.com/archives/2011/8/29/play/
15 comments
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!
Steve introduces Enterprise Objects Framework (EOF) at about 25 minutes in: http://www.youtube.com/watch?v=j02b8Fuz73A
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/
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/
Play's URL mappings seem very close to Django's (i.e. restful and sensible): http://www.playframework.org/documentation/1.2.3/routes
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!
[1] http://www.playapps.net/
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!
[1] http://www.playapps.net/
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! 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.
Any info on whether the Scala version of Play! (http://scala.playframework.org) works without modification?
Seems to work fine: http://smooth-stream-686.herokuapp.com/
(code at https://github.com/lstoll/heroku-playframework-scala , basically a simple hello world app)
(code at https://github.com/lstoll/heroku-playframework-scala , basically a simple hello world app)
Beautiful!
Many thanks for confirming.
Many thanks for confirming.
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.
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 is the most popular Java framework on dotCloud: http://docs.dotcloud.com/tutorials/java/play
It even has its own module: http://www.playframework.org/modules/dotcloud
It even has its own module: http://www.playframework.org/modules/dotcloud
Play is great. Simple, fast, and easily scalable.
Play and Akka are my new favorite toys when I do Java.
Play and Akka are my new favorite toys when I do Java.
When you say scalable, what do you mean?
My buddy is looking into the framework and has run into some odd perm gen constraints because so much of the framework uses static members, etc.
I haven't talked to him about the details, and I wonder if those go away in production (since you're not reloading).
Basically, I guess I'm asking if you've seen it deployed in a largish installation?
Sujal
My buddy is looking into the framework and has run into some odd perm gen constraints because so much of the framework uses static members, etc.
I haven't talked to him about the details, and I wonder if those go away in production (since you're not reloading).
Basically, I guess I'm asking if you've seen it deployed in a largish installation?
Sujal
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.
It's awesome.
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.
It's awesome.
Play! with Mirah can be a very nice combination.
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.
Could you elaborate on why you 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:
http://www.playframework.org/documentation/1.2.3/routes
As a side note, I implemented a similar (but basic) routing for Rack apps in Ruby:
https://github.com/delano/otto
http://www.playframework.org/documentation/1.2.3/routes
As a side note, I implemented a similar (but basic) routing for Rack apps in Ruby:
https://github.com/delano/otto
Good news! Thanks. Is play-scala compatible with?
According to http://news.ycombinator.com/item?id=2937671 - I think yes.
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
Glad to see this. I am excited to try it out.
[deleted]