I used Play! for more than one and half a year and I must say I have mixed feelings about Play! now. Before 3 or 4 years ago, your chances with getting a web application easily in JVM languages was using J2EE ecosystem or Spring framework. But now there are plenty of alternatives. When Play! came out, it has done really a good job, it was working just fine, it was magical and it totally nailed it. But then frameworks evolved around languages like Groovy and Clojure and they nailed it as well. Best move Play! made so far was supporting Scala, because all existing Scala web frameworks were crap (yes I'm talking about Lift).<p>I used Play in a startup backend and I won't be able to say I was satisfied with it. Play v2 is especially slower on your local development box, compilation takes some time and I actually still like Play 1.2.x family more. Its memory consumption was horrible on production (I made really a lot jvm adjustments and could not get it properly).<p>Personally, I now like Python frameworks (e.g Flask) and they are much easier, but I am not sure if you should rely your whole service infrastructure or enterprise software on a dynamically typed language stack. There are companies out there achieved this but I think Java or Scala will be just fine for LinkedIn, and by the way why the hack they don't allow comments on their engineering blog?
Was excited to check out Linkedin using Play but then the reasons highlighted in the article almost let me down.<p>I am comparing to Python frameworks and Node and everything mentioned there has been available in the Python stack for a while and now Node (extra points for realtime websockets stuff).<p>As per the post Play boasts of:<p>Rapid iteration, Reactive (only for the server not the client), Open, Supported, Flexible, Java & Scala<p>Maybe I would consider Java & Scala just for the enterprise community scale but definitely not the only one for functional paradigms or rapid iterations.<p>Everything else is there in other modern web frameworks in Python, Javascript & even perhaps Ruby.<p>Probably a new thing for Java but why the choice? Is LinkedIn constrained to use the JVM?
Awesome. I've been using (playing?) with this framework for a bit over a year now and absolutely love it, I'm glad it's catching on as much as it is. The fact that Heroku and the Cedar stack supported has probably helped user adoption a ton.<p>I'm actually using Play 2.0.x for my first independent venture, which I posted a Show HN about a few hours ago:<p><a href="http://news.ycombinator.com/item?id=5258059" rel="nofollow">http://news.ycombinator.com/item?id=5258059</a><p><a href="http://www.tryringo.com" rel="nofollow">http://www.tryringo.com</a>
I like Play, currently using for a personal project. But ultimately looking forward to the day where frameworks are replaced by mixing and matching libraries where you get just what you need and wire it up exactly how you want to without any limitations.<p>On the JVM and especially since version 2.1 Play is one of the most lightweight/modular frameworks. At it's core it's just a fast/async http server. So why can't that just be a library you pull in and fire up in a main method?<p>You can have an IDE or somthing like sbt recompile your changes on the fly so you can get rapid feedback. Ultimately more rapid feedback comes for automated tests vs refreshing your browser and verifying something manually (unless it's UI/lookandfeel changes which are not generally limited by having to compile)
How do you do DI with Play? It seems as if everything is oriented towards writing static methods:<p>- controller methods are static<p>- DB access using the framework seems to involve calling play.db.DB.getDatasource()<p>- Play's Cache API involves calling Cache.get(), Cache.set()<p>Are Play applications easy to write unit tests for? Does it involve reconfiguring the framework to use some sort of stub services rather than the real DB/Cache implementation?
At Pellucid Analytics we're using Play 2.1 with a similar success story to LinkedIn's. The undersold feature IMHO is the asynchronous responses: with the excellent new monadic scala.concurrent.Future interface, you can more easily put together non-blocking web apps with code that looks slick and concise
Does anyone else feel templating is outdated tech? I feel like these days you can just do this:<p>- build json rest backend in whatever (java jaxrs/jersey, nodejs express, etc)<p>- build UI with html css js<p>- If initial page load is an issue due to lots of ajax calls, then use server side templating to ONLY insert a single variable which would contain a json object. This way the initial load is fast since the json is templated directly into the page. After load the UI calls rest services to get more data.<p>I've found that this enforces a clean separation of concerns.
WE have written lot of code in Play 1.2.X all of a sudden they migrated to Play2.0 without any backward compatibility.This is sad.<p>WIth Play2.0 they introduced Scala Many folks has the opinion that Scala is complex, and i also lost trust in play because of no backward compatibility and i stuck up with huge code base which is not backward compatible<p>now iam looking build my other new applications on frameworks like Ruby on Rails , django leaving play.
While I don't doubt Play is useful (I haven't personally tried it just yet) I've noticed big tech companies seem to be wasting their time building new frameworks instead of helping improve already existent frameworks in need of new ideas and fresh eyes. Why a new framework? Is it really not a straightforward process to contribute to an already established open source framework for your desired language?
I've embraced Play! on a few projects, and my experiences have been great. There's no need to expand on existing sentiments, but I will say: this tutorial is excellent. Wish I'd had this when I first got started!
Is it just me, or is Google's Play Store also having a greenish triangle (set at the same exact angle) sort of confusing? I've never heard of the Play Framework, is it related?
Reading people's comments here make me laugh a little bit. ASP.NET MVC been around a few years now and does that and a lot more in a very easy way and in a great platform. I find it really funny how people get commodity software and dress up as the next big thing.<p>It's pretty much the same as when Microsoft announced nuget after ruby gems and apt-get existed for so long. Why don't they just cut the bull out and call it for what it is?
I have to say I've been wondering for a while what happened to LinkedIn - what used to be a great service has lately taken to a great deal of UI misbehaviour and dysfunction - to the extent that I'm now relucant to go near it for fear of its hangs, jumping menus, and repeated reloads. Perhaps this has been teething trouble switching frameworks?
For me, the good thing about Play is the platform support. Play 2.X is fully supported on Heroku which makes developers to hack something out really quickly.
>Rapid iteration: change the code, refresh the page, and see the change instantly.<p>I see the play people tout this all the time, and I assume it is in reaction to an assumption of dynamic language people that you have to manually compile every time you make a change. But it is really misleading. You make a change, refresh the page, and wait 10 seconds for it to compile and reload. Iteration speed was just as poor with play as it was with bloated J2EE monsters on jboss.