I have to confess I found this the most confusing navigation interface ever. I quit after a half dozen slides. Was there a "home" option somewhere I stupidly missed?
Why are you sorry? Different frameworks have different strengths (and weaknesses!). When in doubt, going with what you are most comfortable with is frequently a good bet.
Partial to Grails - would liked to have seen the 'demo data' approach in Grails call an external service method instead of inline in the bootstrap process. It's the default way that's shown, but doesn't allow for too much growth. It's one of those 'default' things that you see everyone doing because it's what's promoted, but it's not really a great practice - having a separate service method that can rebuild initial or sample data (which can also be invoked from other locations, not just the bootstrap) would be preferable. Or, perhaps better, use one of the 'sample data' plugins which provide DSLs for that sort of thing.
Grails is decent in my experience but I have two major gripes after working on a large Grails project
1. code reloading (ie change code, see results) doesn't work reliably and server restarts are slow
2. The ORM is still based on hibernate.
Is it just me or does anyone else have an incredibly difficult time with hibernate? I've wasted many stressful days debugging weird flush exceptions. I've never had trouble with ActiveRecord. I think it boils down to the concept of a "session" in hibernate, which is essentially a giant global variable begging you to touch it or look at it wrong, whereupon it will plot its revenge by deciding which obscure exception to throw at flush time.
Hibernate is useful in one situation: you have a transaction that has to exist across actions taken by multiple disparate services, and you still need the container to manage this for you.
In my opinion, if your in that situation, you either have an application that is an edge case, or you've architected your application poorly.
My rule of thumb:
If it has the word 'enterprise' anywhere in it's name or description. Avoid it like the plague, only use it if its the last available option.
Couldn't agree more about the enterprise sentiment. That is why I like things like Grails, that try and drag the enterprise java world, kicking and screaming into the modern era of ruby on rails style mvc and such.
I think Grails mostly succeeds at this modernization, but I have to give fair warning that there are still some enterprisey bits (Spring, which isn't so bad and Hibernate, which will bite you) down in the guts.
edit: Forgot to mention that Groovy is a fantastic, under-appreciated language with some neat features that should get more attention. Groovy is a major selling point for using Grails.
I love groovy. Anytime I have something 'Java-JVM' that isn't performance critical, I write it in groovy. But even that mindset is falling away given the ability to use @CompileStatic.
The best part of groovy to me is that I can use it where I want, when I want, with a single POM dependency and without (generally) having to think about how it interacts with existing Java code.
When I write a Jersey controller, I start in java, if I hit a point where I'm thinking "this would be easier with a closure" or "defining an entire inner class here is stupid", I stop, change the file ending from .java to .groovy, and code away.
> Anytime I have something 'Java-JVM' that isn't performance critical, I write it in groovy. But even that mindset is falling away given the ability to use @CompileStatic.
The @CompileStatic-based static compilation in Groovy only began being written 1 year ago (in October 2011), and was only mature enough to be included in a production-ready version of Grails (version 2.2) a few weeks ago (December 2012).
Scala has had static compilation from the very beginning, and was rewritten between Scala 1.x and Scala 2.x.
Stick to dynamic typing if you're using Groovy, even stuff that isn't performance critical.
Yes, that was my exact experience with Hibernate. I spent two years working on apps that used Hibernate and I never felt like I really understood how it worked. ActiveRecord for the most part "Just Works" for me in comparison.
I agree that the Hibernate's session can make debugging maddening. You should check out EBean (the default Java ORM bundled with Play 2). It is basically Hibernate without the stateful session stuff. I had never heard of it before Play and now I am really surprised that more people aren't using it.
Grails 2 does change the reloading agent to a custom one from SpringSource compared to previous versions - https://github.com/SpringSource/spring-loaded . Hopefully that does take away much of the code reloading woes.
Since June, when the presentation was created, Play has gone through a few big revisions. The primary method of accessing a database is Anorm (which, if you aren't a Hibernate fan, Anorm is a huge win) although you can also use Hibernate, or you also have the choice of using Slick, which is Typesafe's ORM (and a lot easier to use). IntelliJ 12 has better support for Play as well, and the overall performance has improved a great amount.
It's too bad that the presentation doesn't include sample Scala code for Play; imho this is the number one reason to use Play. The saveRating() controller method that they use as Play's example, which is some twenty lines of Java code, could be done in one or two lines of Scala code. Similarly, running a job in Play is essentially just spinning up an Akka actor and scheduling messages to send to it-- very very straightforward.
Play has been extremely easy to work with, especially with writing Scala code, and it's much more lightweight compared to, say, the Lift framework.
Can Play 2 be made to work well with hibernate+JPA?
I know many people don't like it , but I invested a fair amount of time into understanding hibernate and if I stick with the JVM I would want to be able to apply that.
Yes, it will work. There's no magic sauce about adding whichever ORM you want; just declare it as a dependency in your build file and you're ready to go.
Thanks, is there anything "weird" about it though?
For example: I remember in play 1.x various helper method were provided that were different from those in standard JPA including something that felt like properties in ruby. Not really a problem in practice, but required a litte trial and error when compared with the hibernate docs. However I imagine Play 2 makes use of various dynamic style programming techniques (via Scala) that might make hibernate behave in subtly different ways to what the hibernate literature might lead you to believe?
I appreciate that this is an extremely hand-wavey question.
Play uses Ebean on the Java side of the fence. Anorm is for Scala users. Here's how to do a query for a person in Anorm:
SQL("select * from person where id = {id}").on("id" -> myAgeVariable).map(row => MyPersonObject(row[String]("name"), row[Int]("age"))).toList
...returns you a list of MyPersonObjects. No need for JPA bindings or any other annotations. Based on type safety, you must have the method MyPersonObject.apply(name: String, age: Int) or else the compiler will error. It's a great way of catching SQL funkiness inside your IDE.
Yech, embedding raw SQL strings in a typesafe, compiled language like Scala is so full of fail it's not funny. Hopefully they'll switch out Anorm for Slick (which is also a Typesafe project - http://slick.typesafe.com/) soon.
Agreed, about about Ebean being the nicest Java ORM. Ebean's lack of a stateful session seems much less maddening than Hibernate. I wonder why it isn't used more.
I don't know why JRuby + Rails gets no love. JRuby is similar to Groovy but the Rails ecosystem is far far better than Grails. I have worked on all three frameworks and I think -
- The Rails ORM (ActiveRecord) is far more superior and mature than ANORM or anything out there
- The Rails templating system is super easy and feature rich
- Rails has awesome libs like Devise (Authentication), Cucumber (BDD) and Capybara (UI Testing)
- The argument that Ruby is slow is not really valid with JRuby + Torquebox. Yes, it cannot match Java but for most apps it is sufficiently fast.
All in all, I have been trying to find a better combination than Rails + JRuby but I cannot find any. If pushed against a wall I would only say that for large projects some sort of type safety helps which Scala can provide but prepare for some pain while development (when compared to JRuby + Rails ecosystem).
I'm really surprised that you would consider ActiveRecord more mature and superior to anything else. I've always considered it the weakest part of Rails. It doesn't include support for foreign keys (you can ad it with a 3rd party plugin but I was really surprised that it wasn't included) and it gives you no control over which fields are lazy loaded. Am I missing something? Why do you consider it superior to everything else?
About Lazy Loading at field level it is not really needed in most scenarios. You can do it with your own code if you wanted it that way.
Edge case scenarios may be handled differently in most ORMs however with Active Record I never felt the need to write SQL ever. Also for simple checks I use the Rails console to see data whereas with other ORMs I had to open a SQL console.
In case anyone wants to check out the live demos of the apps that Matt Raible and I built for this presentation check out the Grails app:
http://bike.ubertracks.com/
Both apps are a bit dated at 7 months old because Grails and Play have been progressing pretty quickly. With Play 2.1 on the horizon it's probably time for a refresh. And as someone pointed out, I've need to do a Scala + MongoDB + Single Page App version. Just haven't had the time. But in case anyone is interested, someone did create a Spring MVC version of the app:
https://github.com/brentlemons/runhappy
I started using Play! when it was at about v1.0 because it was a simple light framework and an easier alternative to grails or spring.
I'm not going to use it for any new projects though. Play 2.0 is a whole different thing which seems targetted at Scala mainly (which I don't have time to learn) , and is not very backwards compatible with play 1.x at all.
In my opinion it's worth the time spent learning, I think Scala is much less complex than its reputation and doesn't take much time to learn the basics, and once I did, I didn't want to go back to Java which seems to me now much more complex and cumbersome than Scala. It's really starting to become my favorite general purpose language.
I'm sure it's a decent language. It's that I have only so much learning time available and Ruby/JRuby , JS and ObjC seem like they would be a more practical use of it.
If I wanted to learn something for personal interest I would probably want to do Scheme,Haskell or Go.
54 comments
[ 5.2 ms ] story [ 87.9 ms ] thread(tl;dr Spring MVC first, then Grails, then Play)
I'm personally going to try Play next actually, mostly due to Scala being typed
1. code reloading (ie change code, see results) doesn't work reliably and server restarts are slow
2. The ORM is still based on hibernate.
Is it just me or does anyone else have an incredibly difficult time with hibernate? I've wasted many stressful days debugging weird flush exceptions. I've never had trouble with ActiveRecord. I think it boils down to the concept of a "session" in hibernate, which is essentially a giant global variable begging you to touch it or look at it wrong, whereupon it will plot its revenge by deciding which obscure exception to throw at flush time.
In my opinion, if your in that situation, you either have an application that is an edge case, or you've architected your application poorly.
My rule of thumb:
If it has the word 'enterprise' anywhere in it's name or description. Avoid it like the plague, only use it if its the last available option.
I think Grails mostly succeeds at this modernization, but I have to give fair warning that there are still some enterprisey bits (Spring, which isn't so bad and Hibernate, which will bite you) down in the guts.
edit: Forgot to mention that Groovy is a fantastic, under-appreciated language with some neat features that should get more attention. Groovy is a major selling point for using Grails.
The best part of groovy to me is that I can use it where I want, when I want, with a single POM dependency and without (generally) having to think about how it interacts with existing Java code.
When I write a Jersey controller, I start in java, if I hit a point where I'm thinking "this would be easier with a closure" or "defining an entire inner class here is stupid", I stop, change the file ending from .java to .groovy, and code away.
The @CompileStatic-based static compilation in Groovy only began being written 1 year ago (in October 2011), and was only mature enough to be included in a production-ready version of Grails (version 2.2) a few weeks ago (December 2012).
Scala has had static compilation from the very beginning, and was rewritten between Scala 1.x and Scala 2.x.
Stick to dynamic typing if you're using Groovy, even stuff that isn't performance critical.
Also, you are not restricted to hibernate since the GORM stuff has been refactored and now supports new hotnesses like MongoDB and Redis - https://github.com/SpringSource/grails-data-mapping
Also you can switch to JPA and use any JPA provider
I absolutely won't use Hibernate for any new projects. I don't understand why anyone is using Hibernate. Here is a write-up of my experiences with it:
http://www.databasesandlife.com/hibernate/
Edit: Based on this claim: "Play 2 and Grails 2 are often hyped as the most productive JVM Web Frameworks." Slide 2
It's too bad that the presentation doesn't include sample Scala code for Play; imho this is the number one reason to use Play. The saveRating() controller method that they use as Play's example, which is some twenty lines of Java code, could be done in one or two lines of Scala code. Similarly, running a job in Play is essentially just spinning up an Akka actor and scheduling messages to send to it-- very very straightforward.
Play has been extremely easy to work with, especially with writing Scala code, and it's much more lightweight compared to, say, the Lift framework.
I know many people don't like it , but I invested a fair amount of time into understanding hibernate and if I stick with the JVM I would want to be able to apply that.
For example: I remember in play 1.x various helper method were provided that were different from those in standard JPA including something that felt like properties in ruby. Not really a problem in practice, but required a litte trial and error when compared with the hibernate docs. However I imagine Play 2 makes use of various dynamic style programming techniques (via Scala) that might make hibernate behave in subtly different ways to what the hibernate literature might lead you to believe?
I appreciate that this is an extremely hand-wavey question.
SQL("select * from person where id = {id}").on("id" -> myAgeVariable).map(row => MyPersonObject(row[String]("name"), row[Int]("age"))).toList
...returns you a list of MyPersonObjects. No need for JPA bindings or any other annotations. Based on type safety, you must have the method MyPersonObject.apply(name: String, age: Int) or else the compiler will error. It's a great way of catching SQL funkiness inside your IDE.
When I use minimalist web frameworks, I get to use best-of-class libraries across the board, not make decisions based on damage control.
Examples of minimalist web frameworks: Sinatra, Flask, Scalatra, Ring/Compojure
Ebean looks interesting but it seems me that there is very small community, some documentation are from year 2009(it seems me litle bit old).
- The Rails ORM (ActiveRecord) is far more superior and mature than ANORM or anything out there - The Rails templating system is super easy and feature rich - Rails has awesome libs like Devise (Authentication), Cucumber (BDD) and Capybara (UI Testing) - The argument that Ruby is slow is not really valid with JRuby + Torquebox. Yes, it cannot match Java but for most apps it is sufficiently fast.
All in all, I have been trying to find a better combination than Rails + JRuby but I cannot find any. If pushed against a wall I would only say that for large projects some sort of type safety helps which Scala can provide but prepare for some pain while development (when compared to JRuby + Rails ecosystem).
About Lazy Loading at field level it is not really needed in most scenarios. You can do it with your own code if you wanted it that way.
Edge case scenarios may be handled differently in most ORMs however with Active Record I never felt the need to write SQL ever. Also for simple checks I use the Rails console to see data whereas with other ORMs I had to open a SQL console.
And the Play app: http://hike.ubertracks.com/
The code is at: https://github.com/jamesward/happytrails
Both apps are a bit dated at 7 months old because Grails and Play have been progressing pretty quickly. With Play 2.1 on the horizon it's probably time for a refresh. And as someone pointed out, I've need to do a Scala + MongoDB + Single Page App version. Just haven't had the time. But in case anyone is interested, someone did create a Spring MVC version of the app: https://github.com/brentlemons/runhappy
I'm not going to use it for any new projects though. Play 2.0 is a whole different thing which seems targetted at Scala mainly (which I don't have time to learn) , and is not very backwards compatible with play 1.x at all.
If I wanted to learn something for personal interest I would probably want to do Scheme,Haskell or Go.