{"slug": "miso-1-13-release", "title": "Miso-1.13 release", "summary": "The Haskell web framework Miso released version 1.13, introducing a global context mechanism that shares data across all components via an IORef, and new -faeson and -ftext flags that polyfill Miso.JSON as Data.Aeson and force MisoString to Text on the client. Developer dmjio also announced an experimental integration with xyflow/system, creating a miso-flow library for node-based UIs, with example code and haddocks available on GitHub.", "body_md": "[dmjio](https://discourse.haskell.org/u/dmjio)\n1\n \n27 Likes\n\n \nThis new avatar of miso is simply marvellous to look at.\n\nI am not a frontend developer (tried my hand at elm and enjoyed it, but haskell I enjoy more)\n\nthis has me intriguiged enough to try one more time .. this time with miso\n\nA question  though.. what’s the limitation here?\n\nCan we do something like what reactflow allows for react.. ?\n\n \n2 Likes\n\n \n[dmjio](https://discourse.haskell.org/u/dmjio)\n3\n \nthank you  \n\nIn theory we should be able to make a `miso-flow` version, `xyflow` has a framework agnostic core called `xyflow/system` that we could wire up to miso’s virtual DOM nodes using `onCreatedWith` lifecycle hooks. I might give that a try, others have asked about that as well.\n\n \n1 Like\n\n \n[dmjio](https://discourse.haskell.org/u/dmjio)\n4\n \nDear [@kushagarr](/u/kushagarr) ,\n\nWas able to get Claude Fable to scaffold out an integration between `xyflow/system` and the miso DSL. I am not an `xyflow` internals expert, but this seems like a decent start that could be iterated upon.\n\nexample: [https://flow.haskell-miso.org](https://flow.haskell-miso.org)\n\nexample code: [miso-flow/example/Main.hs at master · haskell-miso/miso-flow · GitHub](https://github.com/haskell-miso/miso-flow/blob/master/example/Main.hs)\n\nhaddocks: [https://flow-haddocks.haskell-miso.org](https://flow-haddocks.haskell-miso.org)\n\nrepo: [GitHub - haskell-miso/miso-flow: Node-based UIs for miso, powered by xyflow · GitHub](https://github.com/haskell-miso/miso-flow)\n\n \n2 Likes\n\n \nThanks for another release!  I’m working on a project now and chose Miso over Elm and I’ve been very happy with it.\n\nI’ve been using global context to follow patterns I learned back with some React work with Reflux and later native context, though it’s more of a dispatch pattern than setContext.  Is the global context just message passing under the hood, or does it work directly on specially available data?\n\nI’ll also have to explore this new aeson option.  One point of friction has been having two JSON libraries between client and server and it became a mess when I tried to unify on Miso due to some differences between my GHCJS and regular packages in NixOS.  Maybe it’s time to take another look.\n\n \n1 Like\n\n \n[dmjio](https://discourse.haskell.org/u/dmjio)\n6\n \nAwesome, would love to see your app.\n\nIs the global context just message passing under the hood, or does it work directly on specially available data?\n\nThe latter, `context` is shared by all `Component` in a global `IORef`. Whenever it is modified (via `modifyContent` in `update`) the scheduler thread will update the `IORef` and redraw all `Component` whose `useContext = True` (any `Component` that was mounted with `mountWithContext`) top-down.\n\nI’ll also have to explore this new aeson option\n\nThe new `-faeson` `-ftext` flags will polyfill `Miso.JSON` as `Data.Aeson` and force `type MisoString = Text` on the client. That was requested by users that are integrating with other libraries on the client that make heavy use of `text` / `aeson`, for ergonomic reasons.\n\nOtherwise, `type MisoString = JSString` is the default, and `Miso.JSON` uses `JSString` for the `String` constructor. This was shown to be the most performant configuration for the JS backend in general, for WASM backend it seems to vary by workload.\n\n \n\n \nUnfortunately, it’s an admin-only data-management UI at the moment for pages served directly from Servant right now, so hard to demonstrate.  Also, it’s still under development and I can’t say I’d necessarily be proud of it at this point. \n\n`context` is shared by all `Component` in a global `IORef`\n\nI’ll definitely look into this new context mechanism then.  There’s some nice abstractions to message passing and creating a single owner of data, but it’s just annoying to manage.  Context-management functions can easily be centralized for 95% of the benefit but an IORef will just be simpler and more efficient.  Less async nonsense to deal with too.\n\nAh, so the Aeson in this case is more of a client-side thing and not server-side.  Sounds like it’s not particularly useful in my case of unifying server/client logic.  I don’t see a reason not to use native JSON on the client.\n\nThank you for the awesome project!\n\n \n1 Like", "url": "https://wpnews.pro/news/miso-1-13-release", "canonical_source": "https://discourse.haskell.org/t/miso-1-13-release/14629#post_5", "published_at": "2026-09-05 16:50:24+00:00", "updated_at": "2026-09-07 02:13:30.706787+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Miso", "dmjio", "xyflow/system", "miso-flow", "GitHub", "Claude Fable"], "alternates": {"html": "https://wpnews.pro/news/miso-1-13-release", "markdown": "https://wpnews.pro/news/miso-1-13-release.md", "text": "https://wpnews.pro/news/miso-1-13-release.txt", "jsonld": "https://wpnews.pro/news/miso-1-13-release.jsonld"}}