cmiiw, but imho play is too similar with others web framework, like rails.
i'd prefer scala community to push lift instead.
lift has some great ideas, and has many things to improve.
Why I'm Moving Away from the Play Framework
11–20 of 88 posts
Re: Why I'm Moving Away from the Play Framework
#12Play made it very very easy for me to target a jar from php. The php-java bridge at the time would start and stop the jvm with every request (I dont know how it stands up today). I did some research and was able to stand up a play server whose routes reflected classes/methods in the jar in about 20 mins.
Are there other play-like frameworks for java?
Re: Why I'm Moving Away from the Play Framework
#13Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
Re: Why I'm Moving Away from the Play Framework
#14Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.
Re: Why I'm Moving Away from the Play Framework
#15So what's the best alternative for a Java shop?
Depends what your doing... I have JEE6 template project which basically set up with everything configured. This can be nearly as productive as django.
Re: Why I'm Moving Away from the Play Framework
#16So what's the best alternative for a Java shop?
I don't know about 'best', but I certainly can tell you what we've done for our latest project, Voost. https://www.voo.st/
Google App Engine cause we hate doing sysadmin work. Objectify. Cambridge Template Engine with JEXL. RestEasy/HtmlEasy. Jackson. Guice to bind it all together. Front end is heavily CoffeeScript, Handlebars, Jquery, LabJS, customized bootstrap and various other libraries. We've got a credits page full of links to the above projects... https://www.voo.st/about#credits
Overall, I'm pretty happy with this choice. We've had to do some weird and semi-complicated stuff to integrate it all together, but at this point, it works quite well.
Re: Why I'm Moving Away from the Play Framework
#17I use Play! frequently. Love it.
I maybe be misunderstanding her first point, but I am currently running individual unit tests in IntelliJ for one of my play apps on 1.2.4...
I can't speak to her other issues, I've never run in to them.
Re: Why I'm Moving Away from the Play Framework
#18"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework."
Fair enough, but I wouldn't switch to an inferior framework over it.
Re: Why I'm Moving Away from the Play Framework
#19Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.
I'm not if sure the author understands concurrency.
EDIT: Author of the blog post.
Re: Why I'm Moving Away from the Play Framework
#20So what's the best alternative for a Java shop?
We're using Apache Wicket and are pretty happy with it.