Not really.
As far as I can remember I liked the ideas but found their execution to be a bit lacking, sometimes ad-hoc in their attribute DSL, focusing more on the show off to convince single page application proponents of the approach than on a clear conceptual model (which htmlact tries to detail in the manual here).
Two other things that come to mind are:
- AFAIR their examples relied a lot on unique
idattributes for targeting request results. Unless you find a principled and automated way to generate these that’s not compositional and brittle. InhtmlactI extended the CSS selector syntax to allow to address your ancestors (peace be upon them). That’s more compositional but now you become sensitive to structural changes in your markup – pick your poison[1]. - I’m no longer sure about that, i.e. don’t take my word for it, but I think their DSL allowed to spread the definition of an interaction among many elements which made it more difficult to understand what is happening. In
htmlactall attributes defining the effects of an interaction are always located on a single element, the element that performs the request.
Finally when things go wrong I prefer to have to understand 700 lines of ml rather than 2800 lines of JavaScript (note that they likely have better legacy browser support and more functionality).
In any case there’s a long list of todos in htmlact and it likely needs one or two more design rounds before getting to something decent – if that’s even remotely possible on the web.
Mind you I tried to use three letters once, but the whole experience turned out to be extremely unpleasant :–)
Using unique ids reifed in an OCaml EDSL could be a better idea. ↩︎