Web applications are nice. They’re useful, they’re cross-platform, users need no installation, no upgrades, no maintenance, not even the computing or storage power to which they are used. As weird as it may sound, I’ve even seen announcements for web applications supposed to run your games on distant high-end computers so that you can actually play on low-end computers. Go web application!

Of course, there are a few downsides to web applications. Firstly, they require a web connexion. Secondly, they are largely composed of plumbing. Finally, ensuring their security is a constant fight.

How many pipes do you need?

If you have ever developed a web application, you know what I mean by plumbing: just writing an online TODO list — the equivalent of maybe twenty minutes of work in Visual Basic, in Python, Java or Objective-C — requires mixing an insane amount of languages, to define your user interface (HTML, JavaScript, CSS), to define your storage (DDL, DML, DCL, plus possibly an ORM language), to get your server and your client to communicate (XML, more JavaScript, PHP or one of its competitors, as well as some HTTP and a little MIME configuration), to launch your application (whichever configuration languages are used by your server). Of course, if your application is a bit more complex and requires something like compatibility with smartphones, or like distant storage, or distributed computing, or backups, or modularity (in the world of the web, it’s called “web services”)… well, you will probably require a few additional languages.

All of this is just plumbing. Only once you have written it can you concentrate on the core of the application. And once the application is written, the pain is just starting, because chances are that your application can be attacked by hijacking the link between your user interface and the core (cross-site scripting) or between the core and the storage (SQL injection) or by keeping the user interface and replacing the application core (man-in-the-middle attacks) or by replacing the user interface by a malicious client or by taking the place of a currently connected user to steal some of its credentials (rebinding) or by taking advantage of low-level bugs (buffer over/underflows), etc.

None of this is a show-stopper, of course — just take a look at the web and you will see thousands of web applications. Just like the complexity of Software Development Kits in the early days of Windows, MacOS or X didn’t stop adventurous hackers from developing desktop applications. But of course, if twenty-five years of desktop application development have taught us one thing, it is that the life of developers can be made easier. Nowadays, a few generations of SDKs later, Windows developers have .Net, C# and Visual Studio, Macintosh developers have Cocoa, Objective-C and XCode, while X-based developers have the libraries of Gnome/KDE, Python and a variety of programming environments. The growing popularity (and libraries) of Haskell, F#, OCaml, Scala and other functional programming languages could mean that one of the next generations of SDKs will increase safety and security.

The web hasn’t quite reached that stage yet. Even the state-of-the-art in web frameworks only provides features slightly more advanced than early Windows/Mac/X SDKs: low-level bindings for low-level mechanisms, designed to ensure low-level properties. Or, rephrased differently, in the current state of web development, GMail, Google Maps or Facebook are still considered complicated applications, although they are conceptually quite simple and should therefore be equally simple to implement.

We can do better. How? By removing the need for plumbing. By providing automated mechanisms for ensuring high-level security properties. By providing language support for common patterns.

Enter OPA

Let me introduce OPA. OPA, or One Pot Application, is a complete development platform for web applications and web services. Development in OPA requires no plumbing. Applications developed with OPA are automatically checked for safety and security before they are executed. Applications developed with OPA are automatically (and provably) immune to cross-site scripting, to SQL injections and to most existing forms of attacks. And OPA provides language support for storage, communication between client and server (Ajax and Comet), concurrency, distribution, mobility, etc.

With OPA, we intend to skip several generations of SDKs and provide right now a high-level and modern programming platform. OPA has been 6 years in the making: 4 years of sketches, mockups and prototypes as part of academic research projects and 2 years of actual implementation at MLstate. A few days ago, OPA has officially entered demonstrable status. Not quite ready for prime time, but definitely usable for development. Do you want to write an online note-taking application? That’s about 20 lines of code, from scratch. A minimal chat? About 30 lines. A multi-channel, distributed chat? About 80 lines. A minesweeper? About 100. We’re using it to develop utilities, content management systems, tools for administrations and games.

Pre-alpha builds of OPA have been distributed to selected partners. A public version will be made available within a few weeks, as well as commercial applications developed with OPA. In the meantime, we are busy improving the syntax, completing the standard library, making error messages intelligible, fixing the bugs and extending the range of safety and security checks.

Interested? Well, few details are public at this time. However, you can take a look at a video recorded during ICFP presenting OPA and MLstate.

Stay tuned.