
Show HN: Miso – A Haskell implementation of Elm - dmjio
https://github.com/dmjio/miso
======
bratsche
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#.

~~~
jchw
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.

~~~
dmjio
Agreed, could have chosen a better title.

------
Perceptes
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.)

~~~
KurtMueller
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.

------
beefsack
Very impressive, and as a developer who prefers using languages with strong
type systems, I'm particularly intrigued by efforts like this.

Most of the examples seem to contain 1.5MB of JS. My gut feel is that it isn't
terribly low or high for transpiled JS, but it is what it is.

I'd be interested to see how large it is compressed.

~~~
dmjio
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.

------
wuschel
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.

~~~
dmjio
This is fantastic feedback, better documentation is the next step so I'll be
sure to include a comparison section between the two.

------
b123400
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.

------
zem
along similar lines, here's an ocaml+bucklescript version of the elm
architecture: [https://github.com/OvermindDL1/bucklescript-
tea](https://github.com/OvermindDL1/bucklescript-tea)

~~~
ch4s3
He has a great intro blog post too
[http://blog.overminddl1.com/posts/bucklescript-tea-game-
over...](http://blog.overminddl1.com/posts/bucklescript-tea-game-overbots-
pt1-setup/)

------
ivanbakel
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.

~~~
giesch
Redux was based on Elm, not the other way around.

------
anon335dtzbvc
The title should be:

Misco: Write Elm-like front-end applications in Haskell.

------
fiatjaf
You've submitted this yesterday. I upvoted you and asked a question. I was
ignored.

~~~
dmjio
Ah, my bad, I wasn't aware someone else submitted it, what was the question?
Would be happy to talk about it.

~~~
yorwba
The previous submission is here:
[https://news.ycombinator.com/item?id=14682295](https://news.ycombinator.com/item?id=14682295)

The question was:

> Why do you wrote this instead of just using Elm? Is GHCJS fast enough? Does
> it produces builds small enough?

~~~
dmjio
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

