5 ms·

Show HN: Miso – A Haskell implementation of Elm

114 points by dmjio 9y ago

fiatjaf 9y ago
You've submitted this yesterday. I upvoted you and asked a question. I was ignored.
- brudgers 9y ago
  A different account submitted the story yesterday. This submission is by an account that shares a similar name with the Github repository.
- dmjio 9y ago
  Ah, my bad, I wasn't aware someone else submitted it, what was the question? Would be happy to talk about it.
  - yorwba 9y ago
    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 9y ago
      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
bratsche 9y ago
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#.
- yangyang 9y ago
  I did too, but I thought it was going to be a mail client (https://en.m.wikipedia.org/wiki/Elm_(email_client) https://en.m.wikipedia.org/wiki/Elm_(email_client))
- jchw 9y ago
  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 9y ago
    Agreed, could have chosen a better title.
ivanbakel 9y ago
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.
- kornish 9y ago
  Are you thinking of Redux, the library commonly used with React which enforces unidirectional state management?
- ghthor 9y ago
  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.
- giesch 9y ago
  Redux was based on Elm, not the other way around.
wuschel 9y ago
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 9y ago
  This is fantastic feedback, better documentation is the next step so I'll be sure to include a comparison section between the two.
b123400 9y ago
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 9y ago
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 9y ago
  He has a great intro blog post too http://blog.overminddl1.com/posts/bucklescript-tea-game-overbots-pt1-setup/ http://blog.overminddl1.com/posts/bucklescript-tea-game-over...
Perceptes 9y ago
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.)
- dmjio 9y ago
  Couldn't agree more.
- quickthrower 9y ago
  Purescript and Halogen would like to have a word. Having said that when I tried to build a simple Halogen project the build hung.
- KurtMueller 9y ago
  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 9y ago
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 9y ago
  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.
anon335dtzbvc 9y ago
The title should be: Misco: Write Elm-like front-end applications in Haskell.

114 points by dmjio 9y ago

fiatjaf 9y ago

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

brudgers 9y ago
A different account submitted the story yesterday. This submission is by an account that shares a similar name with the Github repository.
dmjio 9y ago
Ah, my bad, I wasn't aware someone else submitted it, what was the question? Would be happy to talk about it.
- yorwba 9y ago
  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 9y ago
    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

bratsche 9y ago

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

yangyang 9y ago
I did too, but I thought it was going to be a mail client (https://en.m.wikipedia.org/wiki/Elm_(email_client) https://en.m.wikipedia.org/wiki/Elm_(email_client))
jchw 9y ago
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 9y ago
  Agreed, could have chosen a better title.

ivanbakel 9y ago

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.

kornish 9y ago
Are you thinking of Redux, the library commonly used with React which enforces unidirectional state management?
ghthor 9y ago
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.
giesch 9y ago
Redux was based on Elm, not the other way around.

wuschel 9y ago

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 9y ago
This is fantastic feedback, better documentation is the next step so I'll be sure to include a comparison section between the two.

b123400 9y ago

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 9y ago

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 9y ago
He has a great intro blog post too http://blog.overminddl1.com/posts/bucklescript-tea-game-overbots-pt1-setup/ http://blog.overminddl1.com/posts/bucklescript-tea-game-over...

Perceptes 9y ago

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

dmjio 9y ago
Couldn't agree more.
quickthrower 9y ago
Purescript and Halogen would like to have a word. Having said that when I tried to build a simple Halogen project the build hung.
KurtMueller 9y ago
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 9y ago

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 9y ago
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.

anon335dtzbvc 9y ago

The title should be: Misco: Write Elm-like front-end applications in Haskell.