A perennial problem with Web development is its complexity and the number of languages and technologies a developer must juggle to deploy even the simplest Web application. You need HTML and CSS for the UI, JavaScript for the client-side code, a server-side platform such as Java or PHP for the back-end logic, SQL to access the database, and potentially more.

What if all of that went away?

In recent weeks, I’ve been fascinated with Opa, a new language that aims to eliminate all of the convoluted code-wrangling from Web application development. With Opa, you don’t use one language to script your UI, another to code your business logic, and so on. Everything, from the client-facing code to the database access, is written in Opa.

Unlike with some rich Internet application (RIA) platforms, users don’t need a browser plug-in to use Opa applications. The parts of your Opa code that need to run in the client browser are automatically compiled into JavaScript.

Other parts of your code run on the server, as appropriate. Here, Opa is unusual in that it’s a truly all-in-one solution. Unlike most platforms, you don’t need to install and maintain a stand-alone Web server, database server, application server, and middleware layer to get going. The Opa platform provides everything, from the Web server to the database server to the client- and server-side frameworks.

As a result, Web applications built with Opa can be incredibly compact. There’s very little of the “glue code,” boilerplate, and drudge work that characterizes most Web platforms. The sample application is a distributed Web-based chat client that comprises just 27 lines of Opa code. A full description of how to develop and deploy Web applications in Opa would be too long to include here, but I encourage you to browse the copious documentation available online.

Does Opa have legs?
As clever as it is, however, I can see several challenges Opa faces if it hopes to gain wide acceptance. First, because it is a brand-new technology, the available talent pool for developing projects in Opa is very shallow. It’ll have to gain a lot more momentum before most development shops categorize it as anything other than experimental.

Second, Opa presents significant barriers to entry for developers. The Opa language is easy enough to learn, but the problem is that developers must learn it. Because it is an all-in-one solution, very little of a Web developer’s existing skill set is applicable to programming in Opa. There is an Opa way to access databases, an Opa way to handle network communication, an Opa way to display and format data, and so on. Developers must master all of these techniques to become effective in Opa — even if they’re thoroughly familiar with them on other platforms.

Third, doing things the Opa way means giving up some of what you can do today with existing Web technologies. For example, Opa’s generated client-side code isn’t as versatile as hand-coded JavaScript, and its hierarchical database lacks the full power and flexibility of a SQL-based database. Most significantly, you lose the ability to optimize your data access using stored procedures, triggers, and similar capabilities, which tend to be the key selling points of commercial relational database systems.

Fourth, Opa’s all-encompassing design means developers must rely on the Opa implementation for everything, which could end up being a significant barrier to new features. Seismic shifts in Web development techniques are not unheard of. Consider the rise of AJAX, which is now virtually ubiquitous in modern Web UIs. If a similar shift happens in the future, Opa developers could easily be left behind as they wait for the platform to adapt to the newest techniques.

Opa is published under the GNU Affero General Public License, and its source code is available on GitHub, so technically anyone can join in and contribute new features, bug fixes, and improvements. But here Opa’s design presents a problem, also. The Opa engine is written in OCaml, itself a relatively little-known programming language that combines functional, imperative, and object-oriented programming styles. In other words, most independent developers will have to learn yet another obscure language, in addition to Opa, just to contribute to the open source project.

Finding a niche
Opa is not the first language to face such challenges. In fact, in considering Opa’s design and goals, I’m reminded of nothing so much as the so-called fourth-generation languages (4GLs) that sprang up beginning in the 1970s. Like Opa, the 4GLs aimed to speed up the software development process, make programming more accessible to more people, and reduce the size of program source code for better maintainability. Those were laudable aims, particularly when the alternative was hammering out business logic in Cobol. As a 4GL for the Web, however, Opa’s greatest challenge may be it seeks to address a need that simply isn’t very urgent.

Even if traditional n-tier application development techniques can be cumbersome, they’re not particularly hard to understand, even for neophyte developers. Likewise, JavaScript may not be everybody’s favorite language, but it isn’t difficult to learn; Stanford University uses it as a teaching language for introductory computer science courses. Even DOM manipulation has become straightforward with the advent of libraries such as Dojo and jQuery. And JavaScript is becoming ubiquitous, even finding applications as a scripting language outside the browser. Thus, most programmers will continue to learn and apply traditional Web development tools and methods, even if they experiment with Opa.

Despite all of these criticisms, I do think Opa is worthy of attention. It could easily become a valuable tool for rapid prototyping, experimentation in education and the sciences, and even efficient deployment of in-house business applications. And it’s important if for no other reason than that it challenges the orthodoxy of Web development. As with any discipline, there’s more than one way to do things, which Web developers should be reminded of more often. Any technology that enables developers to conceptualize and deploy applications in new ways should be a welcome addition to the Web development toolbox — even if it’s not the one you reach for first.

Incidentally, if you’re interested in trying out Opa, there’s currently a contest under way to see who can come up with the most original and effective Web applications using the language. To win, you’ll have to be up and running by Oct. 17. If anything is a test of how quickly you can build and deploy applications in Opa, I reckon that’s it!


Related Posts:


Comments are closed.