Haskell as a JavaScript MVC framework | Hacker News Reader

Haskell as a JavaScript MVC framework

tonyday567.github.io

55 pointszygomega25 comments

I'm sure it's very clever, but the result (http://tonyday567.github.io/static/index-auto.html) didn't work for me in Chrome (but did in Firefox). I suppose the unfortunate problem with this is that delivering it with an issue like that would mean that approximately 99.99% of the web developers out there would have no idea how to fix it (the generated JS is utterly incomprehensible, of course).

That is something I was worried about, because afaik, ghcjs is still fairly experimental. But ability to use ghc's magic to produce javascript sounds aluring :-)

I think, that if you could integrate source-map capabilities (haven't tried http://hackage.haskell.org/package/sourcemap yet) it might make the debug process more bearable.

But if you would be looking for haskell-like-language with more comprehensible to-javascript output, http://www.purescript.org/ pleasantly suprised me (even though I had time to barely get past the hello world :-)

I wanted to use PureScript, but the language is too unstable for me. They're getting rid of lists and pattern matching for them in the next version, for example, because they made the mistake of using JS's Array type.

Can you list some ways/reasons Purescript is too unstable for you? Maybe a link to the JS Array type mistake? I've used purescript for some semi-serious stuff before and didn't notice anything unstable.

The next minor version of PureScript is changing everything. That's scary.

s/minor/major

Good article, I really like the insight of how sum types can be used in MVC, and how the OO community is oblivious of this.

Nice short read.

I'm a big fan of static typing, including sum types. But can someone explain to me what's so great here?

The highlight of the article is having a unique Action sum type instead of a myriad of separate functions. But the action still has to be processed by a myriad of separate equations (is that the correct Haskell term? Not familiar with the language):

    apply ClearCompleted tds = over todosItems (Map.filter (\x -> view itemStatus x /= Completed)) tds
    apply (DeleteItem x) tds = over todosItems (Map.delete x) tds
    apply (EditItem x) tds = set todosEditing (Just x) tds
    ...

"Only one of the 68 frameworks defined an Action" is probably because it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

If actions need to "be serialized, recorded for later analytics, and generated automatically" then it makes much more sense. But this is a TODO sample app. YAGNI.

And if we really need it, it's not like JS cannot do it:

    function apply(action, todos) {
        switch (action.type) {
            case 'ClearCompleted':
                return todos.filter(todo => !todo.completed);
            case 'DeleteItem':
                return todos.filter(todo => todo !== action.todo);
            ...
        }
    }

The above has probably been done a billion times in one form or another. Of course it's not safe from typos in the case strings or missing cases, but that's a broader issue with JS in general, not specifically related to sum types.

I'm not trying to shoot down Haskell here, I really wish someone will point to something I'm missing and make it click. But right now it just looks like over-engineering that JS could do but chooses not to.

(Regarding footnote #4: Swift also has sum types and is fairly popular.)

You're not missing anything. What you and the author are describing (in terms of pattern/architecture) has existed for quite a while but was widely popularized recently by Facebook's [Flux](https://facebook.github.io/flux). The author is either naive towards current state of the JavaScript landscape or their just being arrogant about what is actually unique to 'functional' programming.

Yep, was thinking the same exact thing when I saw "actions".

This article doesn't really do justice to Haskell's type system, but the main benefit I achieve is that with a properly defined type, it is often impossible to put the internal state of the program in a inconsistent state, eliminating a large class of bugs and crashes.

Really, the author is in favour of polynomial types (sums of products); the emphasis on sums is probably because tuples/records/arrays/etc. are already quite well known.

To see the distinction, notice that many Actions have some associated data:

    data Action a
      = ClearCompleted
      | DeleteItem ItemId
      | EditItem ItemId
      | EditItemCancel ItemId
      | EditItemDone ItemId a
      | Filter (Maybe ItemStatus)
      | NewItem a
      | NoAction
      | Refresh
      | Toggle ItemId
      | ToggleAll

In your analogy, the `action` value is actually quite complicated: it's an object (record) containing a field called "type" containing a string; if the "type" field contains the string "DeleteItem" then the action object also contains a "todo" field, containing an item ID; if the "type" field contains the string "EditItem" then the action object also contains a "todo" field, containing an item ID; and so on.

This is known as a "dependent record", and requires a much more elaborate type system than polymonial types. In fact, without careful consideration, dependent type checking can end up being undecidable!

Compare this to the polynomial type, where the parameters (item IDs, etc.) are right there in the value. We can never have an Action without the corresponding parameters (if we try, we'll end up with a function rather than an Action, thanks to Currying). We can never switch the type of an action while forgetting to change the parameters; etc. Plus, of course, we've denoted a finite set of actions, rather than relying on strings (AKA "stringly typed" programming).

Another point to note:

> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

Of course it would be simpler, but the entire point of the exercise is to use MVC to separate concerns, even though it's clearly overkill. If we're going to do MVC anyway, then the Action type provides a very simple interface between the Controller and the Model: the Controller just spits out an Action, the Model just receives an Action; no need for any further coordination. Plus, it's all really easy to reason about and type check.

> it's simpler to directly call the right function, rather than over-engineering things with a short-lived intermediary representation.

That intermediary representation can enforce that your input is valid. Then you can create functions based on that intermediary representation and act as if your data is valid because it is.

The intermediary representation can also ensure you cover all cases if your states are encoded with sum/product types thanks to exhaustiveness checking in supported languages.

> I'm not trying to shoot down Haskell here, I really wish someone will point to something I'm missing and make it click. But right now it just looks like over-engineering that JS could do but chooses not to.

JS can't turn runtime errors into compile time errors because it doesn't have a compiler or a powerful type system. In fact it has a very weak/dynamic type system.

It's about encoding the specific problem in the safest way possible. Typos and missing cases represent a very large set of trivial bugs which crop up in many situations like teams, changing requirements, scale, and reuse. The JS function will continually suffer from all of these and your apply function is oversimplified solution. If the bug can be detected and encoded by the computer, why not utilize that?

Yikes, 1,670KB for generated javascript alone, that's kind of a deal breaker.

GHCJS has a ways to go methinks. Js_of_ocaml and Scala.js are far better suited for production use today as the type safety "tax" is much smaller (i.e. binary is at most 1/4 the size for equivalent functionality).

EDIT:

didn't realize you cannot yet call into Haskell from GHCJS, and even Haskell to GHCJS requires going through FFI[1]

Meh, might as well use Fay or Haste if that's the caste.

[1] http://stackoverflow.com/questions/29967135/how-to-call-hask...

I quite like Haste for Haskell to JS compilation. Its output isn't too bloated.

Purescript (while not quite Haskell) also has very small output and is strict by default. There's also the very fun, informative, and productive "Purescript By Example"[0] book.

0: https://leanpub.com/purescript/read

Github link is broken .org instead of .com https://github.com/tonyday567/mvc-todo

I did not even find the GitHub link... This brings you straight to the meat of the project:

https://github.com/tonyday567/mvc-todo/tree/master/library/T...

And the actual Action sumtype is here:

https://github.com/tonyday567/mvc-todo/blob/cb4bbb613aa31ba6...

"It’s going to become much harder for haskell to avoid success"

I have 100% faith in the Haskell community's ability to keep doing what they've been doing for years. ;)

I start to like Haskell and would enjoy learning to use it for the Web, but look at the size of it:

http://i.imgur.com/kPHl4L7.png

7834KB is way too large for just that, I'm afraid.

I've 120Mbit/s, that's why it still loads fast, but I remember how slow, but fascinating surfing with 56K modem was.

I've explored ghcjs. I had a reasonable react based site down to ~400k after dead code removal and minification. Still biggish, but not multi-megabyte.

The raw unoptimized code was in the several megabyte range though.

I think it would be worth sharing that on a blog post submitted to HN. Sounds like a lot of work, maybe there are ways to automate that with a shell script or a Haskell program. 400KB is absolutely okay I think.

I agree, that would be awesome to study/emulate. Possibly use some of the techniques to make GHCJS programs smaller.

Reply on news.ycombinator.com