I want qlik-embed to work. A simpler integration, modern authentication and less code to maintain should make moving away from the Capability APIs an easy decision.
I am using it now. OAuth integration was the deciding factor, with the push towards embedded AI adding another reason to switch. If I could have integrated OAuth as easily with the Capability APIs, I would have stayed with them without thinking twice.
Qlik calls it its primary embedding framework. For a straightforward chart, I can see why. For an application with extensions, maps, custom styling and its own error handling, the migration comes with compromises that are difficult to accept.
Performance improved, until I needed iframes
My first attempts appeared to load the same scripts across multiple charts. The overhead was enough for me to shelve the switch. Performance has improved massively since then, and Qlik deserves credit for that.
But the improvement feels uneven once I need iframe="true".
Legacy extensions still take me back to iframe rendering through classic/chart. Qlik documents experimental preview="true" support for extensions and more chart types in analytics/chart. UI documentation
In my testing, that preview behaves as read-only. I cannot make selections, and it adds an unnecessary outline around the charts. I couldn't find either behaviour explained in the documentation. Broader chart support is of limited use when I lose the interaction that makes Qlik useful in the first place.
The iframe fallback brings back the performance cost I was trying to escape.
Native charts should be the easy part
Maps are my clearest example. They are native Qlik charts, so I expected them to work through the modern chart component.
The current compatibility table explicitly excludes maps from standard analytics/chart support. Its classic/chart path requires an iframe. Qlik explains that tenant resources such as map tiles and uploaded images cannot currently be authenticated outside that mode. Chart compatibility
That helps explain the image failures I've encountered. It doesn't make the outcome any less frustrating. A native chart that needs tenant-hosted assets can send me straight back to the heavier rendering path. For maps, already expensive in my applications, that extra overhead has made the experience unusable in some cases.
Even branding can trigger the same compromise. Qlik documents that custom theme fonts need iframe mode when embedding across domains, with a possible performance impact. A font should not become an architectural decision. Custom theme documentation
Less integration code, less control
With the Capability APIs, I controlled more of the chart lifecycle. During migration, reproducing my global error handling, custom loading states, chart error messages and authentication retries has been harder than it should be.
There is still API access. refApi exposes the embedded app for operations such as selections and bookmarks. My frustration is with controlling the surrounding experience consistently. refApi documentation
One recent example was trying to remove or restyle Qlik's interaction blocker inside an embedded extension. My React application could reach the outer container, but the cross-origin iframe prevented it from changing the internal element. Moving that styling into Qlik meant depending on internal selectors that Qlik itself warns are unsupported. Qlik's CSS guidance
A small visual adjustment had become a tenant-side workaround. That is the loss of control I mean.
New features make the choice feel compulsory
Qlik Answers adds to the pressure. Its ready-made embedded experience is delivered through qlik-embed. It isn't something my existing Capability API integration simply gains. Assistant components
The documentation now labels ai/assistant as legacy and lists ai/agentic-assistant for the agentic experience. My rule with Qlik is simple. If it says legacy, I avoid it. In my experience, it brings more problems than it is worth.
The assistant still feels bolted on in my application. Getting it to match the surrounding typography, spacing and branding has been harder than I expected.
The Answers APIs provide another route for building my own interface. I appreciate having that option. It also means taking on more development to get the integrated experience I wanted from the component.
There are reasons to keep going
OAuth is a welcome standard authentication route, even though I've encountered session problems with Cloud hubs and embedded applications open together in the same browser. Qlik's authentication guidance is also far ahead of what I had a decade ago.
A component with a few parameters is easier to start with than manually orchestrating visualization calls. Nebula.js and picasso.js give me another way to build charts with more control, if I have the patience or enough AI tokens to do the work. Nebula.js and picasso.js
I use qlik-embed because it gives me the OAuth integration and access to new AI components I need. I still need reliable maps, images and extensions, alongside enough control to make them feel part of my application. Until those everyday requirements stop pushing me into costly workarounds, I can't call it a complete replacement.
Top comments (0)