Web programming in Scala: Choosing a framework

For the last few months I have been trying to build a web site. Months? You may wonder why it's taking so long. It's nothing very fancy; just a simple input screen for a project I am working on. But the idea is to learn the techniques involved, and try to build an infrastructure that I can use for .. you know.. the super duper mega project always lurking in the pipeline.

A bit of my background. I have been a Systems Programmer (embedded systems, mostly) and my web programming skills shine at visual magnitude -20. A little bit of HTML, XML, Javascript and HTTP is fine with me, but I had a tough time staying afloat in the sea of buzzwords like JSP, JSF, Facelets, Servlets, Containers, EJBs, ORMs, ooh-my-blah-blah..

One thing I was clear about: I wanted solutions only around the language I am most comfortable with… Scala (and hence around Java). Without that restriction, the sea would have been even deeper and wider, for a newbie web developer.

Lift Web

I started by checking out [Lift Web], a framework written in Scala, and one of the oft showcased Scala applications. Lift seems to be a comprehensive framework, still in evolution (I mean the evolution of paradigms not just the code). The mailing list is very active and responsive. There have been some recent documentation efforts, but I didn't have that convenience back when I started, and so I had a tough time getting the big picture (probably because I didn't know some web basics back then). I also had a struggle with Maven (the dependency manager from Apache) which is used by the Lift guys. The problem, I think, was that Maven was being used for both dependency management and building the code. My complaints about a lack of a build tool on the scala mailing list triggered the creation of a very nifty tool: [SBT] by Mark Harrah.

Eventually, I was able to build what I wanted in Lift and it works fine. But I wished for a more light weight framework, so that I get to understand what is happening behind the scenes, and get a feeling of control.

I prowled for alternatives.

Slinky and Sweet

[Sweet] is a much simpler framework than Lift and easy to get started with. There is clear documentation available on the project's wiki. The only problem (from my point of view) is that it is based on a third party templating language (freemarker). When I mentioned this on the Sweet mailing list, it was suggested that I could build my own View class, and it was while exploring this option that the penny dropped.

I realized that this whole framework thingy is actually quite simple, once you understand Servlets and the HTTP request/response cycle. And what makes templating simple is Scala's support for XML. For example.

// This surrounds the given node with a standard template code.
def surroundWithStd (node:scala.xml.Node, title:String) = {
       <head> <title>{title}</title> </head>
       <body bgcolor="#c0c0ff">

// Sample usage
private def userAdd = {
    surroundWithStd (
         <h1>User addition</h1>
         <form method="post">
           <label for="nameField">Name</label>
           <input type="text" name="nameField" />
           <input type="submit" value="Add" />
       "user addition"

This should be faster than Lift's templating+snippet support (since the parsing of XML literals in Lift's case would have to be done at run-time) and more importantly doesn't require you to know anything more than Scala.

Ofcourse, you could do away with the XML support and use Strings directly (like the examples given in Servlet tutorials), but with XML you get static checking for XML syntax by the Scala compiler! The disadvantage is that it is bit slower (About 4x slower on a simple benchmark that I wrote).

This kind of down-to-basics approach is also being taken by the [Slinky] framework. But that is still a nascent project and heavily depends on the scalaz package, which is a little too academic and under-documented for me.

Rolling my own framework

Not finding anything that readily matched my needs, I just sub-classed javax.servlet.http.HttpServlet and went from there. It was totally straight forward; about 100 lines of code for the "framework" which includes "get" and "post" handlers, extraction of parameters and session data, along with a way to handle URLs with regex pattern matching.

You get the full advantage of a general purpose language at your disposal for the view layer. But that could also be a disadvantage for large projects, because the flexibility could snow-ball into complexity.

For smaller projects, it is a boon, because the number of people who would contribute to the project would be smaller and hence the problem is more managed. Also, it is quite easy to slap-on a file-based view layer with limited inline scripting (something like JSP or Lift's templates) on top of this basic layer when the project grows.


It is a good learning exercise to cook stuff on your own. And I am now more aware of the relative strengths of the currently available alternatives. In the future if my needs grow, I will be comfortable in upgrading my framework, or tailoring others to my needs.

Add a New Comment