Live data from Hacker News

What’s new in Play 2.2

playframework.com

31–40 of 44 posts

Re: What’s new in Play 2.2

#31
post #13

Earlier quoted context omitted.

When considering the verbosity, are you comparing to the modern frameworks such as Jersey?

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…

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.

Re: What’s new in Play 2.2

#32
post #27
post #4

Earlier quoted context omitted.

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 e…

> 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 d…

You can also run Play projects with vanilla SBT. That's what I usually do. Then you don't have to worry about the unusual stuff that Play does.

Re: What’s new in Play 2.2

#33
post #30
post #28

Earlier quoted context omitted.

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 dire…

You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine. That's how we do it anyways.

Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.

Re: What’s new in Play 2.2

#34
post #2

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.…

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 engi…

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.

[1]: https://blog.twitter.com/2012/improving-performance-twitterc...

- http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-R...

Re: What’s new in Play 2.2

#35
post #27

Earlier quoted context omitted.

> 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 d…

You can also run Play projects with vanilla SBT. That's what I usually do. Then you don't have to worry about the unusual stuff that Play does.

Honestly I'd like to run them with vanilla Maven. There's play2-maven-plugin that's trying to get there and that'd be a great thing, I wish them well.

Re: What’s new in Play 2.2

#36
post #28
post #2

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.…

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 dire…

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.

Re: What’s new in Play 2.2

#37
post #10
post #4

Earlier quoted context omitted.

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 e…

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 inte…

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).

Re: What’s new in Play 2.2

#38
post #33
post #30

Earlier quoted context omitted.

You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine. That's how we do it anyways.

Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.

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.

Re: What’s new in Play 2.2

#39
post #33
post #30

Earlier quoted context omitted.

You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine. That's how we do it anyways.

Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.

btw JS dependencies are available as maven deps now as well. Pretty handy http://www.webjars.org/

Re: What’s new in Play 2.2

#40
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.

Post reply on HN