I have been trying to port the formlets concept to the client side with a lot of success. I think. The applicative and monadic code of the MFlow widgets works almost unchanged when compiled to Javacript with the haste compiler.
I called it hplayground since it is more marketable than Haskell-js-reactive-widgets . And it seems to me something that convert the browser into a playground to essay different things. The DOM tree structure, the HTML formatting, the events, are not an impediment for making simple things simply. It helps making complicated things easy since all of them work in harmony.
The examples are alive here:
What i achieved? the possibility to create applications in the browser as fast as easy as console applications and have console, reactive, window-oriented and spreadsheet-like behaviours for free. The mix is a weird but powerful programming something. A kind of having your cake and eat it too.
The problem with the current haskell/elm reactive-declarative developments in the client side is as follows: They all create static layouts with holes that will be modified declaratively expressing reactive dependencies. The result is that page content can not be modified, except the holes.
I want everything, including the layout, to be modifiable by the events. and this means monadic code. And this means that the layout and the events must run across ifs, elses, case and branches of the code.
The hplayground idea is to use applicative code for static layouts but also monadic code for dynamic updates The events propagate downstream within the monadic code. Whenever that a widget raises an exception, the rest of the monadic computation is triggered, generating new rendering. The events, the computation, the HTML.DOM modifications of the layout follows the same natural and intuitive path within the monadic computation.
This is an static layout with to input boxes with a dynamic part at the end that show the results when the two input boxes validates:
Since Widget a is a instance of monoid as long as a is a Monoid, any number of them can be folded.
Graphics are possible also, no news here, since the canvas internal layout is managed by his own monad in Haste. And that is right. However if you look at the "function draw" example and the "gallery" example you can see that the canvas is erased and recreated when the input boxes or a timeout event arrives. The reactive effect of the function draw example is noteworthy.
One more example: The pascal triangle:
Things are not yet finished. I have to create an MFlow application for people to play with the idea. I have to upload the last version of the examples to the page
Where these examples can be seen in action
I have to manage mouse events. It probably will use the same semantics than the wtimeout call, used in the gallery example.
Finally, for the updates of non local elements of the layout that not follow the default downstream flow of a monadic computation (think for example on something like a spreadsheet) Some of them can be done using Haste.DOM primitives , but I have to create high level abstractions like the cell concept. But I have not finished it yet.
At this moment only text boxes and buttons work. I have to add the dropdowns option buttons and wlinks. so that full window like applications can be created. I just follow the path of higher resistance and leave the easy things for later.
An finally, some day I will take time to make my presentations, my examples and my texts more readable and more pretty and at least not as dyslexic as they are, but God did not called me to go this path. Too busy programming. Blogger conspirates against me, but I have no clue about what happens with the layout of this page.
To summarize, with little more effort that what you would employ in the creation of a console application and with the same structure, you can create a live dynamic application running in any browser.