# Miso-1.13 release > Source: > Published: 2026-09-05 16:50:24+00:00 [dmjio](https://discourse.haskell.org/u/dmjio) 1 27 Likes This new avatar of miso is simply marvellous to look at. I am not a frontend developer (tried my hand at elm and enjoyed it, but haskell I enjoy more) this has me intriguiged enough to try one more time .. this time with miso A question though.. what’s the limitation here? Can we do something like what reactflow allows for react.. ? 2 Likes [dmjio](https://discourse.haskell.org/u/dmjio) 3 thank you In 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. 1 Like [dmjio](https://discourse.haskell.org/u/dmjio) 4 Dear [@kushagarr](/u/kushagarr) , Was 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. example: [https://flow.haskell-miso.org](https://flow.haskell-miso.org) example 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) haddocks: [https://flow-haddocks.haskell-miso.org](https://flow-haddocks.haskell-miso.org) repo: [GitHub - haskell-miso/miso-flow: Node-based UIs for miso, powered by xyflow · GitHub](https://github.com/haskell-miso/miso-flow) 2 Likes Thanks for another release! I’m working on a project now and chose Miso over Elm and I’ve been very happy with it. I’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? I’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. 1 Like [dmjio](https://discourse.haskell.org/u/dmjio) 6 Awesome, would love to see your app. Is the global context just message passing under the hood, or does it work directly on specially available data? The 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. I’ll also have to explore this new aeson option The 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. Otherwise, `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. Unfortunately, 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. `context` is shared by all `Component` in a global `IORef` I’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. Ah, 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. Thank you for the awesome project! 1 Like