Introducing Play 2.0(playframework.org)
playframework.org
Introducing Play 2.0
http://www.playframework.org/2.0
17 comments
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!
"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...
The instant development feedback loop is one of the great appeals of Play...
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).
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?
The play scripts (play run, play create etc) were all python powered I think.
Yes, just because of startup time, IIRC.
The website is nice with one small but massively important exception. The line height of the text is far too small, it should be around 1.5 times the font size at that size.
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]
Very nice website.
[update: 2.0 has no more exception work flow]
2.0 doesn't use exceptions for flow control - but out of interest, what do you mean "I don't think this works for high traffic web sites"? 1 exception for a request won't affect performance, right?
Although exceptions have become faster, and you can speed them up (overwrite stack generation code), they are slow mostly due to filling the stack trace. Mostly based on this:
http://www.javaspecialists.eu/archive/Issue187.html
http://www.javaspecialists.eu/archive/Issue187.html
That article mentions that the performance is dependent on the fillInStackTrace() method, which play framework overrides to do nothing.
Was not familiar with this method, appreciate the heads up guys. Did some quick micro benchmarks and it looks like I got an 11.5x speedup in some code that was using Exceptions for flow control.
A small nitpick: Lift does (typically) use exceptions for control flow, for redirects.
Where did you find the reference to no more exception work flow? That seemed to be everywhere in the framework.
From the source code... the controller actions are all returning values: https://github.com/playframework/Play20/blob/master/samples/...
'grep -R throw .'
or you could just look at controller code...
or you could just look at controller code...
"Yes no more exception for flow control." via Twitter.
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 ...
"Play" just makes it sound so... unrobust. It needs a name that conveys that it's industrial-strength. How about Chupacabra or Lugwrench or ...
[deleted]
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?
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.
-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.
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.
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 :)
But this is what I love about the ruby world, we get both options :)
I've opted for the third option, use C ruby. I use JRuby at work and love the JVM in that context, I just wish I could use it for my fun side projects :(
PS - using ruby and having both options is pretty awesome.
PS - using ruby and having both options is pretty awesome.
heroku has support for play, though it's not 2.0 yet. a free account might be a good workaround to your vps.
heroku is far more expensive if you have any amount of data, or if you need a background worker. I run 3 rails sites, with background jobs, a search engine (sphinx), etc. All on a $30/month vps, and they run great.
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.
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.
You can do CI with play projects, it just feels wrong if you look at it from a Java perspective as there are no build files like .war files.
You can do it by triggering source code repo updates and then play restarts...
You can do it by triggering source code repo updates and then play restarts...
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.
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.
The bad thing about this news is that now I don't want to start an app with Play 1.2.3 anymore.
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?
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?
In my experience, Rails is much slower to start up than Java frameworks, even if the rvm itself loads faster. Also, Play does allow you to see changes instantly. Read the docs for more information.
As far as static typing goes, that's a larger debate. Many, myself included, believe static typing has many benefits for error prevention, debugging, tooling, etc.
As far as static typing goes, that's a larger debate. Many, myself included, believe static typing has many benefits for error prevention, debugging, tooling, etc.
Even Zed Shaw praised this!
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.
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.
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.
I'd rather have big disruptive incompatible major release that kinda compatible which may or may not break in production in a subtle ways.
Reminds me of Tapestry 3 -> 4 and 4 -> 5. A lot of people made plugins and learnt Tapestry 3 and when 4 came out all of that was for nothing.
Tapestry 5 now is a whole different story, and so far a good one.
Tapestry 5 now is a whole different story, and so far a good one.
I like the features planed, especially the native scala support.