If I'm reading this correctly, caching only happens if I give it a stable cache key? If that's true, this just seems like an insanely bad decision. I've seen waaaay to much bad React code to think that that isn't a massive foot-gun.
1. That combined with hot reloading just makes me think some jr dev is going to forget to put that there while they're building something locally and burn through their LLM budget without even knowing it.
2. What happens if the cache key changes. Is there any way to migrate from one key to another? Let's say I'm using user ids as the cache key and you need to do a migration that changes the format of the key, is the existing design just gone forever?
3. Does anyone even want a non-deterministic UI? Don't get me wrong, it's a cool for a demo, but I can't think of anything that would annoy me more than coming back to a website and every week it looks different.
Sorry to be a downer, but man, I just really struggle with this. If this is just kind of a cool hobby project then you can ignore #3, but for 1 and 2 I really feel like it'd be a better to do something like have a data attr for the prompt and then have component generation be something a user kicks off through a script or something.
Generative UI has a lot of potential, and some of the ideas here are interesting, but the positioning as a developer tool (for folks that can just generate stable UI using claude code already) seems odd to me. What's the expected use case?
I'm interested in exploring the ideas here for on-the-fly output based on user intent. It reminds me a bit of the schema model I used for the LangView experimental library (https://x.com/rupertmanfredi/status/1653780093712633859).
I was hoping this might be a syntax or very very lightweight markup that could feed LLM generation of UI rather than just roll the dice to see what UI gets generated every time.
But why would anyone do this? The UI will obviously change unpredictably on every generation, there's no way to deliver quality control if the UI is generated on the fly.
I could see this being useful for client and patient onboarding in the services and medial sectors respectively. For example:
A potential client providing information for a law-firm regarding their grievance.
A patient filling out the medical questionnaire prior to their first visit to a medical practice.
Rather than having a fully deterministic form, you'd be providing them with forms that adapt to their specific issue. The data can then be intelligently stored both as JSON and a more generic record in an RDBMS.
That can be achieved with 100% infallability with a form framework like FormKit. Why risk it, especially in a high-stakes situation like health? Pretty sure it would actually be against some kind of regulation to do that specifically in the healthcare field.
It depends on whether your API provider is HIPAA compliant and what sort of disclosures are provided. If you're running inference in house then it's not an issue provided you're following all the other guidelines.
With FormKit you'd still be using a predefined deterministic flow where all the conditionals are accounted for in advance. FormKit wouldn't be able to generate a truly non-deterministic UI that changes based upon how the user answers. If you're wanting to sue your neighbor for their tree falling onto your house, an AI powered UI for a law firm could be giving you form fields on what type of tree it was, how old the tree was, hot tall the tree was, how close it was to the property line, and what room in your house the tree landed in... All generated from how the user responded to an initial "what's your grievance?" question.
I'm not advocating for or against this type of approach - I'm just pointing out a few potential use-cases for it since that's what you asked for.
This is interesting. So here, your app generates data, and you use AI to decide how to render those data.
This is similar to, but not the same as, the approach taken by json-render: https://github.com/vercel-labs/json-render
The latter assumes AI generates the data AND picks the components it will use from your predefined library.
If I'm reading this correctly, caching only happens if I give it a stable cache key? If that's true, this just seems like an insanely bad decision. I've seen waaaay to much bad React code to think that that isn't a massive foot-gun.
1. That combined with hot reloading just makes me think some jr dev is going to forget to put that there while they're building something locally and burn through their LLM budget without even knowing it.
2. What happens if the cache key changes. Is there any way to migrate from one key to another? Let's say I'm using user ids as the cache key and you need to do a migration that changes the format of the key, is the existing design just gone forever?
3. Does anyone even want a non-deterministic UI? Don't get me wrong, it's a cool for a demo, but I can't think of anything that would annoy me more than coming back to a website and every week it looks different.
Sorry to be a downer, but man, I just really struggle with this. If this is just kind of a cool hobby project then you can ignore #3, but for 1 and 2 I really feel like it'd be a better to do something like have a data attr for the prompt and then have component generation be something a user kicks off through a script or something.
Google has a similar project called A2UI:
https://developers.googleblog.com/introducing-a2ui-an-open-p...
In the real-world, to me it makes the most sense for client and patient onboarding.
Generative UI has a lot of potential, and some of the ideas here are interesting, but the positioning as a developer tool (for folks that can just generate stable UI using claude code already) seems odd to me. What's the expected use case?
I'm interested in exploring the ideas here for on-the-fly output based on user intent. It reminds me a bit of the schema model I used for the LangView experimental library (https://x.com/rupertmanfredi/status/1653780093712633859).
Hey - it's not quite a developer tool. It's meant to generate personalized UIs on the fly, for different users, at runtime.
The magic eight ball of UI.
Not usable enough? Just refresh! No, we don’t know how many times you’ll need to do that.
I was hoping this might be a syntax or very very lightweight markup that could feed LLM generation of UI rather than just roll the dice to see what UI gets generated every time.
But why would anyone do this? The UI will obviously change unpredictably on every generation, there's no way to deliver quality control if the UI is generated on the fly.
I could see this being useful for client and patient onboarding in the services and medial sectors respectively. For example:
A potential client providing information for a law-firm regarding their grievance.
A patient filling out the medical questionnaire prior to their first visit to a medical practice.
Rather than having a fully deterministic form, you'd be providing them with forms that adapt to their specific issue. The data can then be intelligently stored both as JSON and a more generic record in an RDBMS.
That's just my initial thoughts.
Google has a similar project called A2UI: https://developers.googleblog.com/introducing-a2ui-an-open-p...
That can be achieved with 100% infallability with a form framework like FormKit. Why risk it, especially in a high-stakes situation like health? Pretty sure it would actually be against some kind of regulation to do that specifically in the healthcare field.
It depends on whether your API provider is HIPAA compliant and what sort of disclosures are provided. If you're running inference in house then it's not an issue provided you're following all the other guidelines.
With FormKit you'd still be using a predefined deterministic flow where all the conditionals are accounted for in advance. FormKit wouldn't be able to generate a truly non-deterministic UI that changes based upon how the user answers. If you're wanting to sue your neighbor for their tree falling onto your house, an AI powered UI for a law firm could be giving you form fields on what type of tree it was, how old the tree was, hot tall the tree was, how close it was to the property line, and what room in your house the tree landed in... All generated from how the user responded to an initial "what's your grievance?" question.
I'm not advocating for or against this type of approach - I'm just pointing out a few potential use-cases for it since that's what you asked for.