31–40 of 61 posts
It's also now part of the Typesafe stack - here's the release announcement from the typesafe blog: http://blog.typesafe.com/introducing-play-20
For anyone interested in its claim of being reactive, as I was, the Play framework does not appear to support reactive programming [1]. From their samples and documentation, it looks like an event-driven server without any reactive aspects. I'm fairly sure they're mistakenly calling typical event-driven programming "reactive". This is backed up by the statements of Typesafe's CEO on the subject in an interview [2]. […
I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?
I partially disagree, especially with backing from Typesafe. The "engine" benefits from Scala, as a highly concurrent and transactional heavy system. The choice of language for building MVC applications & services on that engine is left up to the developer. The 2.0 mindset, and you see this in everything is very much a best tool for the job balanced with flexibility and choice. It's going to take a little while for a…
I just think it will be hard to justify play2's use in java-heavy organizations if Java support is a second citizen to Scala.
I loved Play 1.2.x, I think it is the only framework that really provides a way forward for modern java web dev, and I strongly hope Play 2 keeps things moving.
Earlier quoted context omitted.
Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.
This is the first controller I opened from their samples[1] : public class Forums extends Application { public static void index() { List forums = Forum.findAll(); long topicsCount = Topic.count(); long postsCount = Post.count(); render(forums, topicsCount, postsCount); } ... } You can't mock out Forum, Topic or Post. You can't inject some type of "FormRepository" or whatever pattern you want to gain some type of con…
For anyone interested in its claim of being reactive, as I was, the Play framework does not appear to support reactive programming [1]. From their samples and documentation, it looks like an event-driven server without any reactive aspects. I'm fairly sure they're mistakenly calling typical event-driven programming "reactive". This is backed up by the statements of Typesafe's CEO on the subject in an interview [2]. […
Or just read the play documentation https://github.com/playframework/Play20/wiki/Iteratees
However, Play does not offer automatic facilities for having variables (and interface) update when other variables change, as described in the Wikipedia article. For examples of reactive programming, see Knockout, batman.js and Ember.js (all primarily client-side).
When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…
I can't agree more - I've been doing a non-trivial bit of scala work in the past six months, and the part that seems the most lacking to me is JSON support. Every scala JSON library I've used (spray-json, sbjson, lift-json and the like) requires you to define a concrete serializer class for every single type you would like to move across the wire. I really miss the ease of use of reflection-based parsers like Jackson…
The reason why everyone encourage you to do so is because typeclass serialization is much more robust that introspection. With introspection you may have runtime exceptions, but with typeclass serialization you know at compile time when something is wrong.
Also, Jerkson is included in Play 2 (that's what we use as base for the Json lib) so you can use it directly if you want introspection.
But if you choose typeclass serialization, you can still define serializers easily, in one line, without losing the type-safety: https://github.com/playframework/Play20/blob/master/framewor...
Can anyone talk about their experiences of using Play 2.0 and Lift, if they've used both?
I found Play to be fairly intuitive and it matched my mental model pretty well. It was lightweight compared to Lift and the other Java frameworks I looked at. Play 2.0 seems to have made improvements in the areas I found weak in Play 1.x. i.e. modularity, Scala support (specifically for continuations)
Lift is a fairly heavy framework, but you can ignore big parts of it if you need to. In Lift it took me a while to grasp the HTML transforming concept, partly because the documentation seemed to out of date. It felt both cumbersome and elegant at the same time. Sadly I didn't get very far on the project so I have no idea how Lift has changed/improved since then.
Today I would choose Play in a heartbeat if it fit the parameters of my project.
Typesafe,
Please don't be a tool. Take your "whitepapers" out from behind an email registration page.
I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?