It’s time for Haskell in the Web browser.
JavaScript has been around for over a decade now. During that time, we’ve seen it implemented by every major browser vendor, and thus we’ve seen it become widely used by many Web sites. We’ve even seen JavaScript used in non-Web applications and uses.
But JavaScript has some pretty serious drawbacks. The performance of the various JavaScript interpreters embedded in the popular Web browsers has always been less than ideal. And being interpreted, it often becomes more difficult to detect syntax errors and other common mistakes. Worse yet, being weakly typed opens JavaScript scripts up to a whole host of type-related problems.
There are programs available to help with the development of JavaScript scripts. JSLint analyzes JavaScript code, looking for a variety of problems. A JavaScript debugger, such as Venkman, is also essential. But even these tools do not catch many serious problems.
As more complex Web applications are developed using JavaScript, we’ve started to see certain limitations being hit. One such limitation is the maintenance of a sufficiently high level of quality. This is not only in terms of correctness, but also in performance and portability. The very nature of JavaScript makes quality control a tedious task.
It may be time for us to look beyond JavaScript, to technologies that offer the capabilities needed for larger-scale software development. One essential feature is strong typing. Ideally, this typechecking can be done statically (ie. before the code is executed). Type-related errors caught before an application is executed leads to the developer addressing them, rather than a bewildered user encountering a confusing error message at runtime, typically interrupting (if not losing outright) what they were working on.
Strong, static typing has additional benefits, especially when it comes to optimizations. The more restrictive semantics allow the optimizers within compilers and interpreters to make assumptions and decisions that could not otherwise be made. This in turn often allows for greater optimization techniques to be applied to the code, improving runtime performance and decreasing code size.
So instead of looking at a language like JavaScript, we should probably be looking more towards a language like Standard ML or Haskell. I think Haskell would be an optimal choice. It offers many of the high level constructs of JavaScript, but it also addresses many of the aforementioned problems. What we lose relative to JavaScript is the ability to use techniques that lead to poor-quality, buggy code. But furthermore, we gain a language that promotes quality software through strong, static typing. Beyond that, Haskell has many advanced features, including pattern matching and lazy evaluation, that we really don’t find offered by JavaScript.
Haskell has even more going for it. Another major benefit is the availability of several interactive environments and interpreters. GHCi, for instance, is actively maintained, and is of a very high quality. There is also Hugs 98, which is a rather complete implementation of Haskell 98.
The purely functional nature of Haskell will become more and more important as consumer PCs begin to offer four to eight (or more) cores per CPU. Haskell can allow for the safe, automatic parallelization of code to a far greater extent than JavaScript ever could. We will need to take advantage of such features if we will want our Web applications, or even our applications in general, to effectively use the PCs of the near future.
So what we need to see is a Haskell implementation embedded within a major browser, and extended to offer DOM integration. This would allow for developers to use it instead of using JavaScript. The very nature of Haskell would allow for the development of complex, high-quality Web applications. With such Web applications becoming larger and more essential each day, we need a much more significant focus on quality and performance. Haskell will allow us to achieve this, while JavaScript will not.
January 27th, 2008 at 1:38 am
To me, the biggest problem with JavaScript is the lack of real security model. Not that I love Java, due to it’s often poor performance, but it does have a good security model. What does Haskell offer in terms of a security model?
January 27th, 2008 at 5:54 pm
Steve, languages themselves lack security models; the Java model is built into the runtime.
Haskell is a purely functional language in which all side-effectful operations including network and disk access take place outside of the language itself, but are presented to Haskell through a special construct called a monad, which (among other things) allows you to sequence operations through a form of function composition.
Given that Haskell is based upon the lambda calculus and (as shown by Jonathan Rees with Scheme) it’s possible to build a security kernel with lambda calculus by controlling which functions or procedures are shared through environments, it shouldn’t be too hard to construct such a kernel for mobile Haskell code by having it run in a special environment where only safe operations are provided — for example, by providing a special version of the IO monad.
Of course, it’s possible to commit DoS attacks with even pure functional code by constructing enough objects to chew up all available memory. Preventing that from happening is a responsibility of the runtime, as with Java.
January 28th, 2008 at 11:35 am
I don’t think static typing is that much required for software quality. Look at Erlang. It’s not statically typed, but they seem to have the most reliable software on earth.
And I don’t know if we really need strong typing on the client side for webapps. I mean, it’s a lot about manipulating the DOM tree, i.e. data the compiler does not understand anyway.
As for portability, it is not a language issue. Let every web browser editor make his own haskell interpretor and you won’t find it that reliable anymore…
Finally, performance : have a look at common lisp or Lua. You’ll see bad performance is not linked to dynamic typing. Sure, they’re not as fast as light, but that’s enough for client-side webapps I guess.
Yes, Haskell is a great language, and developping client-side javascript is a painful experience. But I’m not sure we’ll see Haskell in firefox very soon. I won’t hold my breath here.
February 5th, 2008 at 9:55 pm
Something has been done already to bring Haskell into a web browser, do the DOM integration, etc. See the link below:
http://haskell.org/haskellwiki/Yhc/Javascript
This is a work in progress though and far from being final, but many of the thoughts expressed in the original post slowly come true.
February 12th, 2008 at 2:58 pm
I’ve been working on GHC backend for JavaScript, you should be interested:
http://vir.mskhug.ru/
And as a Yhc backend it is a work in progress, it is in deep alpha stage now.