8 ms·

>Rapid iteration: change the code, refresh the page, and see the change instantly. I see the play people tout this all the time, and I assume it is in reaction

>Rapid iteration: change the code, refresh the page, and see the change instantly. I see the play people tout this all the time, and I assume it is in reaction to an assumption of dynamic language people that you have to manually compile every time you make a change. But it is really misleading. You make a change, refresh the page, and wait 10 seconds for it to compile and reload. Iteration speed was just as poor with play as it was with bloated J2EE monsters on jboss.

jlward4th 14y ago
You should run Play with "~run" which recompiles on file-change. Running with just "run" doesn't recompile until you hit refresh in your browser. This provides a noticeable difference in the "effective" compile time.
- papsosouid 14y ago
  We did. The difference is negligable, it takes a fraction of a second to hit f5. In fact, it costs time fairly often as you save the file, notice right away that you have a typo, fix it and save again, but now it is still busy compiling from the first time so you have to wait out two compiles.
  - wiradikusuma 14y ago
    How about this setup: IntelliJ (catches typo better), SSD (faster disk access), JRebel (free for Scala).
brikis98 14y ago
On my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test command in sbt for automatically rerunning tests on each change, and the amazing error handling, this is a massive step forward for Java/Scala web development.
- papsosouid 14y ago
  >Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. It is? Are you building a war/ear and copying it to a server to deploy or something? I think every java IDE has support for locally building and deploying within the IDE, which is no slower than play's reloading.
  - brikis98 14y ago
    For simple setups, that can work. JRebel can help. For more complex servlet apps, especially those with Spring lifecycle management, this rarely works, which means a full redeploy after almost every Java change.
- sparx 14y ago
  Intellij Idea + JRebel, I dont have to reload stuff with my Java application.
- Uchikoma 14y ago
  One usually uses JRebel instead of redeploying an app in TC/Jetty.
