

Introducing Play 2.0 - dabeeeenster
http://www.playframework.org/2.0

======
Egregore
Initially I thought that Play 2.0 was released, and was little disappointed
when found out that it's just an introduction and you can use only preview,
actually they expect to release a usable beta by the end of the year.

I like the features planed, especially the native scala support.

------
glenngillen
Not being a java developer, have to say I loved my experience using it last
week. It was a core part of some demos I was giving and going from no app to a
deployed "hello world" was as easy as I've experienced in any framework,
possibly the easiest!

------
timf
"Having a more complex build system may slightly slow down build performance
at development time"

The instant development feedback loop is one of the great appeals of Play...

------
tommorris
Play is lovely, but the one thing I'm really hoping for is improvements to
make Scala's Option types work out of the box with Hibernate (rather than
having to use nulls).

------
timc3
Looks like its going to be a great release, and I am loving the website. Just
wondering what was the Python support 1.0 and 1.2?

~~~
dabeeeenster
The play scripts (play run, play create etc) were all python powered I think.

~~~
swah
Yes, just because of startup time, IIRC.

------
Uchikoma
What prevented me from using Playframework and going with Lift: 1\. Play 1.0
(2.0 too?) used exceptions for flow control. I don't think this works for high
traffic web sites. 2\. Lift's CSS selector templating is slick, I would not
like to go back to PHP/JSP/... style templating.

Very nice website.

[update: 2.0 has no more exception work flow]

~~~
scompt
Where did you find the reference to no more exception work flow? That seemed
to be everywhere in the framework.

~~~
mrspeaker
From the source code... the controller actions are all returning values:
[https://github.com/playframework/Play20/blob/master/samples/...](https://github.com/playframework/Play20/blob/master/samples/kiki/app/controllers.scala#L64)

------
yalestar
I dinked around with Play last week 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 ...

------
jshen
My biggest problem with jvm web stuff is that it uses so much ram for simple
little web apps. For someone that likes to make small web apps for fun, I
can't fit more than one jvm app on my little vps. Anyone know how to get the
memory down on these things?

~~~
eropple
My answer, and no it's probably not what you want to hear, is one of two
things:

-Get a bigger VPS

-Build bigger applications.

There is a lot of overhead in the JVM (CLR too). It's pretty much unavoidable
in the Java ecosystem. That said, that overhead remains relatively constant
even as you write significantly bigger pieces of software, so after a certain
point it tends to matter a lot less.

~~~
ssmoot
Just to re-inforce this: While the initial memory spike can seem pretty
unreasonable coming from a site with a couple Mongrels or something,
converting to JRuby from a Unicorn site using 16 workers and over 2GB of RAM
is very nice. You end up using a lot less RAM and support a lot more
connections.

~~~
jshen
yeah, it's definitely great once you reach a certain traffic level. I imagine
you either get a ton of traffic, or you're site is very dynamic to require 16
workers. I cache a lot of pages so many requests do not hit the rails stack at
all.

But this is what I love about the ruby world, we get both options :)

------
koevet
One of the main reasons the Play! framework didn't get a lot of traction,
IMHO, was the lack of a proper build tool (Continuous Integration anyone?).
The plan to use SBT as a build tool is a welcome news. Same goes for the Akka
integration.

~~~
scompt
There's a continuous integration server called calimoucho
(<https://github.com/guillaumebort/calimoucho>) written by the author of the
Play framework. I don't have any experience with it though.

------
swah
I've been looking again at Play given this post, and there are so many
modules, examples, documentation and interesting features that is kinda hard
to believe they are going to start again for 2.0.

~~~
alanl
I had just started tinkering with play, with the idea that I might introduce
it for a project at work. But the fact that their going to rebuild 2.0 from
scratch puts me off a bit TBH.

------
jpastika
I honestly don't know much about Play, but I like the website. Nice use of
scroll/navigation. But, whatever you do, DO NOT look at it in IE 8!!! ;-)

~~~
aw3c2
Scrolling eats one cpu core and is super laggy for me (Opera on Linux,
nvidia)...

------
swah
The bad thing about this news is that now I don't want to start an app with
Play 1.2.3 anymore.

------
va_coder
I don't get it.

To me an appealing aspect of Ruby, Python etc is that I can pull up Vim, make
some quick changes and see the results. For _most_ Web apps this is a great
thing.

Why would I move back to a statically typed, compiled, "slow to startup"
runtime?

~~~
ww520
"is that I can pull up Vim, make some quick changes and see the results. For
most Web apps this is a great thing." That's exactly what Play does.

~~~
swah
IIRC, they have adapted one of Eclipse's java compilers just so you could
that.

------
swah
Even Zed Shaw praised this!

------
j_baker
_Don't worry, we don't expect you to migrate your existing applications to
Play 2.0. The Play 1.x versions will continue to be maintained and you don't
need to move to Play 2.0. We ourselves have many Play 1.x web applications
running and we will of course continue to support them_

This sent shivers down my spine. Is it that hard to maintain backwards
compatibility? And you would figure that if they _did_ have to break backwards
compatibility, there would be a clear migration path instead of this "Don't
worry about upgrading. Just continue to use outdated versions of our software
forever." attitude they seem to have. It's almost never a good idea to put
yourself in the position to have to maintain two diverging versions of the
same software if you can avoid it.

~~~
markokocic
It is not hard to maintain backward compatibility, but why be constrained with
it? It is hard to evolve a library or a framework if you have to be always
backward compatible.

I'd rather have big disruptive incompatible major release that kinda
compatible which may or may not break in production in a subtle ways.

