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.
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!
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).
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.
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:
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.
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.
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 :)
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.
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.
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.
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.
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.
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 like the features planed, especially the native scala support.