Ask HN: Is anyone doing any significant work with the play framework?
10 comments
I ran across play a couple of months ago and I love it (wrote article on my initial thoughts back in Feb - http://www.agentcurry.com/2010/02/15/the-power-of-play).
Like a couple other commenters, I come from the J2EE world and always found the MVC frameworks overkill for most non-enterprise apps (even some enterprise apps for that matter). I really like all the niceties they have integrated into Play. It's intuitive, easy to use and you can get something up and running fast (very fast). To get my feet wet I've created a URL shortener app. It's a pretty simple app, but has allowed me to explore and familiarize myself with the features of Play! It's been a great experience using Play! thus far; I've just started a more "robust" application using Play! and hope it continues to exceed expectations.
Like a couple other commenters, I come from the J2EE world and always found the MVC frameworks overkill for most non-enterprise apps (even some enterprise apps for that matter). I really like all the niceties they have integrated into Play. It's intuitive, easy to use and you can get something up and running fast (very fast). To get my feet wet I've created a URL shortener app. It's a pretty simple app, but has allowed me to explore and familiarize myself with the features of Play! It's been a great experience using Play! thus far; I've just started a more "robust" application using Play! and hope it continues to exceed expectations.
Have you taken a look at another Java-based framework www.scooterframework.com? All your experiences in Rails can be found there: ActiveRecord, associations, routes, named sql queries, i18n, ajax, etc. I particularly like the one-click routes link. I think Scooter's routes which is based on Rails is much better. Also I like Scooter's ActiveRecord over Play's JPA. I just cannot tolerate annotations polluting my Java class everywhere.
Scooter is very impressive. I can almost convert my Rails app to Scooter-based app in Java line by line. ActiveRecord is awesome. I think that is probably why it took only 260 lines of Java code to write Twitter in Scooter.
Personally I think ActiveRecord is the weak link in Rails (2.x ... I see they are doing some fixing in 3.0).
Coming from Hibernate and such, it may seem like a breath of fresh air, but the result of a find ain't lazy, the query language sucks making you drop to SQL even for sub-selects, and the model definitions look weird ... inferring the columns from the DB schema is the wrong approach IMHO (they should take a look at Django sometimes).
Coming from Hibernate and such, it may seem like a breath of fresh air, but the result of a find ain't lazy, the query language sucks making you drop to SQL even for sub-selects, and the model definitions look weird ... inferring the columns from the DB schema is the wrong approach IMHO (they should take a look at Django sometimes).
Scooter framework allows you to use both ActiveRecord and direct sql queries which you either embed in code or list in sql.properties file. See http://www.scooterframework.com/docs/lovely_features.html#na...
Django is a nice framework. But don't you think that listing table columns in Django model code is a violation of DRY (Don't Repeat Yourself)? Database already holds meta data. Repeating it in model code is unnecessary.
Django is a nice framework. But don't you think that listing table columns in Django model code is a violation of DRY (Don't Repeat Yourself)? Database already holds meta data. Repeating it in model code is unnecessary.
> But don't you think that listing table columns in Django model code is a violation of DRY (Don't Repeat Yourself)? Database already holds meta data. Repeating it in model code is unnecessary.
No, because the columns definitions in Django are complete. You specify their meaning, not their internal representation. And you can also add your own types easily.
In ActiveRecord you have to look at the DB schema for, well, the table definition, and you have to look again at the model's definition for validation rules or for relationship rules. It may be DRY, but it's not KISS.
And I never have to work with the database schema directly, like writing SQL for the schema definition (I only drop to the db's console for debugging purposes, nothing else). A migration utility like South can detect the code-changes I've made and write the migrations for me.
No, because the columns definitions in Django are complete. You specify their meaning, not their internal representation. And you can also add your own types easily.
In ActiveRecord you have to look at the DB schema for, well, the table definition, and you have to look again at the model's definition for validation rules or for relationship rules. It may be DRY, but it's not KISS.
And I never have to work with the database schema directly, like writing SQL for the schema definition (I only drop to the db's console for debugging purposes, nothing else). A migration utility like South can detect the code-changes I've made and write the migrations for me.
Definitely looks interesting...I'm going to dive deeper. They really, really need a site re-design however. :/
Has anyone come to play from Rails (as I have)? Is there anything you miss from Rails?
never heard of it before. the demo seems to leave itself open to CSRF though. shrug.
Well, glad you're paying attention, but that's not correct. Play escapes everything for you by default, just as Rails 3.0 does now (http://www.playframework.org/documentation/1.0.1/releasenote...)
Not talking about escaping. I'm talking about the fact that there doesn't appear to be anything like an authenticity token backing the POST that's used to create a new item.
It's perfect, I think, unique in Java world.
I don't have any systems deployed to production yet, but am in the process of creating an internal app using Play and am liking what I see so far.
There are a few minor problems with the framework being quite immature, and I don't always think the creators have a clear roadmap of where they are going. However in a way this is good for me, because the early adopters can help drive things, but with the core team trying to keep the framework as light as possible.
Coming from a j2ee type background, running each instance as a standalone process, not inside an appserver was a little strange at first. But the process separation has turned out to be a good thing for me, just takes a little more management. But because things are structured in a REST/share nothing architecture, the ability to use a proxy with failover configuration and doing hot deploys via this is nice.
The team are very responsive with help on the google group, and bugs are fixed very quickly, you just have to be prepared to run with nightly builds to keep up to date.
One worry I do have is how the team/community will continue to handle if things do become more popular. I am worried about an influx of new developers clogging the current direct channel to the developers and feel the community will have to split into newbies/users/developers to handle things more efficiently. But they are doing a great job so far so long may it continue.
There are a few minor problems with the framework being quite immature, and I don't always think the creators have a clear roadmap of where they are going. However in a way this is good for me, because the early adopters can help drive things, but with the core team trying to keep the framework as light as possible.
Coming from a j2ee type background, running each instance as a standalone process, not inside an appserver was a little strange at first. But the process separation has turned out to be a good thing for me, just takes a little more management. But because things are structured in a REST/share nothing architecture, the ability to use a proxy with failover configuration and doing hot deploys via this is nice.
The team are very responsive with help on the google group, and bugs are fixed very quickly, you just have to be prepared to run with nightly builds to keep up to date.
One worry I do have is how the team/community will continue to handle if things do become more popular. I am worried about an influx of new developers clogging the current direct channel to the developers and feel the community will have to split into newbies/users/developers to handle things more efficiently. But they are doing a great job so far so long may it continue.
We're building an app that will be going into production in the next few weeks. It's not a huge application, probably around 300 hours of work.
Coming from a framework stack of WebWork/Struts2, Spring and Hibernate, it's a total breath of fresh air. Everything is there that you ask for, even nice little helper methods like encrypting strings, resizing images or serving byte arrays as documents.
We keep expecting to find some big shortcoming that brings about loads of painful refactoring, but it hasn't happened yet!
The templating engine is simple, clean and gets out of your way. The hot reloading really does work. The fact that there is NO XML configuration in our app is blissful and a real wake up call to how absurd Spring and Hibernate configuration used to be. The error messages are almost always enough to show you straight away where the problem is.
The only downside is that it completely shuns the entire Servlet API (although I appreciate that this is where a lot of the simplicity comes from). As a result you cant leverage any servlet-based components. But maybe that's a good thing.
I'm seriously impressed. I thought my company was going to have to make a jump to python or ruby to get such a clean, simple well thought through full-stack framework, but we dont.
Coming from a framework stack of WebWork/Struts2, Spring and Hibernate, it's a total breath of fresh air. Everything is there that you ask for, even nice little helper methods like encrypting strings, resizing images or serving byte arrays as documents.
We keep expecting to find some big shortcoming that brings about loads of painful refactoring, but it hasn't happened yet!
The templating engine is simple, clean and gets out of your way. The hot reloading really does work. The fact that there is NO XML configuration in our app is blissful and a real wake up call to how absurd Spring and Hibernate configuration used to be. The error messages are almost always enough to show you straight away where the problem is.
The only downside is that it completely shuns the entire Servlet API (although I appreciate that this is where a lot of the simplicity comes from). As a result you cant leverage any servlet-based components. But maybe that's a good thing.
I'm seriously impressed. I thought my company was going to have to make a jump to python or ruby to get such a clean, simple well thought through full-stack framework, but we dont.
I'm curious...can you describe a servlet-based component that you might want to reuse? As I've been doing Ruby mostly for the last few years, I'm struggling to think of an example.
I'm not sure what dabeeeenster had in mind, but I know that we previously integrated third party forums and other modules into our servlet based applications. You still have the option to run servlet based components on a subdomain to keep your core Play app clean.
I think because Play is Java, you tend to want to merge it into existing servlet applications, but you have to realise that it's the same as moving to an entirely new language. It might be based on the same core language, but its not really compatible.
Although we were excited about creating something with Play, we had to hold back several months because there was no way to gradually migrate and integrate Play into our existing servlets. It only really works when you are starting a new project. Its not ideal, but as previously said, you have to treat it as completely separate, not linked to servlets and its as though you are moving to Ruby etc.
I think because Play is Java, you tend to want to merge it into existing servlet applications, but you have to realise that it's the same as moving to an entirely new language. It might be based on the same core language, but its not really compatible.
Although we were excited about creating something with Play, we had to hold back several months because there was no way to gradually migrate and integrate Play into our existing servlets. It only really works when you are starting a new project. Its not ideal, but as previously said, you have to treat it as completely separate, not linked to servlets and its as though you are moving to Ruby etc.
Hi.
We use Play! Framework in production since a year ago.
We have two sites, http://www.masterbranch.com which is a site to manage developer CVs and track your open source experience in your CV. The other one is a network about developers, sysadmins, web designers (this one is in spanish) http://es.debugmodeon.com
We are happy with Play!. It's easy to use, has lots of built-in features and Play! team is also awesome and their work is exquisite.
Cheers
We have two sites, http://www.masterbranch.com which is a site to manage developer CVs and track your open source experience in your CV. The other one is a network about developers, sysadmins, web designers (this one is in spanish) http://es.debugmodeon.com
We are happy with Play!. It's easy to use, has lots of built-in features and Play! team is also awesome and their work is exquisite.
Cheers
I am moving from Grails to Play, because i can no longer deal with the half-assed-ness of Grails. It is so buggy and those issues shine thorugh to my product. It is hard to break-dance when walking on eggs.
>> The only thing I find missing is not really a problem with play! but rather a limitation of Java...I am completely, totally addicted to Ruby's blocks. I love being able to collection.each{|one|} over lists...it just feels right.
Absolutely true and that is why they are working hard on making Scala a first class citizen with Play. With Scala you basically get a lot of the conciseness of Ruby but with the static type checking and early error catching that you get from Java.
>> The only thing I find missing is not really a problem with play! but rather a limitation of Java...I am completely, totally addicted to Ruby's blocks. I love being able to collection.each{|one|} over lists...it just feels right.
Absolutely true and that is why they are working hard on making Scala a first class citizen with Play. With Scala you basically get a lot of the conciseness of Ruby but with the static type checking and early error catching that you get from Java.
Playframework is just great..
Long time Java and Ruby guy here. Most recently have spent much of my time with Rails, which I really enjoy...most of the time. However, I find it infuriating at times to read through some of the code of the framework itself...the magic(tm) of ruby simply makes it difficult to trace at times. To boot, none, and I mean none (including RubyMine) of the available IDEs do a great job of ruby source navigation. They're at times adequate, but a far cry of the capabilities Java IDEs give you.
Four months ago, someone posted a link to playframework.org. I glanced it over, half interested but wary of picking up and learning yet another half-assed attempt at copying Rails to the Java world (I'm looking at you, Grails). However, earlier this week, something made me think of it, and having some spare time, I downloaded it and walked through the tutorial.
I am blown away.
play! supports just about every feature I can think of that I find so appealing in Rails, but it does so in Java. The code is clean. The project seems mature. The layout of a project is almost identical to a Rails project, so it's very easy for a Rails developer like me to grok. It will generate project files for Eclipse, Netbeans, Textmate and Intellij on command. It will walk your dog and make love to your wife, while finishing up the yard work you've recently neglected. Ok, that might be a stretch, but you get the idea.
The only thing I find missing is not really a problem with play! but rather a limitation of Java...I am completely, totally addicted to Ruby's blocks. I love being able to collection.each{|one|} over lists...it just feels right.
That said, play!'s clean code and style make Java palatable again, and the speed is fast(!). It's the first time I've been excited about Java development in a long time. I'm really surprised the buzz around it has been rather quiet. I think it's a Java web development game changer.
So, sorry about the blathering, but I'm curious...are any other HN'ers using play? If so, what's your experience been so far? Have you run into any limitations that would cause you to steer others away from it? Have you deployed to production yet?
Please share your experience or thoughts on play, if you don't mind.
Thanks.