The first few times that I tried experimenting with Lift I was disappointed with the development environment options. I ended up just running Maven from a command line with the tutorial projects open in TextMate.
I had a much better experience this morning when I decided to check out the recently released version 1.0 of Lift. This worked fairly well for me:
- Create a demo project as per the getting started instructions
- Build and run the project using mvn jetty:run from the command line, then stop jetty
- Create a new IntelliJ project from existing sources (I had problems creating a project from a Maven POM file, but it was probably something that I was doing wrong)
- Open the IntelliJ Maven Projects tab and click the “circular arrows” menu bar icon to look for POM files in the current project
- I was then good to go: editing Scala code, editing Lift HTML template files, and running the mvn jetty:run target in the IntelliJ Maven Projects tab
To be honest, Rails is by far my favorite web app framework but I do find myself going back to server side Java for much better runtime performance for some projects. Since I have been working through the excellent Programming in Scala book, and generally enjoying Scala, Lift is perhaps looking like a good option for higher performance web applications where performance is more important that minimizing development costs. One thing that may convince me to stay with plain old server side Java (POSSJ) is any issues with running under the Java version of App Engine (which I am starting to like). Deployment platform selection (choosing between managed servers, App Engine, or Amazon EC2) needs to be done early because App Engine does have limitations that prevents its use for some projects, no matter how cost effective it is. POSSJ web applications that use JDO (or JPA) can be sort-of portable on and off App Engine, but Lift’s use of Scala actors (usually implemented with threads) may not play well with App Engine. On the other hand, Amazon has been consistently lowering costs for using EC2, etc. so having greater flexibility may win out over some cost savings with App Engine. (By the way, if you write and use Hadoop map reduce data crunching applications, Amazon Elastic MapReduce really is incredible – the more I use it, the better I like it!)