Haskell, XQuery, JavaScript or Opa for web development
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… ;)