

Ask HN: Is anyone doing any significant work with the play framework? - rufugee

Guys,<p>Long time Java and Ruby guy here. Most recently have spent much of my time with Rails, which I really enjoy...most of the time. However, I find it infuriating at times to read through some of the code of the framework itself...the magic(tm) of ruby simply makes it difficult to trace at times. To boot, none, and I mean none (including RubyMine) of the available IDEs do a great job of ruby source navigation. They're at times adequate, but a far cry of the capabilities Java IDEs give you.<p>Four months ago, someone posted a link to playframework.org. I glanced it over, half interested but wary of picking up and learning yet another half-assed attempt at copying Rails to the Java world (I'm looking at you, Grails). However, earlier this week, something made me think of it, and having some spare time, I downloaded it and walked through the tutorial.<p>I am blown away.<p>play! supports just about every feature I can think of that I find so appealing in Rails, but it does so in Java. The code is clean. The project seems mature. The layout of a project is almost identical to a Rails project, so it's very easy for a Rails developer like me to grok. It will generate project files for Eclipse, Netbeans, Textmate and Intellij on command. It will walk your dog and make love to your wife, while finishing up the yard work you've recently neglected. Ok, that might be a stretch, but you get the idea.<p>The only thing I find missing is not really a problem with play! but rather a limitation of Java...I am completely, totally addicted to Ruby's blocks. I love being able to collection.each{|one|} over lists...it just feels right.<p>That said, play!'s clean code and style make Java palatable again, and the speed is fast(!). It's the first time I've been excited about Java development in a long time. I'm really surprised the buzz around it has been rather quiet. I think it's a Java web development game changer.<p>So, sorry about the blathering, but I'm curious...are any other HN'ers using play? If so, what's your experience been so far? Have you run into any limitations that would cause you to steer others away from it? Have you deployed to production yet?<p>Please share your experience or thoughts on play, if you don't mind.<p>Thanks.
======
bigclumsyoaf
I don't have any systems deployed to production yet, but am in the process of
creating an internal app using Play and am liking what I see so far.

There are a few minor problems with the framework being quite immature, and I
don't always think the creators have a clear roadmap of where they are going.
However in a way this is good for me, because the early adopters can help
drive things, but with the core team trying to keep the framework as light as
possible.

Coming from a j2ee type background, running each instance as a standalone
process, not inside an appserver was a little strange at first. But the
process separation has turned out to be a good thing for me, just takes a
little more management. But because things are structured in a REST/share
nothing architecture, the ability to use a proxy with failover configuration
and doing hot deploys via this is nice.

The team are very responsive with help on the google group, and bugs are fixed
very quickly, you just have to be prepared to run with nightly builds to keep
up to date.

One worry I do have is how the team/community will continue to handle if
things do become more popular. I am worried about an influx of new developers
clogging the current direct channel to the developers and feel the community
will have to split into newbies/users/developers to handle things more
efficiently. But they are doing a great job so far so long may it continue.

------
masterbranch
Hi. We use Play! Framework in production since a year ago.

We have two sites, <http://www.masterbranch.com> which is a site to manage
developer CVs and track your open source experience in your CV. The other one
is a network about developers, sysadmins, web designers (this one is in
spanish) <http://es.debugmodeon.com>

We are happy with Play!. It's easy to use, has lots of built-in features and
Play! team is also awesome and their work is exquisite.

Cheers

------
dabeeeenster
We're building an app that will be going into production in the next few
weeks. It's not a huge application, probably around 300 hours of work.

Coming from a framework stack of WebWork/Struts2, Spring and Hibernate, it's a
total breath of fresh air. Everything is there that you ask for, even nice
little helper methods like encrypting strings, resizing images or serving byte
arrays as documents.

We keep expecting to find some big shortcoming that brings about loads of
painful refactoring, but it hasn't happened yet!

The templating engine is simple, clean and gets out of your way. The hot
reloading really does work. The fact that there is NO XML configuration in our
app is blissful and a real wake up call to how absurd Spring and Hibernate
configuration used to be. The error messages are almost always enough to show
you straight away where the problem is.

The only downside is that it completely shuns the entire Servlet API (although
I appreciate that this is where a lot of the simplicity comes from). As a
result you cant leverage any servlet-based components. But maybe that's a good
thing.

I'm seriously impressed. I thought my company was going to have to make a jump
to python or ruby to get such a clean, simple well thought through full-stack
framework, but we dont.

~~~
rufugee
I'm curious...can you describe a servlet-based component that you might want
to reuse? As I've been doing Ruby mostly for the last few years, I'm
struggling to think of an example.

~~~
bigclumsyoaf
I'm not sure what dabeeeenster had in mind, but I know that we previously
integrated third party forums and other modules into our servlet based
applications. You still have the option to run servlet based components on a
subdomain to keep your core Play app clean.

