# On UI as Code **URL:** \ **Category:** General\ **Created:** [27 March 2025 18:07 UTC](https://forum.malleable.systems/t/on-ui-as-code/313 "2025-03-27T18:07:10Z")\ **Posts on this page:** 1\ **Showing post:** 17
**Author:** ![Bosmon](https://forum-cdn.malleable.systems/user_avatar/forum.malleable.systems/bosmon/32/236_2.png) [@Bosmon](https://forum.malleable.systems/u/Bosmon)\ **Post date:** [2 April 2025 16:27 UTC](https://forum.malleable.systems/t/on-ui-as-code/313/17 "2025-04-02T16:27:18Z")
> [@akkartik](#): > > So I sometimes create custom views of conversations. Here’s one I just made for our exchanges, in case you find it useful. Thanks, this is really lovely - I’m touched you went to the trouble to map this out! It feels like we need some dedicated scheme for tracking these - perhaps in the form of a “substrate” or so? : P > [@akkartik](#): > > Your model 1 and model 2 distinction makes sense to me now. But it still seems independent of the use case in OP. At the point where someone is trying to remove that underline, they likely have no idea whether to define new words or orchestrate existing words. So the distinction seems to add more cognitive load, and it’s unclear if it helps. Here’s where I think the distinction is important. Indeed - the OP has no idea at the point they find the requirement e.g. for the underline whether they want to change words or add words. This can only be informed once they find where the words and what form they take which are responsible for the underline, which for a start requires there to be some intelligible journey they can take towards the words from what they see on the screen. At the point they find them, they will likely form an opinion then which model they prefer - and especially, if they find they take the form of anything like a 1600 line TypeScript file, they will likely want model 2. However, unless the artefact they interact with was already built on some kind of substrate with coordinates to it (_in addition to_ them having some ability to rebuild/redeploy it due to its being open source etc. etc.) model 2 is not going to be available. I see this as almost a political kind of distinction, amounting to [Freedom of Association](https://en.wikipedia.org/wiki/Freedom_of_association) for code - the user should have a free choice of options for how they want their communities to be connected. Does that help situate the distinction any? > [@akkartik](#): > > I think there’s no good way to achieve malleability at scale, so the declarative approaches seem to have limited upside and imperative approaches seem more competitive. Yes, I agree with that - but also, at this scale, we are at the level where one could expect AI to satisfactorily produce the entire design for us, meaning that any distinction between approaches is pretty minor. But every big design starts as a small design, and I hope that eventually substrates can be developed which ease the task of designs growing up, becoming mature, and having more and more variants shared amongst communities with slightly divergent needs. So even if there is no real advantage at the small scale I think it’s worth exploring different means of expression. Unfortunately this is a microcosm of the “poison tree” which AI spreads in so many different communities - it makes it very much harder for immature ideas or workers to find space to grow up. > [@akkartik](#): > > It sounds like magic, and I have no idea how to achieve that goal. So if you manage to “show not tell” this and build something with the values of CSS that generalizes beyond layout concerns, it’s going to be a hugely impactful achievement. It would upend my whole belief system in the picture above. Well this sounds a bit intimidating to me - hopefully there is some middle ground in which I could produce something which is neither a paradigmatic smash, nor a humiliating failure, but something “a bit funny” which stimulates further ideas and work! To put a line in the sand, “ancient Infusion” did actually succeed in delivering most of the goals of the OAP paper, it’s just that Jonathan Edwards (quite rightly, I think) considered that we should remove mention of the system itself from the paper since it was already massively crammed. In an older version of the paper there were system details and even a dynamic [video of a CATT](https://lichen-community-systems.github.io/infusion-onward-video-example/). You can see some test cases for the CSS selector-like system, “distributeOptions” [here](https://github.com/fluid-project/infusion/blob/main/tests/framework-tests/core/js/FluidIoCTests.js#L5716-L5785) and some docs [here](https://docs.fluidproject.org/infusion/development/IoCSS). The problem was that the system was so race-laden and unperformant I wouldn’t dare render more than a couple of dozen components in it and certainly not its own self-editing interface. What’s changed since 2022 is that I’ve rather better got my head around reactive programming techniques/incremental computation and have more confidence that I can orchestrate the workflow without it being full of transactions and weird stovepipes. One thing I realise is, that, since you’ve developed [LuaML2](https://forum.malleable.systems/t/a-minimalist-hypertext-browser/316/2) we don’t need to agree about whether the Web is a worthy platform or not. I see that what I consider the premier JS reactive programming library, [alien-signals](https://github.com/stackblitz/alien-signals) has been [ported to Lua](https://github.com/YanqingXu/alien-signals-in-lua) and that also there is good support for proxies in Lua so many of the underpinnings are there - should I produce anything usable “it shouldn’t be too hard” to port it in to LuaML2. Have you tinkered with reactive programming much? ```auto {type='line', data={0,0, 0,600}}, {type='line', data={0,0, 800,0}}, ``` Does this kind of lingo have a name, LSON or so? : P --- _[View the full topic](https://forum.malleable.systems/t/on-ui-as-code/313)._