GeeCON Prague 2014*
The moose likes Scala and the fly likes Play for Scala - SBT advice?  Compile time? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Languages » Scala
Bookmark "Play for Scala - SBT advice?  Compile time?" Watch "Play for Scala - SBT advice?  Compile time?" New topic
Author

Play for Scala - SBT advice? Compile time?

Michael Swierczek
Ranch Hand

Joined: Oct 07, 2005
Posts: 107
    
    1
Peter Hilton, Erik Bakker, and Francisco Canedo,

Thank you for taking place in the Scala Books giveaway.

I used Play 1.2.x for a simple intranet application at work and found it to be excellent and easy to use. I was especially blown away by the value of instant feedback from changes - now I understand what the Python, Perl, Ruby, PHP, etc... developers were raving about and why working with Java Servlets made them crazy. ;) I started learning Play 2, but I ran into two headaches that were not present in Play 1.

First, making non-trivial changes to the SBT (for anyone else reading this, that's Simple Build Tool, the Maven-analog used by many Scala projects) settings required tackling the SBT learning curve. I found that very time-consuming, it took me more time to understand SBT than it took me to understand all of the features I wanted to use in Play 2. I see that as an obstacle to adoption, a throwback to early Java EE days. "We have this awesome tool, but the learning curve before you can work quickly is brutal."

Does your book cover SBT in any detail? If not, can you recommend any SBT documentation or book besides the official website?

Second, one of the greatest features of Play 1.x was the hot reload. You make your change, save your .java or template or other file, hit F5 in your browser, and you get the new page or a helpful error immediately or almost immediately. Play 2 has the same features, but the Scala language is more complex and the Scala compiler then is much slower. So you make your changes to your .java or .scala file or template, hit F5 in your browser, and then wait 5 or 10 seconds, sometimes longer, until you get your results. That's still better than the feedback loop on an old Servlet application - make change, save, restart Tomcat, refresh page - but it's very frustrating if you've been spoiled by the almost instant reload time of a Play 1 application.

Am I the only person with this problem? Do you see any solution, or does it seem to improve with newer versions of Scala? Are there any tips for reducing the impact?
Erik Bakker
author
Greenhorn

Joined: Feb 03, 2013
Posts: 8
Michael Swierczek wrote:Peter Hilton, Erik Bakker, and Francisco Canedo,
First, making non-trivial changes to the SBT (for anyone else reading this, that's Simple Build Tool, the Maven-analog used by many Scala projects) settings required tackling the SBT learning curve. I found that very time-consuming, it took me more time to understand SBT than it took me to understand all of the features I wanted to use in Play 2. I see that as an obstacle to adoption, a throwback to early Java EE days. "We have this awesome tool, but the learning curve before you can work quickly is brutal."


That's right. I've done a few presentations about Scala where I mentioned: "... and the standard build tool for scala is SBT, which stands for Simple Build tool and it's a very complex build tool."

SBT is hard to grasp. However, to be fair, the Play 1 python build script might have been easier to understand, but that thing could not be adapted to your needs at all. Early versions didn't even do dependency management.

Does your book cover SBT in any detail? If not, can you recommend any SBT documentation or book besides the official website?

Our book (Play for Scala), does not cover much of SBT. Josh Suereth is currently writing a book on SBT and I'm quite confident that that book will be extremely useful and worthy of recommendation.

Second, one of the greatest features of Play 1.x was the hot reload. You make your change, save your .java or template or other file, hit F5 in your browser, and you get the new page or a helpful error immediately or almost immediately. Play 2 has the same features, but the Scala language is more complex and the Scala compiler then is much slower. So you make your changes to your .java or .scala file or template, hit F5 in your browser, and then wait 5 or 10 seconds, sometimes longer, until you get your results. That's still better than the feedback loop on an old Servlet application - make change, save, restart Tomcat, refresh page - but it's very frustrating if you've been spoiled by the almost instant reload time of a Play 1 application.

Am I the only person with this problem? Do you see any solution, or does it seem to improve with newer versions of Scala? Are there any tips for reducing the impact?


Getting it as fast as Play 1 will probably never happen. But there are a few things to ease the pain:

1) Use `~ run` instead of just `run`. When you prefix a command with `~`, it will be automatically executed again after a code change. With a `run` in Play, it reloads only on the next request (refresh in the browser), but if you do `~ run`, it will already start compiling after saving, and the reload will be quicker.

2) IIRC Play 2.1 and its sbt version 0.12.2 will have a bit better incremental compilation support, potentially reducing compilation times.

3) Scala 2.11 will focus on compiler speed.

4) Your next computer will be faster

Also, but that may be personally, I find myself reloading way less than on Play 1 applications. Scala IDE is very good at highlighting errors, and I can code long periods of time without ever refreshing in between.

Anyway, the first tip may be the only thing that's usable for now, but it should certainly help


I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.
Michael Swierczek
Ranch Hand

Joined: Oct 07, 2005
Posts: 107
    
    1
Erik Bakker,

Thanks for your responses, I'm satisfied with the answers. I imagine the "~run" change is especially helpful in the common case when you change multiple files before returning to the browser. Then instead of waiting for SBT to recompile a few files when I reload the page, it's already recompiled or found errors in all but the most recently changed file.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Play for Scala - SBT advice? Compile time?