Programming Opa: Web development, reimagined

MLstate's Opa streamlines Web app development with a single language for client and server, but the bright promise is not without pitfalls

Page 4 of 4

Long live Opa
Currently, Opa runs on 64-bit x86 Linux systems; Windows and 32-bit versions are in the works. Build an Opa application today, and you could deploy it on just about any cloud provider that supports 64-bit Linux. You could, for example, host your Opa application on Amazon EC2. However, MLstate has partnered with DotCloud to provide specific Opa support. (Information is available at DotCloud's website.) Note that, at the time of this writing, the Opa service provided by DotCloud was considered to be in beta and did not support scaling.

Licensing of Opa is free until revenues from an Opa-based application reach $1 million. At that point, you must contact MLstate for pricing information.

Opa's documentation is still under construction. This makes learning the language particularly difficult, to say nothing of the work involved in finding your way through the functions of the runtime APIs. As an example, while working through the code snippets provided in the short tutorials sprinkled throughout the online manual, I discovered that there are at least three ways to define a function. One is straightforward and very C-like, but the others are more complex. I could find nothing in the documentation (at the time of this writing) that covers this topic, or even tells whether there is any advantage to defining a function one way rather than another.

Possibly Opa's greatest weakness is its lack of a robust IDE and, as a result, its lack of a good debugger. Because Opa's server code runs in OCaml, you can use OCaml facilities to debug server-side code. And given that Opa's client-side code is JavaScript, you could use, say, Firebug to debug that. But considering Opa's central promise is that you don't have to treat a Web application as a client/server creation, having to use separate debuggers for client code and server code feels like a violation. An Eclipse plug-in is available, but it's described as being in development. So, currently, the preferred technique for debugging your Opa application is by using the tried-and-true "debug-by-printf" method.

Opa's fundamental principle -- that building a Web application shouldn't require a developer to wrestle with multiple languages and technologies -- is a worthy goal that I hope MLstate ultimately achieves. Nevertheless, as worthy as that objective is, it demands that you swallow at least one bitter pill: You have to learn another programming language, and you have to hope that the effort you exert in freeing yourself from the tangle of different technologies will be worth it in the long run. In short, you have to hope that Opa will survive as a technology so that the effort you've expended on it isn't wasted. Here's hoping Opa succeeds.

Opa Web framework at a glance

 Pros Cons
MLstate Opa 1.0 S3.5
  • Powerful, terse, expressive language
  • All components packaged into a single executable
  • Support for MongoDB, with support for CouchDB underway
  • Free until you make $1 million in revenue
  • Incomplete documentation
  • Steep learning curve
  • Linux only (64-bit x86)
  • No IDE nor debugging facilities

This article, "Programming Opa: Web development, reimagined," originally appeared at Follow the latest news in programming at For the latest business technology news, follow on Twitter.

| 1 2 3 4 Page 4