I misunderstood the title at first. I thought this was a rewrite of the Elm compiler in Haskell. This confused me because I was pretty sure that Elm was already written in Haskell.
For anyone else who was confused like I was: this is more like a new frontend framework to implement the Elm architecture but in Haskell. Kind of the way Fable.io has a framework called Elmish, but you're writing in F#.
I am guessing the title should be more like "An implementation of Elm Architecture for Haskell." Even then, it kind of appears to be much more than that based on a cursory glance.
This honestly makes more sense to me than Elm itself. I don't see the reason to make Elm a separate language. It's the architecture that's important (given the type system of the language you choose doesn't suck, which is certainly true for Haskell.)
I like Elm and see advantages for it being separated from Haskell for a couple of reasons:
1) The Elm language is tightly curated. It features the most important parts of Haskell/OCaml for frontend web apps and decreases the surface area of knowledge needed to use it.
Obviously, this point is debatable and has been heavily debated in the Elm community.
2) In Elm, there is only way one to create a frontend web app. When new developers come on to a project, they need to mainly learn only the business logic of your app. When you want help from the online Elm community, they already know the workflow of the app.
3) It's a gateway drug for Haskell/OCaml. I think any rise in Elm's popularity can only help languages like Haskell & OCaml.
Why thank you kind sir :) Using advanced optimizations with google's closure-compiler, the todo-mvc example can get down to 500kb. Compressed it might even be smaller. This is why having the "isomorphic" part is important. This way the user will see content immediately while the app bootstraps in the background and sets up event delegation. Then events will get routed through the vdom to pure haskell functions and the app is responsive again.
I would love to see a small tutorial for package, perhaps even explaining some concept basics, and differences to Elm when working with it. Just dabbling in Haskell a bit (for fun, working through Haskell from first principles). Better a headache from reading a book than a headache installing npm packages on Linux.
I wonder how does it compare with Purescript + Pux. My experience with Pux has been pretty good. As a beginner, I find it more comfortable when the FFI is thin, the compiled JS is kind of readable, so in case if I am stuck, I can still go back to my familiar Javascript.
It will be interesting to see if the push to state-based design on the web really sticks. The JS library I forget the name of seems to have made it pretty popular, but projects like Elm and this will be the proof of its success.
I'm currently in the process of teaching my colleagues the joys of state based design. We're using redux and they'll commonly do something and I'll start my critique with, "Well in Elm I would have to do this because I can only communicate with the View using state changes." It's been a long road, but I think I'm starting to win over some support.
The choice of using Haskell was due primarily to 3 things.
1) Code reuse - The ability to share types on both client and server.
2) Hackage - by using Haskell you have access to 90% of Hackage on the frontend (this means nice lens and json libraries).
3) Types - Haskell's type system can express higher-kinded and poly-kinded types (something which Elm cannot afaik), this gives the user flexibility, expressivity and safety.
The code is quite performant, but for the fast stuff miso FFIs into hand-written js.
In regards to output size, the generated js can be very large. But, the generated code is in a state where it can use the closure compiler's ADVANCED optimizations. That combined with caching the rts.js and gzipping, you can probably get down to a few hundred kbs (which is large by a lot of people's standards), but workable
For anyone else who was confused like I was: this is more like a new frontend framework to implement the Elm architecture but in Haskell. Kind of the way Fable.io has a framework called Elmish, but you're writing in F#.