(Actually, calling something $Foo$ on $Bar$ puts me off. It suggests the developers are not starting out looking at what makes the base language unique in its own right, and will likely make poor design choices from wanting to mimic something from a different, incompatible, realm.)
I'm pretty sure they're referencing the Old Spice commercials and the similarity to 'Ruby on Rails' is only coincidental. The framework itself looks nothing like Rails.
I haven't actually seen those commercials. The name is a pun of "Ruby on Rails".
I intended the name to draw a contrast, not to suggest a similarity! The metaphor of 'rails' is that ruby development is sped up by being kept on a particular track ('convention over configuration') - there is also a connotation of industrial strength, power, etc. A person on a horse calls to mind the opposite characteristics: exploratory, unconstrained, human.
Does this support templating, data models, etc? How far removed is this from a "traditional" MVC web framework and how can on-a-horse be applied in real business? Does it have built-in support for ajax responses, dynamic partial rendering etc?
I'm ok with proof of concept sort of things - everything has to start somewhere. However, I think that having an idea of what it'll eventually be good at helps. Haskell seems to be fairly performant... what else? Concise? I suppose, although I can't read it enough to tell what it's even doing.
The following is my synthesis of current trends; I do not necessarily believe it entirely and I'm not completely advocating it.
One of the recent focuses in the functional world has been composition. Object orientation promised us the ability to have components that could be easily strung together to make programs. It has basically failed. We have OO frameworks and libraries, and we have little tiny OO containers, but the levels inbetween have not manifested the way they were "supposed" to. And even to the extent that libraries and frameworks have succeeded, they often don't play well together. In particular, if you use my preferred definition of "framework" vs. "library", which is that the framework calls you and you call the library, it verges on the impossible to use two frameworks simultaneously. That is to say, you can not compose two of them together.
If you say "Why would you want to do that?", the answer is really simple: You want features from both. You're probably so used to the idea that this is impossible that you've completely internalized it and can't hardly even think about why you might want to do that without rebelling at the thought of how obviously impossible that would be. But there's no fundamental reason why this should be.
So, the Haskell functional community has been kicking around ideas about how to provide truly compositional components. It is absolutely true that there are libraries and frameworks already in existence, but they often don't compose well. The parts are very large and they often are built on assumptions that either can't be satisfied simultaneously, or can only be satisfied with great effort. This looks like one person's stab at solving the problem.
If it sounds like I'm handwaving, to some extent I am. Functional-style composition is hard to wrap your head around if you've been programming in OO for long enough that you think in native OO, and I am not aware of generally accepted terminology for this. It goes both down to a much finer granularity than you are used to in OO (example: a monad is actually this little three-line snippet thing that has been refactored out of all of the implementations of monads, and it's a refactoring at a level so weird and subtle it is weird to come at it if you're not used to it), and ideally up to that middle level that OO is missing. It seems to be a relatively new focus in the community. The goal they are shooting for is to cover that middle ground a lot more richly than OO frameworks have. And again, I emphasize, it is not that OO frameworks like Django have no composition; it is that it is limited in ways that are hard to even see if you've adjusted too much to the OO ways of thought. I also want to highlight that this is a goal; there's no guarantee this is actually possible on the web, but there are some aspects of Haskell that may make it easier to do in that language that any other, in particular the rigid focus on purity everywhere. (On the other hand, getting the strong types to play together well can be a challenge too; with such strong typing as there is in Haskell you have to get the types exactly right or, virtually by definition of "exactly right", you will be mandating wrong behavior or ban safe behavior, with the mandates and bans being much stronger than in languages with weaker type systems.)
On the web, we have special challenges in that an "atomic element" of a web page may consist of HTML that is generated based on a call from a database and a bit of this file over here, depend on a CSS rule being in the page, require certain Javascript which may itself be generated from some data pulled from some other IO source, may require additional images, and so on and so on. Moreover, for performance reasons you need to be able to do things like control where the <script> tags appear exactly, you don't want to include 40 CSS files, one for each of the 40 individual components that a page happens to have. And the community would like to make it so you have compile-time assurances that the website has all necessary resources in it, so for instance you can use strong typing to "assert" that the CSS a given component requires is statically verified to exist. For one small bit of this, Google for "type-safe url handling" for some discussion about how to make one small part of this process type safe. Oh, and when all is said and done, it would be nice if the types were still humanly-comprehensible. :) Working all of this to some sort of compositional framework is going to be a challenge.
So, if you go back and look at the page having gotten through that wall of text, I think it might help you work out what the author thinks is interesting about an otherwise obviously-trivial "web framework". The "more complex example" is the meat of the idea, in which some simple components are wired together compositionally to produce a hierarchal expression manipulator, which would take much more code in most other frameworks. (Though of course being perfectly possible.) Of course by no means is this a manifestation of everything I said above, I see no work on the things being composed with their JS or CSS resources, and so on. This is more like a first step towards what I described in the previous paragraph, not the completion by any means.
I don't know that anybody has spelled all these ideas at once; like I said, this is my synthesis and you are getting it through my biases. But I thought it might sort of answer your question.
You put into words what I couldn't put my finger on about functional programming. With my introduction to ruby and prototype (over C), I'm finally understanding the mathematical-monadic-compositional aspect to functional programming that makes it so powerful.
Its not even what you do with it - its the emergent behavior that makes it so compelling.
Basically what I think you've summed up (but in less words) is that this is a proof-of-concept or a building-block for much more sophisticated examples, showing real approaches of building complex and powerful (especially the UI based expression analyzer) web applications with amazingly little code.
Haskell web stuff in general has a flavor: performance (lots of concurrency and multicore stuff on top of epoll) and component compositionality.
------
As an aside, with the emerging realization that threads and events are linked, its interesting to note that GHC these days presents a thread and event API implemented in terms of epoll/kqueue. Threads and events are unified in GHC, finally.
Wow, they really are trying to imitate Rails.