{
  "$type": "site.standard.document",
  "canonicalUrl": "https://deterministic.space/impl-virtual-dom-cli-libui.html",
  "path": "/impl-virtual-dom-cli-libui.html",
  "publishedAt": "2016-07-23T00:00:00.000Z",
  "site": "at://did:plc:x67qh7v3fd7znbdhauc45ng3/site.standard.publication/3mjcd2t6afe25",
  "textContent": "Among other things, I want to easily write UIs in Rust. (What I describe below could also be done in any other language though.)\n\nVirtual DOM\n\nDealing with a virtual DOM (instead of directly manipulating the real DOM) was popularized by React.js. Advantages are:\n\n- Developer declares what UI components should be shown, renderer determines good way to update your UI (clever diffing)\n- Works nicely with reactive programming\n- Works nicely with doing as little as possible in the render/UI thread (send diff result to UI thread which can just apply the changes)\n\nThe name \"Virtual DOM\" might suggest a direct relation to the HTML DOM implemented in browsers; I mean it in a more abstract way, though. (I just haven't come up with a good alternative name, yet!)\n\nJust a tree of UI components\n\nWhile React.js started with rendering to HTML, there are several other targets available now, including React Native (iOS, Android) and HTML5 canvas.\n\nBasic building blocks:\n\n1. Define \"UI component\" trait that can be rendered.\n2. UI components can be nested to build a tree (with exactly one root).\n3. Implement clever diffing between two trees of UI components. (React uses the component type and key attributes unique among sibling components to short-circuit the otherwise O(n^3) diffing.)\n\nAbstract component definition\n\nOne nice thing about all things virtual DOM is that it also abstracts how component instances are created. While React introduced the JSX syntax (think XML-like angular-bracket things in JS that compile to function calls), the virtual-dom module (also in JavaScript) includes a nice helper function that one can call like h('.greeting', ['Hello ' + data.name]) (creates a div with class greeting and content Hello ${data.name}).\n\nThe abstract idea is this: UI components can have attributes and children (i.e., an array of more UI components). A plain string is also considered a UI component and is rendered as a simple text node.\n\nFor example: Your UI library gives you a bunch of functions with the signature (attributes, children) -> VirtualUiNode, and also exports the virtual DOM helper functions to update a tree of these VirtualUiNodes.\n\nI can image it having an API like this:\n\nRender targets\n\nlibui\n\nlibui is a \"simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports\". The Rust binding can be found in libui-rs.\n\nLooking at one of the examples, the code looks quite imperative.\n\nImagine a pseudo-Rust macro called ui! that matches like this: ($type:ident $label:expr? {$($key:ident => $val:expr),}? [$($subcomponent:tt),]?) => {...} (disregarding text nodes for now). Assuming that most libui components can have attributes and sub-components, one could imagine defining the same UI like this:\n\nEach sub-component or list of subcomponents can also be refactored into a variable using the same macro.\n\nCLI\n\n(~~I think I've seen a virtual-dom-like CLI library some time ago, but can't find it right now.~~ Found it again: It's react-blessed, a React-based renderer for the curses-like JS library blessed.)\n\nThere are some ways to make fancy command like interfaces. I've recently used termion and contributed to inquirer-rs.\n\nImagine defining a CLI select box like this:\n\nUpdates\n\nImmediate-mode GUIs\n\n@lqd mentioned on Twitter that virtual DOM might be a poorer version of immediate-mode GUI APIs:\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\"><a href=\"https://twitter.com/killercup\">@killercup</a> your vdom/libui post was cool, but to me vdom is also a poorer version of immediate-mode GUI APIs which would be even simpler :)</p>&mdash; Rémy Rakić (@lqd) <a href=\"https://twitter.com/lqd/status/760223190182465538\">August 1, 2016</a></blockquote>\n\n<blockquote class=\"twitter-tweet\" data-conversation=\"none\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\"><a href=\"https://twitter.com/lqd\">@lqd</a> interesting. do you have an example for nice immediate-mode GUI code?</p>&mdash; Pascal (@killercup) <a href=\"https://twitter.com/killercup/status/760224634855911424\">August 1, 2016</a></blockquote>\n\n<blockquote class=\"twitter-tweet\" data-conversation=\"none\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\"><a href=\"https://twitter.com/killercup\">@killercup</a> 1) <a href=\"https://t.co/zd9I0owlpf\">https://t.co/zd9I0owlpf</a> 2) <a href=\"https://t.co/JgrbdaZGSw\">https://t.co/JgrbdaZGSw</a> (page 34) 3) <a href=\"https://t.co/9lldQFUlWR\">https://t.co/9lldQFUlWR</a> 4) surely on <a href=\"https://twitter.com/handmade_hero\">@handmade_hero</a> as well</p>&mdash; Rémy Rakić (@lqd) <a href=\"https://twitter.com/lqd/status/760229545010163715\">August 1, 2016</a></blockquote>\n\nReact Fibre\n\nAndrew Clark published an overview of the React Fiber Architecture recently:\n\n> React Fiber is an ongoing reimplementation of React's core algorithm. It is the culmination of over two years of research by the React team.\n>\n> The goal of React Fiber is to increase its suitability for areas like animation, layout, and gestures. Its headline feature is incremental rendering: the ability to split rendering work into chunks and spread it out over multiple frames.\n>\n> Other key features include the ability to pause, abort, or reuse work as new updates come in; the ability to assign priority to different types of updates; and new concurrency primitives.\n\nIt'll be interesting to see if React Fibre ends up being the same kind of abstraction I was describing here.",
  "title": "Virtual DOM for CLI and libui",
  "updatedAt": "2016-07-23T00:00:00.000Z"
}