Experiences with Scala and Liftweb – eventsofa
Welcome back. My employer was bought by eBay at the beginning of 2011 and most of my time in 2011 was taken by work. 2012 has come and I revive this blog – beginning with this post and moderation of some hundred comments.
My wife founded a startup called eventsofa to make the German event location market transparent.
Although I’m not directly involved in development, during breakfast and dinner I obviously influence technology decisions and get feedback on those (and talking to the developer). One decision was to use Scala and Liftweb, because I thought they would greatly increase productivity.
There has been some light and some shadow. From watching a developer, Scala is more productive than Java, but only slightly. This also the experience from my own private work with Scala. You need to type less, tuples, pattern matching and functions are helping here. In Java you would need much more boilerplate. But IDE support (Intellij IDEA) is so much worse for Scala, that most of the productivity gains are eaten by errors that are only encountered during compilation.
Compilation takes much longer too and I don’t think the compiler is slow, but the reason is that Scala creates 10x more classes for your classes. And this takes time to compile. SBT seems to work though with ~compile, one problem remaining that you need to have a shell open and visible to see compilation results. Not everything without error flags in the IDE does compile.
Liftweb seems to be a mixed blessing too. CSS selectores are brilliant and beautiful – really – for separating HTML and logic. Rogue is also an excellent ORM for MongoDB. Type-checked queries are much nicer than using Strings for queries. Box is something like Option in Scala, extended with error and failure conditions. But it’s not enough integrated with Option and there is always the clash between frameworks that use Option and Lift that uses Box as an idiom. Box should be something that is part of the Scala core. I like Box better than Scalaz Validation, though people tell me Validation is more powerful. The lift tryo idiom is nice and short, converting Exceptions into Boxes.
The downsides of Liftweb are plentyful though. There is no good practice page. The existing books are introductions, but do not show good practices. With the myriad of options to do things, it seems that you always do it wrong. The mailing list results are usually not very useful, and the project has no clear direction. Why does one need to add each page to Boot? Why no annotations? While the parameter extraction for REST style URLs is nice, as it does provide variable checks, one would prefer this inside the controller class. The main downside seems to be the complexity of Lift. Onboarding developers (students) seems to be a pain. I also think I never again suggest to someone using a web framework that is dominated by one person. We had bad experiences at work with Tapestry, the same seems to be in effect with Lift.
Watching someone develop with Lift, one major issue is turn around. It’s too slow. Playing with the Play framework shows how to get fast turn around times for compilation and error checking. Comparing the error messages in Lift with the error messages in Play and how they are displayed (source in the case of Play) shows how Play is so much mor developer focused than Lift.
Ideally a framework will emerge with such good developer focus as Play, and CSS selectors and Rogue and Slashem support like Lift. I at least will not suggest Lift anymore in the future to people to use.
Those were some impressions I got when talking about eventsofa development – more impressions in some upcoming blog posts.
