Show HN: Miso – A Haskell implementation of Elm | Hacker News Reader

Show HN: Miso – A Haskell implementation of Elm

github.com

114 pointsdmjio25 comments

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 did too, but I thought it was going to be a mail client (https://en.m.wikipedia.org/wiki/Elm_(email_client))

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.

Agreed, could have chosen a better title.

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

Couldn't agree more.

Purescript and Halogen would like to have a word.

Having said that when I tried to build a simple Halogen project the build hung.

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.

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.

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.

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

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.

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

He has a great intro blog post too http://blog.overminddl1.com/posts/bucklescript-tea-game-over...

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.

Are you thinking of Redux, the library commonly used with React which enforces unidirectional state management?

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.

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

The title should be:

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

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

A different account submitted the story yesterday. This submission is by an account that shares a similar name with the Github repository.

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

The previous submission is here: 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?

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

Reply on news.ycombinator.com