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).
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).
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?
Can you provide any specific, actual, practical evidence that it is a bad thing to use a dynamically typed language to write a web app? Or is this just a personal prejudice?
Was excited to check out Linkedin using Play but then the reasons highlighted in the article almost let me down.
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).
As per the post Play boasts of:
Rapid iteration, Reactive (only for the server not the client), Open, Supported, Flexible, Java & Scala
Maybe I would consider Java & Scala just for the enterprise community scale but definitely not the only one for functional paradigms or rapid iterations.
Everything else is there in other modern web frameworks in Python, Javascript & even perhaps Ruby.
Probably a new thing for Java but why the choice? Is LinkedIn constrained to use the JVM?
LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't constrained to the JVM - for example, we use node.js for our mobile server - but it has significant advantages and we have years of investment in it.
Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc).
Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.
Not really. I don't see what features Play Framework has that are revolutionary or things that no other framework running on the JVM/Java wasn't able to do before.
"Rapid iteration" is the kind of "feature" that every framework claims to allow. No one advertises they allow "slow iteration".
LinkedIn isn't constrained to the JVM, as they had some apps running on CRuby 1.8 and node.js, but they do heavily favor the JVM. JVM interop DOES help with much of their existing codebase which is Java heavy.
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.
I'm actually using Play 2.0.x for my first independent venture, which I posted a Show HN about a few hours ago:
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.
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?
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:
- controller methods are static
- DB access using the framework seems to involve calling play.db.DB.getDatasource()
- Play's Cache API involves calling Cache.get(), Cache.set()
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?
Play actually has a really nice plugin system, which we used extensively to integrate Play at LinkedIn. The plugin system offers lightweight support for DI. For example, to use a FooPlugin, you don't use it directly, but ask Play for an instance of it:
What instance you get depends on configuration (typically, a play.plugins file), which makes it easy to swap out implementations at test time. Much of Play's built-in functionality is implemented as a plugin too, including the DB code, so writing unit tests is pretty simple. There is strong support for "fake applications", integration tests, etc: http://www.playframework.com/documentation/2.1.0/ScalaTest
For Play! components, they don't hole you into one DI framework or another. Instead, you can use your favorite DI framework (or with Scala, the cake pattern) on top of any Play API calls.
If you are asking how do you do DI with Play in java, I can't answer your question. If on the other hand you are asking for how to do it in scala, it is quite easy.
Scala's language support for traits, implicit conversions, implicit parameters etc. make dependency injection trivial. Once you get used to it, things like test mocks or IOC containers seem like obvious language smells.
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
- 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.
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.
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
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?
Play is an open source project that has been around for a few years. In fact, that's one of the big selling points for us: we're not inventing something new, but using something the community is using, and contributing back to it.
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.
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.
[+] [-] alpb|13 years ago|reply
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).
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?
[+] [-] taeric|13 years ago|reply
[+] [-] SourPatch|13 years ago|reply
[+] [-] johnx123-up|13 years ago|reply
[+] [-] slurgfest|13 years ago|reply
[+] [-] ratpik|13 years ago|reply
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).
As per the post Play boasts of:
Rapid iteration, Reactive (only for the server not the client), Open, Supported, Flexible, Java & Scala
Maybe I would consider Java & Scala just for the enterprise community scale but definitely not the only one for functional paradigms or rapid iterations.
Everything else is there in other modern web frameworks in Python, Javascript & even perhaps Ruby.
Probably a new thing for Java but why the choice? Is LinkedIn constrained to use the JVM?
[+] [-] brikis98|13 years ago|reply
Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc).
Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.
[+] [-] brown9-2|13 years ago|reply
Not really. I don't see what features Play Framework has that are revolutionary or things that no other framework running on the JVM/Java wasn't able to do before.
"Rapid iteration" is the kind of "feature" that every framework claims to allow. No one advertises they allow "slow iteration".
[+] [-] dxbydt|13 years ago|reply
I am sorry, what ?
[+] [-] ikailan|13 years ago|reply
[+] [-] j-m-o|13 years ago|reply
I'm actually using Play 2.0.x for my first independent venture, which I posted a Show HN about a few hours ago:
http://news.ycombinator.com/item?id=5258059
http://www.tryringo.com
[+] [-] hendershot|13 years ago|reply
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?
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)
[+] [-] SourPatch|13 years ago|reply
[+] [-] brown9-2|13 years ago|reply
- controller methods are static
- DB access using the framework seems to involve calling play.db.DB.getDatasource()
- Play's Cache API involves calling Cache.get(), Cache.set()
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?
[+] [-] brikis98|13 years ago|reply
FooPlugin foo = Play.current.plugin(FooPlugin.class); foo.doSomething();
What instance you get depends on configuration (typically, a play.plugins file), which makes it easy to swap out implementations at test time. Much of Play's built-in functionality is implemented as a plugin too, including the DB code, so writing unit tests is pretty simple. There is strong support for "fake applications", integration tests, etc: http://www.playframework.com/documentation/2.1.0/ScalaTest
We'll blog more about Play plugins in the future.
[+] [-] atto|13 years ago|reply
For Play! components, they don't hole you into one DI framework or another. Instead, you can use your favorite DI framework (or with Scala, the cake pattern) on top of any Play API calls.
[+] [-] kasey_junk|13 years ago|reply
Scala's language support for traits, implicit conversions, implicit parameters etc. make dependency injection trivial. Once you get used to it, things like test mocks or IOC containers seem like obvious language smells.
[+] [-] trailfox|13 years ago|reply
[+] [-] angelohuang|13 years ago|reply
https://github.com/kouphax/play21guice
[+] [-] dwhitney|13 years ago|reply
[+] [-] kirang1989|13 years ago|reply
[+] [-] chaostheory|13 years ago|reply
[+] [-] seivan|13 years ago|reply
[+] [-] cpprototypes|13 years ago|reply
- build json rest backend in whatever (java jaxrs/jersey, nodejs express, etc)
- build UI with html css js
- 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.
I've found that this enforces a clean separation of concerns.
[+] [-] rama_vadakattu|13 years ago|reply
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
now iam looking build my other new applications on frameworks like Ruby on Rails , django leaving play.
[+] [-] DigitalSea|13 years ago|reply
[+] [-] brikis98|13 years ago|reply
[+] [-] saryant|13 years ago|reply
[+] [-] taligent|13 years ago|reply
You know in the time it took you to write that you could have Google'd this information.
[+] [-] izietto|13 years ago|reply
[+] [-] skcin7|13 years ago|reply
[+] [-] michaelahlers|13 years ago|reply
[+] [-] hhandoko|13 years ago|reply
Play for Java : http://www.manning.com/leroux/ Play for Scala: http://www.manning.com/hilton/
[+] [-] Apocryphon|13 years ago|reply
[+] [-] shellac|13 years ago|reply
[+] [-] tucaz|13 years ago|reply
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?
[+] [-] rvkennedy|13 years ago|reply
[+] [-] i386|13 years ago|reply
[+] [-] chadrs|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] untog|13 years ago|reply
[+] [-] pplante|13 years ago|reply
[+] [-] ikailan|13 years ago|reply
[+] [-] angelohuang|13 years ago|reply
[+] [-] hhandoko|13 years ago|reply