Haskell, XQuery, JavaScript or Opa for web development

Jul 8, 2012

This is a follow up on a previous post of mine, XQuery, Node.js and Opa – which is the “new Java” of web development?. So here comes the table…

Haskell XQuery JavaScript Opa
Purely functional as pure as it gets not so pure but mostly functional cumbersome to write functional code not pure but functional
Statically typed yes yes no yes
integrates well with a database with RDMSs (via HaskellDB) and with a native Haskell store called acid-state with XML-DBs with MongoDB or CouchDB with MongoDB or CouchDB
Web server good good, e.g. Sausalito or eXist Node.js e.g. Node.js
Web client (browser) experimental Haskell to JavaScript compilers experimental, see XQuery in the Browser great (native) good (compiles to JavaScript)
GUI code executed seamlessly on client and server no no yes, using Meteor or Derby yes, integrated
Templating system yes, e.g. HStringTemplate not that I know of yes, e.g. Handlebars yes
Parallelism and distribution wide range of facilities for parallelism, maybe less distribution on multiple servers? current implementations spawn a new process for each request, inside that no parallelism afaik requests handled by the Node.js event loop which is non-blocking but unfair and starving. Inside WebSockets can be used uses Node.js, but automates distribution

… and now some explanations. Keep in mind that these are my research notes, I’m no expert (yet ;)).

This started when I was thinking how nice a language Haskell was, purely functional, monads, lazy evaluation and a rich static type system. What more can you ask? Going from top to bottom in the table, unfortunately Haskell doesn’t integrate that well with NoSQL databases as XQuery and JavaScript do with XML databases and MongoDB respectively. When you have to use a different language to query your database than what you use for the application tier, you have an impedance mismatch: you have to convert all the data back and forth and have to think in different ways depending on what tier you’re on as well as having to decide what should be handled in what tier. A similar impedance mismatch arises when you have to use a different language on the client-side (i.e. the browser where we’re stuck with JavaScript) and on the server side. Ideally, you write your GUI code once and it is transparently executed either on the server (upon the initial page load) or on the client (upon further navigation by the user). To pull this off, it seems to help a lot to have a templating system which also separates presentation and computation/business logic. Finally, it would be nice if you could easily (and without introducing hard to find errors) parallelize your code to run on multiple cores of a machine as well as distribute it to run on a cloud. Maybe I’ll have to look at Clojure or Erlang for that as well.

Opa seems to do a lot of things right, the question is how it fares in practice and also how open its application stack really is. For Haskell, we’ll have to wait until it compiles properly to JavaScript, and I’ll have to look at whether there is a database that performs and integrates well with Haskell, otherwise it seems to rule (except that it’s hard to learn). XQuery seems well suited for large amounts of XML data and JavaScript is pretty easy to learn, so it might become the new (concurrent) PHP. So, we’ll see… ;)