mgkimsal 14y ago
Not sure about play!, but with Grails most changes are picked up in < 1 second. Grails 2 is better than Grails 1 about reloading and dealing with domain changes (which by default are hibernate classes) - it used to be that most domain class changes required a restart - not so under Grails 2. I rarely restart my Grails dev env throughout a day - 95% of my changes are as fast as write/save/refresh with PHP.
marcusf 14y ago
It's a bit sad to have to look outside the standard stack for good solutions to this, but I've had great results with JRebel. The rapid iteration it brings to java easily pays for itself almost immediately, if nothing else than in not having to pull your hair waiting for classloader reloads...
eloisant 14y ago
This is mostly due to the Scala compiler being a bit slow. The team at Typesafe is working on that, but if you don't want to wait just buy a decent recent machine with a SSD and you will get back the snappiness you had with Play 1.
- papsosouid 14y ago
  I'm running on an i7 with an SSD already. Our solution was to not use play (or scala for that matter).
  - coopdog 14y ago
    What did you switch to?
    - papsosouid 14y ago
      We ended up using Haskell, which is also famously slow at compiling. But it has been significantly faster than play thus far (using snap's development mode).
      - harichinnan 14y ago
        You are one lucky B!!! Not everyone gets such a choice. It would be either Play or Spring and family.
  - coopdog 14y ago
    What did you switch to?
- dwhitney 14y ago
  I agree with eloisant, if you get a decent machine with an SSD, Play is quite snappy. Recompilations are around 1 second on my MacBook Pro with retina display, which is a small price to pay for the type safety you get with Scala
  - deleted 14y ago
taligent 14y ago
That's Play 2 you are talking about. Play 1 had instant refresh. It is not necessarily the case that you would use Play 2 for new projects.
ZoFreX 14y ago
It's more of an advertisement to people on creaky Java stacks that require a manual full app reload to pick up changes, and often do so... messily.
bad_user 14y ago
I have 8 GB of Ram and SSD and compilation speed hasn't been an issue with me in Play. The refresh process in Play is also a lot better than a JRebel-based solution or something similar, because in case of compilation errors Play generates a nice error page. The refresh speed may indeed be annoying and could be better, but it's less of an issue with Play than in Rails or Django or whatever, because you're working with a static language and while writing code you feel less of a need to see what your new lines of code produce. In Scala, if you're using it as a functional language, all the code you write tends to be correct if it compiles and Play itself uses many functional idioms making it very suitable for a functional style. It's worth noting what Play gives you when compared to Rails, Django and the like. Remember that Rap Genius article from a few days ago, in which people complained about Heroku's Bamboo stack and having to work with over 70 Heroku dynos? I have a Scala module on top of Heroku that's processing 25,000 requests per second in under 100ms per request and that's running with just 8 Heroku dynos. And I'm actually dissatisfied because a high-CPU server on top of EC2 would be able to handle all 25K. With Play you get the best of both worlds. A productive framework and the full power of the JVM. It's not easy to describe how it feels to get this combination, but it feels great, trust me.
- johnx123-up 14y ago
  Do you have any opinion about Scooter http://www.scooterframework.com/ http://www.scooterframework.com/ which looks more RoRish and productive?
  - deleted 14y ago
    [deleted]
- papsosouid 14y ago
  >I have 8 GB of Ram and SSD Me too. >but it's less of an issue with Play than in Rails or Django or whatever >It's worth noting what Play gives you when compared to Rails, Django and the like. Perhaps for some, but we have no interest in dynamic languages or frameworks written in them. We were evaluating frameworks for decent languages only. I was only commenting on the compilation speed issue because they constantly brag about fast iteration when it is no faster than a typical bloated J2EE monster.

jlward4th 14y ago

You should run Play with "~run" which recompiles on file-change. Running with just "run" doesn't recompile until you hit refresh in your browser. This provides a noticeable difference in the "effective" compile time.

papsosouid 14y ago
We did. The difference is negligable, it takes a fraction of a second to hit f5. In fact, it costs time fairly often as you save the file, notice right away that you have a typo, fix it and save again, but now it is still busy compiling from the first time so you have to wait out two compiles.
- wiradikusuma 14y ago
  How about this setup: IntelliJ (catches typo better), SSD (faster disk access), JRebel (free for Scala).

brikis98 14y ago

On my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test command in sbt for automatically rerunning tests on each change, and the amazing error handling, this is a massive step forward for Java/Scala web development.

papsosouid 14y ago
>Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. It is? Are you building a war/ear and copying it to a server to deploy or something? I think every java IDE has support for locally building and deploying within the IDE, which is no slower than play's reloading.
- brikis98 14y ago
  For simple setups, that can work. JRebel can help. For more complex servlet apps, especially those with Spring lifecycle management, this rarely works, which means a full redeploy after almost every Java change.
sparx 14y ago
Intellij Idea + JRebel, I dont have to reload stuff with my Java application.
Uchikoma 14y ago
One usually uses JRebel instead of redeploying an app in TC/Jetty.

mgkimsal 14y ago

Not sure about play!, but with Grails most changes are picked up in < 1 second. Grails 2 is better than Grails 1 about reloading and dealing with domain changes (which by default are hibernate classes) - it used to be that most domain class changes required a restart - not so under Grails 2. I rarely restart my Grails dev env throughout a day - 95% of my changes are as fast as write/save/refresh with PHP.

marcusf 14y ago

It's a bit sad to have to look outside the standard stack for good solutions to this, but I've had great results with JRebel. The rapid iteration it brings to java easily pays for itself almost immediately, if nothing else than in not having to pull your hair waiting for classloader reloads...

eloisant 14y ago

This is mostly due to the Scala compiler being a bit slow. The team at Typesafe is working on that, but if you don't want to wait just buy a decent recent machine with a SSD and you will get back the snappiness you had with Play 1.

papsosouid 14y ago
I'm running on an i7 with an SSD already. Our solution was to not use play (or scala for that matter).
- coopdog 14y ago
  What did you switch to?
  - papsosouid 14y ago
    We ended up using Haskell, which is also famously slow at compiling. But it has been significantly faster than play thus far (using snap's development mode).
    - harichinnan 14y ago
      You are one lucky B!!! Not everyone gets such a choice. It would be either Play or Spring and family.
- coopdog 14y ago
  What did you switch to?
dwhitney 14y ago
I agree with eloisant, if you get a decent machine with an SSD, Play is quite snappy. Recompilations are around 1 second on my MacBook Pro with retina display, which is a small price to pay for the type safety you get with Scala
- deleted 14y ago

taligent 14y ago

That's Play 2 you are talking about. Play 1 had instant refresh. It is not necessarily the case that you would use Play 2 for new projects.

ZoFreX 14y ago

It's more of an advertisement to people on creaky Java stacks that require a manual full app reload to pick up changes, and often do so... messily.

bad_user 14y ago

I have 8 GB of Ram and SSD and compilation speed hasn't been an issue with me in Play. The refresh process in Play is also a lot better than a JRebel-based solution or something similar, because in case of compilation errors Play generates a nice error page. The refresh speed may indeed be annoying and could be better, but it's less of an issue with Play than in Rails or Django or whatever, because you're working with a static language and while writing code you feel less of a need to see what your new lines of code produce. In Scala, if you're using it as a functional language, all the code you write tends to be correct if it compiles and Play itself uses many functional idioms making it very suitable for a functional style. It's worth noting what Play gives you when compared to Rails, Django and the like. Remember that Rap Genius article from a few days ago, in which people complained about Heroku's Bamboo stack and having to work with over 70 Heroku dynos? I have a Scala module on top of Heroku that's processing 25,000 requests per second in under 100ms per request and that's running with just 8 Heroku dynos. And I'm actually dissatisfied because a high-CPU server on top of EC2 would be able to handle all 25K. With Play you get the best of both worlds. A productive framework and the full power of the JVM. It's not easy to describe how it feels to get this combination, but it feels great, trust me.

johnx123-up 14y ago
Do you have any opinion about Scooter http://www.scooterframework.com/ http://www.scooterframework.com/ which looks more RoRish and productive?
- deleted 14y ago
  [deleted]
papsosouid 14y ago
>I have 8 GB of Ram and SSD Me too. >but it's less of an issue with Play than in Rails or Django or whatever >It's worth noting what Play gives you when compared to Rails, Django and the like. Perhaps for some, but we have no interest in dynamic languages or frameworks written in them. We were evaluating frameworks for decent languages only. I was only commenting on the compilation speed issue because they constantly brag about fast iteration when it is no faster than a typical bloated J2EE monster.