I think because Play is Java, you tend to want to merge it into existing
servlet applications, but you have to realise that it's the same as moving to
an entirely new language. It might be based on the same core language, but its
not really compatible.

Although we were excited about creating something with Play, we had to hold
back several months because there was no way to gradually migrate and
integrate Play into our existing servlets. It only really works when you are
starting a new project. Its not ideal, but as previously said, you have to
treat it as completely separate, not linked to servlets and its as though you
are moving to Ruby etc.

------
agentcurry
I ran across play a couple of months ago and I love it (wrote article on my
initial thoughts back in Feb - <http://www.agentcurry.com/2010/02/15/the-
power-of-play>).

Like a couple other commenters, I come from the J2EE world and always found
the MVC frameworks overkill for most non-enterprise apps (even some enterprise
apps for that matter). I really like all the niceties they have integrated
into Play. It's intuitive, easy to use and you can get something up and
running fast (very fast). To get my feet wet I've created a URL shortener app.
It's a pretty simple app, but has allowed me to explore and familiarize myself
with the features of Play! It's been a great experience using Play! thus far;
I've just started a more "robust" application using Play! and hope it
continues to exceed expectations.

------
BonoboBoner
I am moving from Grails to Play, because i can no longer deal with the half-
assed-ness of Grails. It is so buggy and those issues shine thorugh to my
product. It is hard to break-dance when walking on eggs.

>> The only thing I find missing is not really a problem with play! but rather
a limitation of Java...I am completely, totally addicted to Ruby's blocks. I
love being able to collection.each{|one|} over lists...it just feels right.

Absolutely true and that is why they are working hard on making Scala a first
class citizen with Play. With Scala you basically get a lot of the conciseness
of Ruby but with the static type checking and early error catching that you
get from Java.

------
daveturner
Have you taken a look at another Java-based framework
www.scooterframework.com? All your experiences in Rails can be found there:
ActiveRecord, associations, routes, named sql queries, i18n, ajax, etc. I
particularly like the one-click routes link. I think Scooter's routes which is
based on Rails is much better. Also I like Scooter's ActiveRecord over Play's
JPA. I just cannot tolerate annotations polluting my Java class everywhere.

~~~
alexdj
Scooter is very impressive. I can almost convert my Rails app to Scooter-based
app in Java line by line. ActiveRecord is awesome. I think that is probably
why it took only 260 lines of Java code to write Twitter in Scooter.

~~~
bad_user
Personally I think ActiveRecord is the weak link in Rails (2.x ... I see they
are doing some fixing in 3.0).

Coming from Hibernate and such, it may seem like a breath of fresh air, but
the result of a find ain't lazy, the query language sucks making you drop to
SQL even for sub-selects, and the model definitions look weird ... inferring
the columns from the DB schema is the wrong approach IMHO (they should take a
look at Django sometimes).

~~~
alexdj
Scooter framework allows you to use both ActiveRecord and direct sql queries
which you either embed in code or list in sql.properties file. See
[http://www.scooterframework.com/docs/lovely_features.html#na...](http://www.scooterframework.com/docs/lovely_features.html#namedsql)

Django is a nice framework. But don't you think that listing table columns in
Django model code is a violation of DRY (Don't Repeat Yourself)? Database
already holds meta data. Repeating it in model code is unnecessary.

~~~
bad_user
> _But don't you think that listing table columns in Django model code is a
> violation of DRY (Don't Repeat Yourself)? Database already holds meta data.
> Repeating it in model code is unnecessary._

No, because the columns definitions in Django are complete. You specify their
meaning, not their internal representation. And you can also add your own
types easily.

In ActiveRecord you have to look at the DB schema for, well, the table
definition, and you have to look again at the model's definition for
validation rules or for relationship rules. It may be DRY, but it's not KISS.

And I never have to work with the database schema directly, like writing SQL
for the schema definition (I only drop to the db's console for debugging
purposes, nothing else). A migration utility like South can detect the code-
changes I've made and write the migrations for me.

------
SI1233
It's perfect, I think, unique in Java world.

------
rufugee
Has anyone come to play from Rails (as I have)? Is there anything you miss
from Rails?

------
newobj
never heard of it before. the demo seems to leave itself open to CSRF though.
shrug.

~~~
rufugee
Well, glad you're paying attention, but that's not correct. Play escapes
everything for you by default, just as Rails 3.0 does now
([http://www.playframework.org/documentation/1.0.1/releasenote...](http://www.playframework.org/documentation/1.0.1/releasenotes))

~~~
newobj
Not talking about escaping. I'm talking about the fact that there doesn't
appear to be anything like an authenticity token backing the POST that's used
to create a new item.

~~~
pepite
There is now: [http://groups.google.com/group/play-
framework/browse_thread/...](http://groups.google.com/group/play-
framework/browse_thread/thread/85d1863ca03af24e/c2aa265c99addb3f)

------
mnml_
Playframework is just great..

