

Play Framework 2.0 Beta & integration into Typesafe Stack - lapusta
https://groups.google.com/forum/#!topic/play-framework/bVeD4o77aTE

======
mahmud
We use Play at work. It's the only reason I use an Algol dialect after 10
years of writing Lisps. It and Android, to be frank.

I believe we have one of the largest Play code bases. And I still enjoy it.

I picked it out of a line up, I tested Django, Rails, Cake, Java EE and buncha
other stuff. I had just a month to pick a platform and budget limits for 4
staff and 2 years. So far I only needed just a gfx designer and I still do all
coding myself.

Ask me anything about Play.

~~~
ireadzalot
How much xml based configuration is used in Play? I am currently using Spring
and slowly all the xml configs are starting to haunt me.

~~~
lpolovets
I've used Play! for work and personal projects, and I've never had to deal
with XML. Play uses .properties files for simple things (actually, there's
just one main .properties file), YML for more complex data (like a list of
fixtures to load for unit testing), and "convention" for pretty much
everything else (that is, you don't have to write any configuration if you put
things in the places where Play expects them)

------
BonoboBoner
Play's simplicity and its favouring of 'getting-shit-done'-attitude over the
'layering-and-overarchitecting'-attitude in the Java community has greatly
benefited its rise. I really hope this type-safe Scala reimplementation of the
framework pays off and is not a step backwards.

~~~
erwanl
We're still in line with our "no useless boilerplate" approach in Play 2.0.
You can look at the samples and make up your own mind about whether we've been
successful or not:

<https://github.com/playframework/Play20/tree/master/samples>

------
robfig
We use Play heavily at work (eg. 50k SLOC). I love it.

However, I'm pretty nervous about 2.0, due to the tight coupling with Scala. I
still have a bad taste in my mouth from trying to use Lift, and I did not care
for sbt at all.

While typesafe templates seem like a good thing, I can't recall ever having
bugs that would have been caught by them, and it looks like it will eliminate
the magical boilerplate-free parameter passing from the current version of
Play.

~~~
SkyMarshal
What turned you off of Lift?

~~~
robfig
In two full days of effort, I couldn't get a simple set of pages done. I found
Play! right after that, and finished the pages completely painlessly in
roughly no time.

I would chalk it up to terrible terrible documentation, and being unable to
read the example code that I did find due to the Scala practice of using
random characters as method names. e.g. something = x % y %% z ||| a

The documentation was really the worst, though. Maybe it's improved in the
last year.

------
gambo
Wow these are really great news. Already used Play 1.2.3 and this was already
amazing easy to work with. Working now with grails 1.3.7 and I definitely will
change to Play after finishing my current project. Grails is a pain and it
doesnt feel very light as its built uppon the spring stack which is huge.
Using plugins is sometimes risky as they are outdated and you dont really
understand what they are doing in the background. I also like the type safe
approach of Scala/Java which you dont have in grails(groovy/java). This is
also very useful for code completion in IDEs

------
jiggy2011
Play framework is a breath of fresh air compared to other Java frameworks. The
only disadvantage I can see is that allot of the features to make things
simpler do seem to more tightly couple you to it.

~~~
mosburger
I think the overarching fear of tight coupling is what drove enterprise Java
to the brink of madness. I blame people who got screwed by frameworks like EJB
(pre-3) and Struts (pre-2.0). After the frustration of being "stuck" with
these architectural decisions, the community did a 180 and went to excessively
loose coupling and fear of inheritance.

Now the complexity of frameworks like Spring and Hibernate drive people away
from Java because setting up a simple website is such a chore. It seems like
libraries like Play and Stripes aim for the middle ground that makes web
platforms like Rails and Django so popular.

Admittedly, they serve different audiences. It seems like frameworks like Play
are better aimed at simple public websites and not "enterprise web services"
or whatnot. And that's fine.

</pointless-rambling>

~~~
jiggy2011
Play framework uses hibernate + JPA under the hood (although you may be able
to switch it for something else) but provides so much candy around it that it
feels like using Doctrine or something.

This isn't a bad thing as hibernate is an extremely powerful and complete ORM
which I trust allot more than any of the half baked ones.

If you want to use hibernate properly I recommend reading "Java Persistence
with Hibernate" It explains the framework very well including the logic behind
allot of the things that feel strange or over engineered with it.

------
mark_l_watson
I just spent 20 minutes reading through the documentation and the changes look
very good! I sometimes use Play for my own projects and I was very
disappointed to not have been able to talk my largest customer into using Play
when we kicked off two new projects 5 months ago. Oh well.

Play makes Java (or Scala) web development a light and fun experience.

------
yalestar
I dinked around with Play a while ago and was impressed all around. However,
am I the only one who thinks it would benefit immensely from a better name?
"Play" just makes it sound so... unrobust. It needs a name that conveys that
it's industrial-strength. How about Chupacabra or Lugwrench or Nailgun or ...

------
eegilbert
Bravo on launching day one with serious documentation.

------
deutronium
Will existing Play 1.x apps work on Play 2.0?

~~~
Egregore
It seems no, but authors said that current 1.2.* version of play will be in
maintenance mode for a long time, so it's safe to develop with 1.2. _

