We're using Play pretty heavily at our startup though not for our customer-facing frontend, that's still in Rails.
What we love about Play:
* Async everything, especially the web service library
* JSON macros
* Scala-based templates
* Integration with Akka
* Support for server-sent events (we use this for cluster monitoring)
What we wish was better:
* JSON deserialization performance isn't as good as raw Jackson yet. (Our PR regarding this is actually in 2.2, should be better now)
* Documentation could be much better, we still have to resort to the API to figure out a lot of stuff
I've been using Play ever since the 2.0-RC days and it's definitely made some huge gains since then. We use Akka very heavily, especially its clustering, and Play works well in conjunction with that though there are still some gotchas lurking about.
Our backend is one big Akka cluster right now. We've had a few hiccups but overall it's been a hugely enjoyable experience.
Fully agreed on a most of this; when Play does something well, it does something really well. I personally just wish the build system wasn't such a mess and so antithetical to good development practices--it's extremely hard to have something like a shared domain library among multiple projects (with hot reloading, i.e. if you need to iterate on it while you develop) without making a fake Play project with a conf directory and all of that. It feels built for independent systems/applications rather than ones that play (ha) nicely with each other.
(Also, using the Flyway module has made life a lot easier. play-evolutions is a bit wonky.)
Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o...
If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects.
My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala
Those two facts make sbt a big hurdle in adoption I noticed.
Believe me, I've spent enough time with Play to know exactly how the build system does its thing with external dependencies.
The problem I'm referring to is that, for a long time at least (I know pre-2.1, maybe 2.1 as well), there was no way to aggregate non-Play projects--that is, ones that didn't have a conf directory and did have their own pom.xml or whatever--and use the recompiler. So if you were trying to build your project using an external Java/Scala domain object library that could be shared between projects and wanted it to hot-recompile while you're working (because I at least don't write every model class before I get going) you were in for a world of hurt.
I must be misunderstanding the question. Aggregation of non-PLAY sbt projects has worked from day one of Play 2.0 AFAIK. (That's when I started using both, and we've had sbt projects as bit submodules compiled as dependencies from the start).
Yeah, maybe we're talking about different things; I may be using the wrong sbt terminology because I generally try to avoid it. =) Here's the original bug where some WTFs were exchanged:
Ben's patch made the workaround less terrible for 2.1, but it's still a really weird hacky thing to me and I never got it working with my Maven projects (my preferred backend uses Dropwizard so using a sbt project wasn't really optimal at the time).
This ticket is (justifiably IMO) marked as invalid. It's not a bug, misfeature or anything. It looks like a misunderstanding honestly.
If you approach it with a "Play first" mindset and ignore that any of the Play build-cycle stuff only works because it's built on SBT it's going to be rough going.
An "SBT first" mindset makes it much easier.
Create three console apps in three different folders. Doesn't matter where on your system these live.
Now create a fourth directory, add a project sub-folder and a `Build.scala`. Aggregate the projects together and make Project-C a dependency of Projects A and B. A and B are otherwise completely unrelated.
Now when you drop into the SBT console you can run test, compile, etc. All your standard aggregation tasks. If you wanted to actually run A or B, you can run the `run` task and it'll ask you what main-class to execute.
Here's the only real difference as far as Play is concerned: It doesn't use the standard SBT `run` task. So to get the `run` task from the Play plugin you first need to select your Play sub-project: `project my-play-project`. Now you can run `run` and it'll work like a normal Play application.
I think that extra step is actually resolved in Play 2.2 (it uses the standard `run` task now I've heard).
In this setup your "root project" isn't your Play app. It's a code-less project just defining the build and dependencies between your projects. You could add your common project to the Play app's Build.scala, and use `file()` in the Project declaration for it. The project can live anywhere. It's not at all necessary it be in a sub-path, use symlinks, anything like that.
In SBT 0.13 it's even better since you can do almost everything in .sbt files, which unlike a Build.scala can be built up across several projects. So Play-App-A can read the build.sbt from ../common/build.sbt and use that. Where a Build.scala has to be all-encompasing, so your common project configuration would have to reside in my-play-project-a/project/Build.scala.
SBT really is very nice. :-) I've used Maven, Bundler, Buildr, etc. Written my own JRuby Maven+Rubygems build tool (http://github.com/sam/doubleshot). The docs for SBT are real heavy, but if you set aside a few hours to watch some presentations on Parleys, Youtube, etc, it's pretty easy to get into.
Feel free to ping me if you're interested and could use a hand.
This is true, although I'd replace "multiple projects" with "multiple applications" as you can most definitely create highly modular applications using SBT sub projects.
The dirty *nix hack for this is to symlink the shared library; otherwise, converting the lib to a plugin is one way toward creating reusable cross-application libraries.
What I never understood is why they embrace rendering templates at the server. Is it simply a matter of "because we can and it's nice for the people that want to use it", or is there a real real reason why pushing raw HTML via AJAX request is better?
I always thought the status quo in the web development world was to use a framework like Backbone.JS to communicate with your backend and use a client-side template engine to render the templates.
We push HTML through AJAX to keep all of our templating centralized and consistent.
For a while we used templates for the container page, and then backbone and js templating for certain elements on the page. It can become the 2013 equivalent of spaghetti code if you're not careful.
Now, with HTML via AJAX, you have a clear separation of concerns. For example: the designer doesn't need a dev to make an HTML change, and the dev knows that there will be one place that controls how pages are rendered.
Definitely not status quo. One big example is when Twitter moved away from that back to server side rendering for performance reasons [1].
There are basically three aspects of website performance - server performance, network performance, and client performance. You can control server performance and network latency (CDN), but you can't control what's going on on your users computers.
For example, if they're tab-abusers (guilty as charged) with 50+ non-trivial tabs open, plus other apps open and stuff running in the background, then your beautiful high-performance UI could start chugging (as many do on my abused laptop).
So you really have to think about what your main userbase will be and whether you need to put the rendering chunk of your app's CPU usage on your own servers or on your client's desktops/laptops/tablets/phones.
If you have an application that doesn't need to be indexed by search engines, yes. If you have a content heavy website the preferable method is still to render templates on the server. It still varies depending on your use case. I wouldn't say that is the status quo at all.
We use the templates to render email messages on the server primarily.
Note that Play doesn't force you to use the templates, you can plug in your own very easily or forgo them entirely and just push JSON out for client-side rendering.
We use that for monitoring our backend Akka cluster: Play streams JSON using server-sent events to the client for rendering Mustache.js templates.
I don't know the exact motivation for including compiled templates (we love them) but in practice Play is perfectly happy either way.
It's optional; nothing forces you to use them vs doing the AJAX du jour.
Play templates are particularly speedy though, they get compiled into JVM bytecode. I actually prefer doing things that way and keeping markup and JS to a minimum. It 'feels' faster and more robust to me.
Also using Play at a start-up, but as a customer-facing web app. It's great for productivity - getting both compile- and runtime errors in the browser kind of means that you have the advantages of Scala/statically-typed languages combined with those of dynamically typed languages. If you're ready to go fully stateless and (mostly) asynchronous/non-blocking, this is the framework for you.
I agree that documentation is still lackluster. I would add that although I love the Scala templates, the support for html forms in Scala is a bit clunky. Also there are still a few too many changes requiring code refactoring on minor releases, but I accept those as a byproduct of quick iterations/improvements.
Play 2.0 comes with Netty[1] built into it for making asynchronous requests, websockets and REST easier to handle. Netty is what replaces Tomcat unless you choose to use a third party plugin that builds your Play 2.0 website as a WAR file. Also, with Netty, it builds the entire site into a self contained module that you can run with one click anywhere you have the JVM installed (and the dependencies such as the DB if not using the built in H2). I found it useful for quick presentations or portability.
Play is a web development framework. It has the capability to run standalone using it's built in http server or it can output a .WAR file that can be run under containers like Tomcat.
and play 2.1+ can serve https as well http://www.playframework.com/documentation/2.2.x/Configuring.... In practice, play instances are behind a front end server such as nginx for load balancing, https, caching, and virtual hosting. Play's convention for stateless sessions makes it really attractive to scale by adding more instances to the node balancer.
No, it's mostly replacement for the spring-web/struts/jersey/etc. layer (though it also has its own templating layer to replace JSP or whaever). You can run it under tomcat if you want to.
Why use a Rails / Play hybrid? I can understand separating the front- and back-ends, but why not stick to one platform through and through? Momentum? Expertise? Marketing?
The founders wrote the frontend in Rails before I came on board but it does very little work. Really it just handles authentication and captures OAuth tokens.
I imagine we'll move it to Play eventually but right now we're focused on the backend (Play/Akka) because that's where everything really happens.
For those that have some experience using Play with both Java and Scala, which Play variant do you enjoy working with the most? It sounds like there are some API difference between the Java and Scala versions and I'm curious whether those differences are a factor in deciding whether to go Java or Scala with Play. I'm a long time Java developer, envious of Ruby, interested in Scala for its potential in being a hybrid of the two.
With Play 2.0 in Java, there's more verbosity (though nothing like any J2EE framework) in using Java and lack of syntactical sugar features as well as functional programming features (which are widely used in parts like JSON for Play). Also, you don't get the benefits of such things as optional parameters in Java.
Don't get me wrong, the Java version of it is going to be better than any other Java web framework you ever encountered most likely (especially if everything else one tried was based in part on J2EE/JSP since Play has none of those and no XML bs config). However, you do lose some of the Scala niceties when going that route. You still can still call to Scala bits of the API in Java and templates themselves are all Scala (Lift templates), but it's still not quite the same.
If using something like Intellij, you can still mix and match bits of Scala and Java in the same project (but not within the same class file) without too much trouble. Not sure how the official Scala IDE that TypeSafe maintains handles that offhand.
I agree with the above. As a Java and Scala programmer I've tried both and Play! 2 Scala is a joy to use if you're fond of idiomatic Scala and functional programmming.
I use Eclipse with the Scala IDE plugin and although I write all of my code in Scala, I do have a couple of dependencies to Java libraries (the interop works perfectly, but of course you should be careful when mixing immutable code with potential sources of mutability). The Intellij plugin is probably still the more stable of the two, but as mentioned by yareally the Scala IDE is the officially maintained one so you can expect new features to come to Eclipse before Intellij.
Excellent summary. A lot of the API's are definitely built scala-first, then adapted for Java. Usually this isn't too bad, but it can cause some headaches around things like the logger interfaces, etc.
We run a fairly complex java system in the same process as play (similar to an in-process database) for performance reasons, so given the amount of code already in java and not having the time to learn scala, java interop, AND build in the web bindings, we went the Java route.
It's definitely easier to use than something like Spring if you're approaching both for the first time.
It's not that it's "Scala adapted to Java", but more like a choice to do async and functional programming even in Java. That makes stuff a bit verbose sometimes because to pass a function you have to pass an anonymous class.
That will become better with Java 8 and lambdas without having to break compatibility with older Java versions (they will still use anonymous classes).
> Don't get me wrong, the Java version of it is going to be better than any other Java web framework you ever encountered most likely (especially if everything else one tried was based in part on J2EE/JSP since Play has none of those and no XML bs config).
It doesn't sound like you're really familiar with other Java frameworks. While I'm not really a fan of it, Ninja (as just one example) has none of that, and also doesn't have the torture chamber that is Play's (non-standard, custom, even more undocumented) flavor of sbt--easily the worst not-Maven Maven tool I have had the displeasure of working with.
I want to like Play because I love a ton of what they do, but just having to deal with sbt and the non-standard, doesn't-play-nice build system that they enforce has driven me away from it.
Never used Jersey so cannot comment on ease of use at the code level. It may be similar, but it'll likely not have other nice features that Play has that sets it apart from other Java Frameworks.
I was comparing against any Java Framework that depends on J2EE and JSP though as that comes with an excessive amount of baggage that's really hard to get rid of totally (like excessive use of XML tooling/configuration). If one's reason for never touching Java on the web is because of the XML nightmare it generally brings, then Play is the framework one has been searching for. There's no use of XML anywhere that is required and templating/views are similar to what one would do in any scripting language since they're really Scala (Lift) templates and not kludgy JSP that reminds me of ColdFusion.
Also, being built on Scala shapes Play 2.0 in ways that other Java Frameworks are not by design, since Scala is generally against excessive verbosity and it's a Java habit that dies hard for some even when trying to avoid it.
I'll admit I'm biased against excessive XML tooling and configuration, since I come from a PHP & Python background in web development, but I dislike all that boilerplate. I realize it's sort of a common part of almost everything Java, but it's also why I stay away from Java on the web as much as possible.
Edit: Jersey does make use of JSP[1] (Java Server Pages). Some may not find that to be bad thing if they're used to it from prior experience, but I would avoid it personally. If coming from a dynamic programming background on the web (Node.js, PHP, Python, Ruby, etc), JSP is not a fun time.
Jersey is really easy to use as strictly a REST backend. I fully grant that Java is, in general, more verbose than Scala. Just curious if you were comparing this based solely on past experiences. (That is, when making a "service" with Jersey, there is surprisingly little boilerplate. There is the verbosity of Java, but pretty much none of the other.)
And, really, it mainly depends on how you want to structure your application. At face value, an angularjs/whatever frontend that calls to whatever REST implementation you can bring to works quite well.
Regarding JSP, yeah, planning on avoiding that as much as possible, though, for a quick "put a dummy string into a page," I can't say it is that terrible. (I fully grant that is a very slippery slope.
No problem. I was stuck to mostly using the Java side of it for a project that Java was the requirement. It was a university requirement, as I could not convince my group into experimenting with Scala for the entire project. They were mostly worried they would not learn it fast enough to have us finish the project on time and I agreed, since it was a valid concern.
I was worried how it would fair after trying Play 2.0 in Scala previously for my own work. However, it was not anywhere as bad as I thought, but I was a bit envious of not being able to use some of the features of the Scala side I had used previously.
It doesn't say so explicitly in the course description, but I guess we will be using Play and Akka during assignments. If it's half as good as his introduction to Functional Programming in Scala, it will be a treat.
Scala no doubt for its expressiveness power. Extractor, case class/object, pattern matching, first class function, curry function, partially applied functions, implicit, trait and more are so powerful. Use them with caution or you will hate Scala. Rofl!
Play is an interesting option if 1. you need async request handling (most people don't), 2. are comfortable with Scala, and 3. don't mind maintaining your own branch of the framework (or can pay for commercial support).
Otherwise there are better options, given the hard to configure and slow build process, bloated artifacts, infrequent releases, missing features (in the Java version) and incomplete/outdated documentation.
What we love about Play:
* Async everything, especially the web service library
* JSON macros
* Scala-based templates
* Integration with Akka
* Support for server-sent events (we use this for cluster monitoring)
What we wish was better:
* JSON deserialization performance isn't as good as raw Jackson yet. (Our PR regarding this is actually in 2.2, should be better now)
* Documentation could be much better, we still have to resort to the API to figure out a lot of stuff
I've been using Play ever since the 2.0-RC days and it's definitely made some huge gains since then. We use Akka very heavily, especially its clustering, and Play works well in conjunction with that though there are still some gotchas lurking about.
Our backend is one big Akka cluster right now. We've had a few hiccups but overall it's been a hugely enjoyable experience.