dmjio
Re:Haskell Miso v1.9.0 Released
on Thursday April 02, 2026 @02:19PM (#47618152)
Added React-style web components.
Re:Ask HN: What Are You Working On? (Nov 2025)
on Monday November 10, 2025 @01:51PM (#45879367)
Yes, miso uses the JS backend in GHC, and mobile phones have embedded JS interpreters (e.g. JavaScript Core). These interpreters can access native libraries to draw native views, or access native device APIs.
Projects like lynx and react-native automate this process using something akin to node-gyp, exposing kotlin / swift libraries via C ABI w/ a JS API. Miso accesses the kotlin / swift native modules by FFI'ing into the JS that exposes them.
The JS doesn't get compiled, but on Android it does get JIT'd. So it's "native" in the sense that the views drawn are native (not WebViews), and the device APIs are native, but not "native" in the sense that it's compiled.
Re:Ask HN: What Are You Working On? (Nov 2025)
on Monday November 10, 2025 @02:16AM (#45873288)
https://github.com/dmjio/miso-lynx
Building native applications for iOS, Android and Huawei devices in Haskell.
Re:GHC now runs in the browser
on Saturday November 01, 2025 @10:39PM (#45787458)
Yes we do.
Re:Ask HN: What are you working on? (September 2025)
on Tuesday September 30, 2025 @06:59AM (#45424033)
I'm working on miso-lynx
https://github.com/haskell-miso/miso-lynx
It's a way to build truly native iOS, Android and HarmonyOS applications in Haskell using https://lynxjs.org and https://github.com/dmjio/miso, it uses a similar approach to react-native.
Re:miso-lynx - A Haskell mobile framework
on Wednesday July 09, 2025 @08:02PM (#44515939)
This project is an integration between LynxJS.org and the Haskell miso web framework.
miso-lynx - A Haskell mobile framework
Re:JavaScript hydration is a workaround, not a solution
on Thursday September 01, 2022 @02:51PM (#32681192)
Miso has hydration w/ a global event event handler.
Re:Why I’m Leaving Elm
on Friday April 10, 2020 @01:57PM (#22835533)
Haskell will accept you !
Show HN: ArrayFire Haskell
Re:Client-side web programming in Haskell: A retrospective
on Monday October 21, 2019 @10:31AM (#21312677)
Would you be able to share more details as to what caused this bad experience? My experience with GHCJS on a big project has been the opposite.
Re:Client-side web programming in Haskell: A retrospective
on Monday October 21, 2019 @10:16AM (#21312484)
There is a company that has a 400 module miso application and the bundle size is not an issue (https://www.polimorphic.com). After closure compilation GZIP'ing, pre-rendering and caching of the JS, it's a one-time cost, and is negligible due to pre-rendering. We build websites for users, who care only about experience, not about how large the payload is. Payload only matters insomuch as it adversely affects user experience. This argument is strictly a developer concern and is in no way correlated with end-user feedback. There are many <1MB js payload size websites with 0 users.
Re:Client-side web programming in Haskell: A retrospective
on Monday October 21, 2019 @06:36AM (#21310736)
This post dismisses Elm on the basis of lack of typeclasses, but fails to mention miso (https://haskell-miso.org), that includes typeclasses. Miso is Elm-as-an-embedded-DSL written as a Haskell library for GHCJS that allows one to share types on the front and backend, take advantage of the entire Haskell ecosystem and has experienced commercial use.
Re:Reflecting on Haskell in 2017
on Monday December 04, 2017 @12:22PM (#15845538)
A few companies have used this (https://haskell-miso.org/) to make useful software w/ Haskell.
Re:Ask HN: Projects that don't make you money but you're doing it out ...
on Friday August 11, 2017 @01:02AM (#14986687)
Rewriting Elm in Haskell.
[0] Project Homepage: https://haskell-miso.org
[1] Github: https://github.com/haskell-miso/miso
Re:Elm in Production: 25K Lines Later
on Monday July 31, 2017 @03:46AM (#14890161)
If decoding json in Elm is considered hard, I'd recommend checking out miso (https://github.com/dmjio/miso), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses.
https://github.com/dmjio/miso/blob/master/examples/xhr/Main....
Re:Elm in Production: 25K Lines Later
on Monday July 31, 2017 @03:31AM (#14890114)
If you want a powerful type system (i.e. Haskell), but the benefits of Elm, Miso is a project that implements the Elm Architecture in Haskell. It obviously has typeclasses, and can encode / decode JSON on the frontend using GHC.Generics quite well. https://github.com/dmjio/miso
Re:Ask HN: HNers who got their “Show HNs” on homepage, how is your sit...
on Monday July 24, 2017 @01:41PM (#14840746)
You do excellent work sir. Use bulma /a lot/.
Re:Ask HN: HNers who got their “Show HNs” on homepage, how is your sit...
on Monday July 24, 2017 @01:00PM (#14840225)
Project: https://haskell-miso.org, https://github.com/dmjio/miso
Synopsis: Elm arch. in Haskell, but supports isomorphic js
Show HN link: https://news.ycombinator.com/item?id=14685677
Status: Still kickin', ~17k views, top 15 repo globally on GH (for a day)
Re:Show HN: Miso – A Haskell implementation of Elm
on Tuesday July 04, 2017 @04:19AM (#14694372)
Agreed, could have chosen a better title.
Re:Show HN: Miso – A Haskell implementation of Elm
on Tuesday July 04, 2017 @01:33AM (#14693753)
Couldn't agree more.
Re:Show HN: Miso – A Haskell implementation of Elm
on Tuesday July 04, 2017 @01:26AM (#14693717)
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.
Re:Show HN: Miso – A Haskell implementation of Elm
on Tuesday July 04, 2017 @01:20AM (#14693692)
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
Re:Show HN: Miso – A Haskell implementation of Elm
on Monday July 03, 2017 @04:16PM (#14691065)
This is fantastic feedback, better documentation is the next step so I'll be sure to include a comparison section between the two.
Re:Show HN: Miso – A Haskell implementation of Elm
on Monday July 03, 2017 @01:10PM (#14689806)
Ah, my bad, I wasn't aware someone else submitted it, what was the question? Would be happy to talk about it.