Ask HN: Functionnal programming for UI?

[yogsototh]

Hello,

I wanted to make a complete javascript web client. The standard usage with imperative language is to use the MVC pattern. I used object oriented programming but the javascript syntax for OOP was a really poor experience. I had the feeling that using a functionnal paradigm would had fitted better with js.

I know HN was done with Ark a functional programming language. So I wonder if an MVC pattern was done under the hood? May be there is a good recommendation or a known pattern that help making UI under a functional programming paradigm?

[demallien]

I'm not sure what your problem is with the "syntax for OOP". At any rate, I have just finished building an MVC framework for Javascript without any major difficulties. Perhaps you could share an example that has posed you problems?

One thing that I will say about functional programming and UIs is that they can be somewhat antithetical - to get good performance out of UIs, you often need to cache pre-computed results, which is just another way of saying that your code is going to have a boatload of state. Incidently, if anyone knows of a functional solution that overcomes this difficulty, I'd love to hear it.

[yogsototh → demallien]

There is no _major_ problem, but the syntax can be terrible. May be I'm wrong but, the main problem for me was to access the current instance of a class.

1st level : use this 2nd level : var self=this; then use self; 3rd level : var sefl=this; and pass self as parameter.

Typically, when a new view appear, I load dynamically the resources nee: other javascript files and an HTML template file. I use jquery to handle AJAX.

Here is some code:

    ConsumptionView.prototype.show = function(){
        var self=this;
        
        var files=[];
        var tests=[];

        files.push('/static/js/date.js');
        tests.push('Date.prototype.setISO8601');

        mainApplication.run_after_dependencies( files, tests,
                function() {
                    $('#content').load("/static/html/user_consumption.html",
                        function(){ self.htmlLoaded(self);});
                });
    }

the `run_after_dependencies` function will mostly do some getScript only if needed. The last function will do (mostly):

    $.getScript('/static/js/data.js', function() {
        $('#content').load("/static/html/user_consumption.html",
            function() { self.htmlLoaded(self);}
        );}
    );

But in the end, I _have_ to pass 'self' in parameter to 'htmlLoaded' function and I cannot use the 'var self=this;' at the top of the definition of the function html_loaded.

[demallien → yogsototh]

OK, you don't like what is happening at level 3, is that right? Well, I see only two possibilities - either your htmlLoaded function has different semantics for its this and the parameter self, or it doesn't need the parameter. In the first case, repetition is necessary, because you might want to do this:

  view.htmlLoaded(other_view);

in the second case the function should be more like:

  ConsumptionView.prototype.htmlLoaded = function()
  {
      this.doStuff();
  }

[timrobinson → demallien]

Functional reactive programming provides a decent abstraction for functional UIs: http://stackoverflow.com/questions/1028250/what-is-functiona...

My understanding is that FRP represents the state of the program as a function of a stream of events. Each time a new event comes in, information about the event is used to create a new state based on the current one. Ultimately the global state of the program gets mutated, but this fact can be abstracted away; program logic looks like: λ event oldState -> newState

[demallien → timrobinson]

Interesting, but I don't think it gets to the heart of what I'm trying to get at. Imagine that instead of drawing a box where the mouse cursor is, you want to draw 20 words of anti-aliased text. Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen. But that buffer is state. It needs to be updated to when the text is updated.

So maybe I could use FRP to automatically recalculate the buffer when the text changes. But nnow I point out that you can't just arbitrarily allocate a graphics buffer for each piece of text, it would take way too much memory. I could just allocate a buffer only when the buffer is actually on the screen, and not when it's clipped. But even just calculating if the object is on the screen can become very costly when you are working with complicated graphics geometries.

Anyway, I gave up doing it in a functional manner, and just embraced the inherent state-iness of UI work. But I'd love to learn if I've been doing it wrong!

(incidentally, Apple get's around this when working with UIs by 'binding' variables to graphical objects - if one changes, the other changes automatically - eg, moving a slider changes the variable representing the value of the slider. Changing the variable changes the slider on-screen). All done in Objective-C by making heavy use of forced setters/getters.

[timrobinson → demallien]

Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen

This sounds like an example of memoization. The buffer is allocated once, on demand, and presumably reallocated when the text changes. Mutable state is involved, but it's hidden inside your memoization function, which is typically provided by the language. You supply a function like: λ string -> GraphicsBuffer.

[jhuni]

Programming in a paradigm that your language is not made for is indeed a poor experience. JavaScript is not made for OOP or FP, it is made for prototype-based programming so if you want a good experience that is what you should use.

As for FP/MVC UI have you ever heard of tangible values? http://www.haskell.org/haskellwiki/TV