Show HN: Miso – A Haskell implementation of Elm(github.com) |
Show HN: Miso – A Haskell implementation of Elm(github.com) |
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#.
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.
Having said that when I tried to build a simple Halogen project the build hung.
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.
Misco: Write Elm-like front-end applications in Haskell.
The question was:
> Why do you wrote this instead of just using Elm? Is GHCJS fast enough? Does it produces builds small enough?
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