Found this file from my first attempts with Play about a year ago. Hadn't done any more Play until just before Christmas and got a wild thought that I should breath some life into a 15 year old java servlet app that hadn't had anything besides some a couple of css changes since 2001. Thought it would take a week, 90 days later it's about to go live for clients, with some long overdue feature additions (and is now about 80% Scala code, albeit very basic Scala code). I will blog about that soon.
Thoughts on Play Framework from a Rails dev. Part I
Why?
- Pretty much a pattern of every 4-5 years I decided to try something new that will stretch my thinking and skills
- Learning a dynamic language completely changed my thinking and processes, functional is something I know very little about
- Ruby/Rails is cool, there are tons of amazing people, ecosystem is fantastic and don't really want to leave that comfort zone.
- I have code in java and systems that can't be accessed from ruby but can be from java (or .net).
- Already did C#, even though many of the newer features are really cool, I'm committed to a linux based deployment stack. (Node would have been the next choice on the list and I still may do some playing around with it).
- The extreme static type safety of play seems almost 180 degrees from rails but the mvc nature should help to get some quicker productivity
- Perf stories behind Play are interesting to me and would like to test them out more on my own app.
The Players
- Scala and Play both installabled via brew. Play 2.1.0 and Scala 2.10.0 and jdk 1.7.0_17
- Using Intellij 12 with the play module
- Postgresql 9.2 and 9.2 jdbc driver
- Play app created with Scala as default language.
The App
- Proprietary app that's used for commercial business. Not open source.
- Main use case is searching for documents that have been indexed to a jeffersonial legal location (section, township, range, meridian)
- Documents table has two main detail tables (location and formations) but ....
- DB is too normalized (main search involves an 8 way join to get what is displayed on report)
Initial Thoughts
- omgosh, I forgot what type safety and static really means.
- omgosh, even the templates are static and type safe.
- wtf, this is going to take a bit to get used to
- templates are named backwards: footer.scala.html instead of footer.html.haml (My brain doesn't like the Play ordering. More on this later.)
- assets don't have dual extensions, main.scss is turned into main.css (why isn't it main.scss.css like the templates?)
- templates are based off scala and are an (admitted) rip-off of Microsoft's Razor syntax
- there are other template engines but I haven't quite figured that out yet (haml, jade, etc)
- People talk about Rails magic and how it's not object based (please read "Rails as She Spoke" (http://railsoopbook.com/) by Mr. Bowkett it will really help you understand a bit more about how Rails violates OO principles in exchange for developer happiness. Play is more on the OO purity side and there's not nearly as much magic.
- I would label Play as an "intentional" framework. Very little magic, you as a coder are very specific and intentional in what you want the framework to do for you.
- I saw the word dependency injection and nearly gave up right then. I'll give it some more time but that could be a deal breaker. (I have yet to see the word interface on anything yet though.)
- play console is not the same thing as rails console (looks like the play console is an sbt session that doesn't load the app).
- as many times as I've bitched about ActiveRecord...Slick is going to take some major getting used to (I did find some guys in Japan doing an active record clone for scala that looks very promising, see readability below)
- readability, ok, I'll admit I'm pretty new to play/scala BUT ruby/rails have major readability/understandability mojo going
- what's up with the single character and double character variable names in scala?
- scala is camel case (neither good or bad, just different)
- imports at the top of every file (intellij does a nice job of hiding them for me)
Alright, lets go back to this idea of Play being "intentional". Here's a line from a controller in each:
Rails: render index Play: Ok(views.html.document.index("First play view."))
So read that Play line as wrap the index function from views.html.documents (which is template file app/views/documents/index.scala.html) function in an 200 success. Ok, so Rails underneath goes through some steps to find the view template and render it and I think you're begining to see why I call Play "intentional". Here Play requires you to be explicit about the template, what's passed to it and what the http status code is.
So lets do some direct comparisons.
File ends, never got around to comparisons.