41–50 of 88 posts
I'm interested to know what alternative framework the author has chosen in place of Play!.
That's focused on RESTful services so presumably also a JS templating tool browser-side or similar.
So what's the best alternative for a Java shop?
Of course, GWT is not perfect. DevMode needs to be faster, and they need to integrate scala-gwt. :-)
I wrote a Backbone-like framework to deal with some of the boilerplate (http://www.tessell.org), especially if you're doing MVP. I don't quite have a solid DTO story down yet, but overall I like it.
If I had to use a server-side framework again, I really liked Click (http://click.apache.org), as it is component based, but has source code you can actually read (vs. both Tapestry and Wicket which are too big/magical IMHO).
Earlier quoted context omitted.
It is a very well written opinion piece that gives his ( valid ) reasons for not using play any more. That being said he doesn't say anything bad about the framework or the idealogy behind it and in fact laments having to move away from its ease of use. He does bring up the point that Play 1.X is essentially out to pasture at this point. Thats not to say typesafe can't come back and once 2.0 is settled and fix the ou…
s/he/she/ s/his/her/
Earlier quoted context omitted.
I would not use Play 1.x for Scala applications; its non-blocking support is complete crap (and I was pretty displeased to hear, when I asked in their IRC channel, that it would never be in 1.x, oh and by the way to use 2.x you'll need to rewrite your app). I can't speak to 2.x.
You don't need to totally rewrite your app, but it's not backwards compatible either. The biggest change is that they've switched the default views to be written in Scala instead of Groovy. But if you'd still like to write the views in Groovy or are porting an app from 1.x, there are a couple of guys in the community who have written plugins to support writing your views in Groovy.
While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me.
Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it understand that and accept its imperfections. I'd rather fix Java proper (or use Scala) than have a web framework think that it's their job to somehow fix a lackluster language.
Just seems like it'd lead to a lot of bloat/code in the framework that isn't "just serve this webapp as simply as possible".
That being said, what Play got right did look really awesome (the compilation error reporting in particular).
Anyway, will be interesting to see what the Play 2.x release will look like, given it looks like Typesafe is having some amount of involvement in it?
This confirms my bias against frameworks in general and in fact against reusing more code than necessary. And no, I would not write an encryption library myself or re-implement the HTTP protocol. But the disparity between what web frameworks actually do for me in any particular application and the amount of layers and dependencies they introduce boggles my mind. [Edit] If you use maven try mvn dependency:tree
Play is really not a large amount of code though and it's all in one source tree. It generally doesn't have a lot of "layers" compared to even something like Tomcat; the stack just doesn't get as deep. I've had an easy time digging in to the Play source code when needed. Just one experience fwiw. Sure, it's still a framework.
I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes). I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts. Play is a very prescriptive framework but onl…
I was surprised to see Typesafe throw its weight behind Play. While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me. Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it und…
Earlier quoted context omitted.
I'm not if sure the author understands concurrency. EDIT: Author of the blog post.
I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable.
Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread.
Threading is hard, lets go shopping.
The author wrote the Play Framework Cookbook and so it's a presentation from someone that can be considered a bit of an authority on Play (and not someone with an axe to grind). However, the presentation covers a bit of what worries me about Play. Play rewrites the bytecode for things like emulating properties and allowing you to pass whatever you want to the templates and have it automatically name the variables based on their local names in the calling method.
For me, the reason to use Java over Python or Ruby would be to move away from some of the behavior used in those languages that can make debugging and static analysis harder.
I've used Play for some hobby stuff (and kept up on Play 2.0). Play 2.0 seems to remove the former system for passing variables to the templates in favor of a system where templates accept certain parameters with types (a welcome change for me). However, at least the last time I played with it, Eclipse couldn't tell me what variables and types the template was expecting.
I guess Play leaves me feeling like it brings the magic to me without as much ease that Python and Ruby offer (or, at least, without as much familiarity). That might be changing - I think that the changes in the templating for 2.0 show a clear move in that direction. I really wish them well since it's always good to have more good options for development and there's a lot of Java already out there to leverage.