{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiepjul5fpebi3cefzebp6tjuvdbb2qnjeooeoaneof2twqh72j4x4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mgcyxzryvmr2"
  },
  "path": "/t/layoutz-0-3-2-zero-dep-elm-style-tui-s-for-haskell-now-w-terminal-plots-more/13760#post_3",
  "publishedAt": "2026-03-05T07:40:52.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "Brick",
    "Layoutz"
  ],
  "textContent": ">   * With LLM’s, boilerplate code that formats & “pretty-prints” is _**cheaper than ever**_ …\n>   * Thus, _**more than ever**_ , “string formatting code” is spawning, and polluting domain logic\n>   * Ultimately, **layoutz** is just a tiny, declarative DSL to combat this\n>\n\n\nHow does the architecture compare to brick?\n\nTo me the entry points look quite similar.\n\nBrick:\n\n\n    data App s e n =\n        App { appDraw :: s -> [Widget n]\n            , appChooseCursor :: s -> [CursorLocation n] -> Maybe (CursorLocation n)\n            , appHandleEvent :: BrickEvent n e -> EventM n s ()\n            , appStartEvent :: EventM n s ()\n            , appAttrMap :: s -> AttrMap\n            }\n\n\n\nLayoutz:\n\n\n    data LayoutzApp state msg = LayoutzApp\n      { appInit          :: (state, Cmd msg)                 -- ^ Initial state and startup commands\n      , appUpdate        :: msg -> state -> (state, Cmd msg) -- ^ Update state with message, return new state and commands\n      , appSubscriptions :: state -> Sub msg                 -- ^ Declare event subscriptions based on current state\n      , appView          :: state -> L                       -- ^ Render state to UI\n      }\n",
  "title": "Layoutz 0.3.2 🪶 Zero-dep Elm-style TUI’s for Haskell - now w/ terminal plots & more"
}