LLVMs are indeed a huge wild card! We already have companies like MidJourney that merely provide a Discord bot that you interact with. ChatGPT can already call JSON APIs when it doesn't know certain things. The future might not even require a UI at all; you'll just converse with your AI, and that's it.
> What does it take to make Fidget support a retained mode? It's already in retained mode but with an immediate mode API. I think there are so many flavors of Immediate to Retained that it's hard to reason about it all. On one hand, you have the standard retained mode UI, such as creating `new Panels()` and adding a `new Button()` like in VisualBasic or Java's Swing. Then, you have "different" retained mode systems where you lay out stuff using XML (Android/C#/QT) or HTML. Then, you have systems like React, where it kind of acts like immediate mode but is backed by a retained mode DOM. Then, you have something more true to immediate mode like Dear ImGui or Nuklear. Usually, a UI library is a combination of approaches. I tried to make Fidget an immediate mode UI library. The goal was that every frame is kind of fresh... but that proved to be slow. I found myself adding more and more caching (if you can reuse something from the last frame, do so). This is particularly true in HTML mode... where I basically cache the whole DOM and only make minor changes... at this point, Fidget is no longer immediate, but reactive. How do you make text boxes in immediate mode? Undo/redo? Numerous scrolling areas? Animations where things take time to hide, show, and slide off? The more I worked on Fidget, the more retained and complex it got. I felt like the Figma exporter that would export DSL code also didn't pan out as well as I would have liked. Sure, I can generate the initial version of the code from the design. That's a significant improvement! But updating it was difficult. Perhaps a markup format would have been better? Or something that can be exported repeatedly, like a UI model file. I thought immediate mode was easier to program, but not when you're displaying a ton of data and dealing with a heap of state. It all just gets slower and more confusing. Changes during rendering cause strange dependency puzzles. It's cool that in immediate mode, a click is just an if statement. Just check if the mouse overlaps and the button is down! But now, you can't delete an item on a button press but have to wait until the next frame to delete it? I like reactive changes where you have a model. Update the model and the UI magically updates the next frame. But that's kind of slow for a large model! Maybe wrapping each model object in a change tracking layer is a better approach? But then you pay that price on every change! With a lot of work, I feel confident I can get to a place I like.
