lavadip

Web programming in Scala: Choosing a framework

Note: This is a rather old (but still relevant) article that has been ressurected from the archives.

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 are nothing to write about. 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) = {
     <html>
       <head> <title>{title}</title> </head>
       <body bgcolor="#c0c0ff">
         {node}
       </body>
     </html>
}
// Sample usage
def userAdd = {
    surroundWithStd (
       <div>
         <h1>User addition</h1>
         <form method="post">
           <label for="nameField">Name</label>
           <input type="text" name="nameField" />
           <input type="submit" value="Add" />
         </form>
       </div>,
       "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.

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.

Ofcourse, you could do away with the inline XML support and use Strings directly (like the examples given in Servlet tutorials). This is about 4x faster than inline XML (on a simple benchmark that I wrote). But by sticking with inline XML you get static checking for XML syntax by the Scala compiler!

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, as the problem is more managed and the advantages weigh over the problems. 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.

Conclusion

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 suit my needs.

blog comments powered by Disqus