I feel like the custom component is a great tool, but I’m running into some limitations:
Sometimes it’s slow (in the user interface)
It’s somewhat unreliable in terms of re-using it. For instance I created a draggable slider for tyre pressure 0-10 bar and then wanted to re-use that for battery percentage from 0-100%. However, it’s fairly challenging to make it work and look exactly the same when using different values.
Does any of you have experience in optimizing the speed/performance of the AI Custom Component and how do you make it consistent when applying in multiple locations of the app?
The custom AI component is still experimental and, like most AI models, may occasionally behave unpredictably.
Performance issues, such as slowness, are often due to browser behavior, especially delays in loading iframes. In some cases, it might also be related to how Glide handles iframe loading within the DOM.
I know that many folks have had great success with it, and use it a lot.
Personally, I avoid it as much as possible. It’s fine to experiment with in personal or hobby Apps, but mission critical Business Apps generally have a very low tolerance for failure. And I don’t believe the AI Component meets this bar just yet.
I really appreciate your perspective, seriously, great points! That said, I don’t completely agree, and I promise I’m not trying to start a debate .
In my experience, there is a limit where using an AI Component in mission-critical business apps can still be safe. I’ve used it in production many times without any major issues.
The key advantage is that AI Components let you build things that aren’t always possible with Glide’s native tools. That said, I totally agree there are use cases where it becomes risky.
Use cases I agree shouldn’t be used in mission-critical business apps:
JSON Source Data: You can’t guarantee it will continue to work after changes in the JSON column, there’s no alert system, and it can silently break your AI Component.
Browser APIs: These shouldn’t be relied on from within AI Components since they could be restricted by Glide at any time. Definitely something to watch out for.
Overlays: Even if you manage to show an AI Component as an overlay, changes in how Glide handles iframe integration could cause unexpected behavior, or worse, break things entirely.
Use cases I feel confident can be used in mission-critical apps:
Triggers: Using an AI Component to trigger an action based on data changes has worked reliably for me.
Custom components using basic column types (text, boolean, number, array): These are simple and less prone to breaking.
Customizable components using raw JSON as config: This is a flexible and safe pattern if you thoroughly test all possible config combinations before deploying to production. It avoids the need to modify prompts directly, which can lead to breakage.
I’ve use the AI custom component in 2 mission-critical applications.
For the reasons Darren explained above, I was quite hesitant to use it. However I built components that are very simple and I have not experienced any bugs so far.
An example: a custom component to display an image. The default image component doesn’t have the configuration options I needed, so I built a simple image component that fit the exact use case I needed with the custom component.
I have also not reused the AI custom component. I think I would feel more comfortable rebuilding it than copying it.
It needs to be more reliable, and more predictable. I’ve seen several instances where Custom components will randomly fail for no apparent reason.
I should note that I’m probably biased, as I have a general dislike for vibe coding.
I also accept Maxime’s comments and would admit that he is in a much better position to say what it is and isn’t good for, as I know he’s done a lot of work with it.
That said, I’ll continue to resist it for now
Oh, and the other thing I would say is that because it’s still considered an experimental feature, Glide will not support it. So if you use it and it breaks, you’re on your own
Generally speaking I avoid copy-pasting components, though it probably works fine.
To rebuild an AI custom component specifically, I copy-paste my prompts but not the component itself. This might be a waste of time, but to me it’s worth the peace of mind it brings me.
I’m not saying this is the way to do it, I’m saying this is how I do it because I feel more comfortable this way.
There is nothing we can do about how Glide or the browser manage those. Of course, there are way to optimize iframe, but we don’t have control on it from the AI Component.
@Darren_Murphy I’m taking that into account, indeed I’m not using it for mission-critical components/features.
@nathanaelb Tried that as well. In my experience, that didn’t provide reliable results for elements that needed to be identical.
@MaximeBaker I once told it “to improve the performance” and in fact it helped quite a bit (broke some fancy feature, but whatever haha), so I was wondering if there were others and other methods applied. It seems not, then?
I also tried custom code with html to Url and embed component to build a custom component for a client. It is working fine, but the iframe loads with a delay and refresh everytime a column used in the embed changes.
I get what you mean — the custom component is powerful but it isn’t always smooth, especially once you start re-using it in different contexts. I’ve also seen some UI lag depending on the logic and bindings inside it.
For the re-usability part, I’ve found that components behave way more consistently when the core config (min/max/range/style) is abstracted into props instead of hard-coding them. In your slider case, you might get more predictable behavior if you rebuild it once using flexible props and then just pass in different values (instead of editing the component itself each time).
On the performance side, the only things that helped me were:
reducing how many bindings run inside the component
keeping layout/DOM inside it as lean as possible
avoiding too many conditional renders or repeated listeners
Curious — are you using a lot of AI-driven logic inside the component or mostly pure render + bindings? That might also influence speed.
I have experienced similar issues indeed. When I’m doing “backend” work, the frontend glitches. Something to look out for. What do you mean with html to Url?
Thanks, sounds interesting! What is your workflow in doing this? As in, what is your method to get this core config consistent and reliable? And how do you go about reducing the bindings etc?
I try to handle all conditionals in the Data Editor and not implement those in the AI components. So I would say it’s pure rendering. I’m not familiar with the term ’ bindings’. (I’m fluent, but English is not my native language:D)
@MaximeBaker Awesome, thanks for the suggestion! Just tried this out (randomly) and I see some applications using template columns to display information in a custom way. Have you found a way to make this interactive?
As in: one could select something and write that value to a column? I imagine it could be possible using an AI column but that would probably use a lot of updates..
(still looking for a way to make a user-friendly date-time picker that is limited to increments of 15 minutes and only displays working hours/days).
If the code contains JavaScript, you can make it dynamic. But if you rely on another column data, every time it changes, it will unfortunately refresh the embed component. If this isn’t an issue for you, then go ahead.
Unfortunately, the embed component doesn’t support writing to other columns. You can try sending the code to another component and use dynamic data bindings to prevent refreshes on data changes, which allows writing to other columns. However, the component may not consistently execute your exact code. Smaller code snippets usually work fine, but larger blocks often fail to apply correctly.
Updating data from the AI component doesn’t count against your update limits. The only exception is for certain Enterprise plan configurations, but if you are on the Maker, Explorer, Business, or Free plan, you do not need to worry about this consuming updates.
.
