DEV Community: Alexander Lukashov

Hybrid search for your app in an afternoon, for $0

Alexander Lukashov — Tue, 28 Jul 2026 18:00:44 +0000

Somebody's card gets declined. They open your help center and type "my money disappeared". Your article is called "Troubleshooting failed payments". Not one word in common, so search returns nothing and they write to support instead.

Keyword search only finds what you already named correctly. Semantic search fixes that, and then misses the other way: ask it for the error code NB-2001 and it hands you something thematically close instead of the page with that string in it. Hybrid runs both and merges them, so exact matches take the top and meaning fills in below.

The usual price for that is a vector database, an embedding pipeline and a sync job between your content and your index. Here is the version with none of those. It took an afternoon and cost nothing.

Quick disclosure: I built FoxNose, and Loquix is mine too. Everything below runs on a free account, and there is a short list at the end of cases where you should use something else.

The two pieces

FoxNose stores the content and does the search. Mark a field searchable and vectorizable and every record you publish is indexed for keywords and vectors. Hybrid search is on the free tier, and for a small product the free tier is enough to just run this.

Loquix is MIT web components, including a <loquix-search-dialog> you can drop in. Plain custom elements, so React, Vue or nothing at all.

The browser calls the search API directly. No backend of yours in the middle.

1. Describe the content

Sign up and create a project. FoxNose provisions one environment for it, Production, and you can add more later for staging or previews. An environment is a separate database with its own API host at https://{environment_key}.fxns.io. Note that key down, you need it in a minute.

Inside the environment, create a collection. Mine is called articles. Then give it a schema in the visual editor: fields, types, flags, publish. Schema versions are drafts until you publish them, so there is no way to half-apply a change.

I used a help center for a fictional product, 24 articles:

Field	Type	Flags
`title`	text	searchable, vectorizable
`slug`	string	-
`summary`	text	searchable, vectorizable
`body`	text	searchable, vectorizable
`category`	string	searchable

That is the whole search setup. searchable indexes the field for querying, vectorizable means embeddings get generated on every publish. No embedding code, nothing to keep in sync, no index to create.

Two things worth knowing before you load anything. Full-text search lives on text fields, not string, so anything people will actually search inside wants to be text. And a field's type cannot be edited later, only recreated: you remove the field and add a new one in its place, then load the content again. Cheap now, annoying after you have data.

2. Load the content

npm install @foxnose/sdk

Three values go into your .env here: the environment key from a minute ago, the collection key, and a management API key you create in the environment settings.

// seed.js
import fs from 'node:fs';
import { ManagementClient, SimpleKeyAuth } from '@foxnose/sdk';

const articles = JSON.parse(
  fs.readFileSync(new URL('./articles.json', import.meta.url), 'utf8'),
);

const client = new ManagementClient({
  environmentKey: process.env.FOXNOSE_ENV_KEY,
  auth: new SimpleKeyAuth(
    process.env.FOXNOSE_MGMT_PUBLIC_KEY,
    process.env.FOXNOSE_MGMT_SECRET_KEY,
  ),
});

await client.batchUpsertResources(
  process.env.FOXNOSE_COLLECTION_KEY,
  articles.map((article) => ({
    external_id: article.slug,
    payload: { data: article, name: article.title },
  })),
);

client.close();

Run it with node --env-file=.env seed.js on Node 20.6 or newer, so you do not need dotenv for this.

external_id makes it an upsert, so you can re-run this as often as you like. Each write validates the record, generates the embeddings, indexes it and publishes it.

You can also just type content into the visual editor, which is the point for a real product: support people edit help articles without a deploy.

3. Put the search online

Content is served through what FoxNose calls a Flux API. Create one, give it a prefix, connect the collection. Three settings matter for calling it from a browser:

connect the collection with both get_many and get_one, or results come back without content
make the API public, meaning anonymous reads (writes still need a key)
turn on Allow all origins so the API accepts calls from a browser at all (fine here, these articles are public anyway)

Now you have an endpoint:

https://{environment_key}.fxns.io/help-center/articles/_search

No key in your frontend, no proxy to hide that key.

4. Search

// flux.js
const BASE = 'https://YOUR_ENV_KEY.fxns.io/help-center';

export async function hybridSearch(query) {
  const response = await fetch(`${BASE}/articles/_search`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    signal: AbortSignal.timeout(10000),
    body: JSON.stringify({
      search_mode: 'hybrid',
      find_text: {
        query,
        fields: ['title', 'summary', 'body'],
        threshold: 0.85,
      },
      vector_search: {
        query,
        fields: ['title', 'body'],
        top_k: 25,
        similarity_threshold: 0.6,
      },
      hybrid_config: {
        vector_weight: 0.4,
        text_weight: 0.6,
        rerank_results: true,
      },
      limit: 25,
    }),
  });
  if (!response.ok) {
    throw new Error(`Search failed: ${response.status} ${await response.text()}`);
  }
  return (await response.json()).results;
}

One request, two ranked lists, one answer. NB-2001 returns the error codes page. "my money disappeared" returns the payments article. search_mode also takes text or vector if you ever want one side on its own.

threshold: 0.85 is your typo tolerance: at 1.0 matching is exact, lower is fuzzier, so "pyament declined" still lands.

Then there are two numbers that decide how good this feels, and neither has a universally right value:

similarity_threshold is the floor for "close enough" on the semantic side. Every document is a little bit similar to every query, so this is where you cut. Too low and a question about baking bread returns your billing articles. Too high and paraphrases stop working. 0.6 fits these 24 articles.

The weights settle words against meaning. Text-heavy works for a help center, where people search for strings that literally exist: error codes, plan names, button labels. For a product catalog, where nobody knows your wording, push the vector side up.

There is no magic here, which I think is the good news. It is arithmetic over two ranked lists. Load your own content, throw your real queries at it, move the two numbers, look at what comes back. Twenty minutes of that beats any default.

Filters live next to all this: where takes typed operators over any searchable field, combined with all_of and any_of.

5. The dialog

npm install @loquix/core lit

<loquix-search-dialog
  id="search"
  heading="Search help center"
  placeholder="Search help articles..."
  kbd="⌘K"
  mode="plain"
  hide-answer
></loquix-search-dialog>

mode="plain" keeps it a search box and hide-answer drops the LLM answer block, which is a different article. You get a real modal <dialog> with a focus trap, keyboard navigation, loading states and a chip row, none of which you write.

It knows nothing about any backend. It fires events and takes plain arrays:

import '@loquix/core/tokens/variables.css';
import '@loquix/core/define/define-search-dialog';
import { hybridSearch } from './flux.js';

const dialog = document.getElementById('search');

const CATEGORIES = [
  { id: 'getting-started', name: 'Getting started' },
  { id: 'billing', name: 'Billing' },
  { id: 'account', name: 'Account' },
  { id: 'api', name: 'API' },
];

let hits = [];
let category = 'all';

function render() {
  const shown = category === 'all'
    ? hits
    : hits.filter((hit) => hit.data.category === category);

  dialog.results = shown.map((hit) => ({
    id: hit._sys.key,
    title: hit.data.title,
    snippet: hit.data.summary,
    url: `/help/${hit.data.slug}`,
    source: CATEGORIES.find((c) => c.id === hit.data.category),
  }));

  dialog.sources = CATEGORIES
    .map((c) => ({ ...c, count: hits.filter((h) => h.data.category === c.id).length }))
    .filter((c) => c.count > 0);

  dialog.activeSource = category;
}

async function runSearch(query) {
  if (query.trim().length < 2) {
    hits = [];
    dialog.results = [];
    dialog.sources = [];
    return;
  }

  dialog.state = 'searching';
  try {
    hits = await hybridSearch(query);
    category = 'all'; // a new query starts unfiltered
    render();
  } catch (error) {
    console.error(error);
    hits = [];
    dialog.sources = [];
    dialog.results = [{ id: 'notice', title: 'Service is too busy. Try again.' }];
  } finally {
    dialog.state = 'idle';
  }
}

let timer;
dialog.addEventListener('loquix-change', (e) => {
  clearTimeout(timer);
  timer = setTimeout(() => runSearch(e.detail.value), 250);
});

// Enter fires submit, Cmd+Enter fires ask even in plain mode, so wire both
dialog.addEventListener('loquix-search-submit', (e) => runSearch(e.detail.query));
dialog.addEventListener('loquix-search-ask', (e) => runSearch(e.detail.query));

dialog.addEventListener('loquix-search-source-select', (e) => {
  category = e.detail.sourceId;
  render();
});

window.addEventListener('keydown', (e) => {
  if ((e.metaKey || e.ctrlKey) && e.key === 'k') {
    e.preventDefault();
    dialog.show();
  }
});

Three notes on that, because they are easy to miss:

.results and .sources are JavaScript properties, not attributes. Setting them in HTML does nothing.

Debounce is yours to add. Every keystroke would otherwise be its own request, and one request counts the same whether it returns one result or twenty five.

The chips filter what you already fetched, so their counts and their clicks describe the same set of results. No extra request, instant. The same strip is built for a bigger job: give each kind of content its own collection, fire one query per collection in parallel, and each chip becomes a source with its own count as the answers arrive.

React users: @loquix/react wraps every component, events arrive as props like onSearchSubmit. Both packages ship types.

What this is, and where it stops

Worth being straight about the shape of it: FoxNose is not a search engine. It is a typed content database built for LLM agents and RAG, with hybrid search included, which is why one API holds your records and retrieves them and there is nothing to sync in between.

A product that does search and only search goes further in specific places: merchandising rules, search analytics, highlighted snippets, facet counts across a whole corpus, US data residency, edge latency at very large scale. All real features, and if your product lives on one of them, use Algolia. For most teams shipping a help center or in-app search, none of them come up in a normal month.

If you would rather run infrastructure, Typesense and Meilisearch are excellent and free at any volume.

Take it

The whole thing is in one repo: https://github.com/loookashow/hybrid-search-help-center. Copy .env.example, add your keys, then npm install, npm run seed, npm run dev.

Two flags on a schema, one fetch, one component, two numbers to tune. Next time I will put a language model on top of the same API so the box can answer in sentences and cite the articles it used.

Go type "my money disappeared" into your own product's search. Curious what comes back.

Why I made my paid product fully free for personal use

Alexander Lukashov — Tue, 19 May 2026 16:25:33 +0000

I spent two months thinking about pricing before I let myself write the pricing page.

That is not a humblebrag, it slowed everything down. The product was technically ready in March. By April it could have been on sale. But every time I sat down to define the free tier, something did not sit right, and I would close the tab and go fix a bug instead.

What unstuck it was not a framework, a benchmark, or a YC essay. It was one question I could not answer to my own satisfaction. I want to write about it, because the question is generalizable and I think a lot of solo makers building tools quietly trip over it.

A bit of context first. I have been a technical product manager at large tech companies for many years, always on B2B SaaS, always with a team, always for someone else's company. The product I was pricing is Notch, a screen recorder for Mac and Windows. It is the first desktop app I have shipped under my own name. So this was the first time I was personally on the line for a pricing decision, with my own money funding the development and my own name on the receiver.

The freemium playbook I almost ran

When I sketched the pricing card the first time, it looked almost exactly like what every other screen recorder does:

Free tier with a 5-project cap, limited by 1080p output quality, and a watermark on exports
Paid tier at $49 one-time that removes both

This is the freemium playbook by default. The free tier is a trial in disguise. Generous enough to demo the product, restrictive enough that anyone using it seriously has to upgrade. Loom does it. Screen Studio does it. Camtasia does it. Tella does it. So did the spreadsheet I was modelling.

The numbers added up. The conversion funnel made sense. I built the watermark into the export pipeline. I implemented the project counter and a "you've hit your limit" modal. I tested both. They worked.

I just did not want to ship them.

The question I could not answer

The discomfort was not moral. I had convinced myself the freemium model is honest enough, since the limits are visible upfront. The discomfort was about a specific user I kept picturing.

That user is someone like me five or ten years ago: an engineer recording their first screencast tutorial for their blog, a student doing a class project, a hobbyist showing their indie game on Mastodon. Someone who is not going to make a dollar from the thing they are recording. Someone for whom $49, even one-time, is meaningful money.

Why am I asking them to pay?

I sat with that question for two weeks. Every answer felt thin.

"Because the software costs me money to maintain."

OK, true, but that user is not loading my support queue. They are not going to email me. They are using the product silently.

"Because if I let them export for free, they will never upgrade."

They were never going to upgrade. They do not have a use case for the Commercial license, they are not running paid work through it. The "upgrade" framing is a trick I would be playing on someone who could not fall for it.

"Because it is the standard model in the category."

The least convincing answer of all. "Everyone does it" has never been a strong reason to do anything.

The honest version of the question kept reformulating itself in my head:

Why should someone pay me if they are not making money from this themselves?

I did not have a good answer. So I stopped trying to find one.

What I changed

I removed the project cap. I removed the watermark. I removed all limits. The personal tier of Notch is fully free. No degraded export, no nag screens, no asterisks. You install the app, you hit record, you export your video. Done.

The Commercial license is still there. It is $49 one-time, with team pricing for 3 and 10 seats. The split is not "free for limited use, paid for everything". It is "free for personal use, paid for revenue-generating use". The line is the purpose of the recording, not the feature set.

This means:

A student making a class project: free, forever, with full features.
A bootcamp graduate recording tutorials for their portfolio: free.
An OSS maintainer recording a feature demo for a GitHub issue: free.
A teacher recording an async lesson for their students: free.
A consultant making client deliverables: Commercial license.
A SaaS team recording onboarding videos: Commercial license.
A YouTuber monetizing their channel: Commercial license.

The free tier and the Commercial tier are the same software. The license is what changes.

The objection I expected

I had a draft of this post that opened with the predictable objection: "But how will you actually make money?"

I cut it because I think it deserves a real answer, not a defensive setup. Here is the real answer.

Most non-monetizing users were never going to pay anyway. Walking into a freemium model assuming they are conversion-able is wishful. The honest math: if 95% of free-tier users would never pay regardless of how much you crippled the free tier, your "free tier" was effectively gifting them a worse product than they could have had, and resenting them for not converting.

Commercial users are different. They have a budget line for tools. They are comparing me to Loom at $18/user/month or Screen Studio at $108/year. A one-time $49, or $29/user for a 10-pack, is the cheapest thing in their procurement queue. They are going to pay.

Goodwill compounds. The student who got Notch for free for a year, who graduates and goes to a SaaS company that needs internal training videos, that is the person who pitches Notch to their boss. Not because of switching costs, but because they already know it works and trust it. That kind of advocacy does not show up in a conversion funnel, is almost impossible to A/B test, and stacks over years.

The "real free tier" is a marketing position. It is also a moat. Every competitor who runs the freemium-with-limits playbook is implicitly telling their non-monetizing users "we tolerate you, for now". That is not a feeling people seek out.

The deeper reason

I will be honest about the part that is not a pricing argument.

I went into product management years ago because I love watching the results of my work get used. Not "purchased". Used. The thing I find satisfying about shipping is people getting value. If I could only sell products and never see them in someone's hands, I would have stayed in e-commerce.

Building "another commercial product", one more entry in a category, optimized for revenue capture, was not a strong enough reason for me to spend a year of my evenings on something. It is a thing I could have done with my day job's time instead. The reason I built Notch is that I kept wanting it to exist and nothing else delivered it. The reason I am shipping it is that I want other people to have it too.

A pricing model that restricts the people most likely to enjoy the product, in order to maximize revenue from the people also most likely to enjoy the product, is solving for the wrong thing.

The team and Commercial side will pay for itself. I would rather underearn from the model I chose than overcharge through one that fights my own reason for building.

What I'd tell another maker

Three things, briefly.

Pricing reveals what you actually think your product is for. If the only way the math works is by limiting the people who would love your product most, the math might be wrong.

The freemium playbook is the default, not the answer. It works for some categories, usually ones with high marginal cost per user, strong network effects, or genuine paid value the free tier cannot replicate. Most maker tools are none of those.

Trust your discomfort. I spent two months avoiding writing a pricing page because the model I was about to ship felt wrong. That feeling was data. I should have listened to it sooner.

If you are curious what the product looks like with this pricing applied: Notch is on Mac and Windows, fully free for personal use, no account, no cloud, no nags. Commercial license is one-time, $49.

I am happy to argue any of the above in the comments. I think I am right, but I have been wrong about pricing for a living.

May the force be with you.

I Evaluated Every AI Chat UI Library in 2026. Here's What I Found (and What I Built)

Alexander Lukashov — Wed, 18 Mar 2026 18:00:24 +0000

TL;DR:

React stack → assistant-ui
Full agent framework → CopilotKit
Quick prototype or non-React → Deep Chat
Python backend → Chainlit (check project status first)
Multi-framework + composable, early adopter → Loquix (no production deployments yet — read the limitations)

⚠️ Conflict of interest: I'm the author of Loquix, one of the libraries reviewed here. The independent reviews come first. Loquix gets its own clearly-labeled section at the end, written by me about my own work — treat it accordingly. If you want the quick take: for most teams, assistant-ui (React) or Deep Chat (everything else) is the more pragmatic answer.

Before the reviews: four types of lock-in

After evaluating all of these libraries, the biggest insight wasn't about any specific tool — it was that "lock-in" isn't one thing. There are at least four distinct flavors, and understanding which one you're accepting changes how much it matters:

Type	Example	When it bites
Framework	assistant-ui (React-only)	When you need to support other frameworks
Architecture/runtime	CopilotKit	When your agent infrastructure evolves independently of your frontend
Ecosystem	Vercel stack	Creeps up over time; each layer pulls you deeper
API-surface	Deep Chat	When your requirements outgrow the component's config options

Framework lock-in is rarely a problem if your whole team is on React. Architecture lock-in hurts when backend and frontend evolve at different speeds. Ecosystem lock-in you feel slowly — you start with useChat, six months later you're on Vercel hosting, each step made sense. API-surface lock-in only matters when your requirements outgrow the defaults.

I'll reference these types throughout the reviews so you can calibrate the tradeoffs for your situation.

What "chat UI" actually requires

"Messages going up, input at the bottom" — I thought the same thing. Then I started building. Here's the real scope:

Core: Token-by-token streaming without UI glitches, markdown + code blocks with syntax highlighting, a composer that auto-grows and handles Shift+Enter.

Interactive layer: File attachments (drag-and-drop + clipboard paste), feedback buttons for RLHF, a stop-generating button (you'll add this at 2 AM after your agent writes a 4,000-word essay about semicolons), model selectors.

Trust layer: Citations, reasoning traces, tool execution logs, cost estimates. Users increasingly expect to see why the AI said what it said.

The invisible stuff: Accessibility (WCAG, keyboard nav), theming that survives a designer, i18n.

Build all of that from scratch: 2–4 weeks, before a single line of agent logic. That's why this market exists.

The libraries

assistant-ui ⭐ ~7.9k — React, composable, headless — MIT

YC-backed. The library that shows up in every "build a ChatGPT clone" thread.

Follows the Radix headless pattern — unstyled primitives (Thread, Composer, Message) you compose yourself. State management is thoughtful, streaming is first-class, Vercel AI SDK integration is tight.

Who it's for: React + Next.js teams that want maximum control without implementing the hard parts. If your whole stack is React, this is the safe default — mature ecosystem, responsive maintainers, well-designed composability model.

Where it hurts: React-only (framework lock-in). Vue, Svelte, Angular, vanilla JS — not supported. "Headless" also means you do all the design work; getting a polished UI requires assembling many pieces and the learning curve is real.

Lock-in type: Framework.

CopilotKit ⭐ ~28.6k — React, agent framework with UI — commercial tiers available

Not just a UI library — an agentic application framework that includes UI components. Drop in <CopilotPortal />, get a full copilot experience. Agents can read your app state, call your functions, generate UI dynamically. They co-created AG-UI and partnered with Google on A2UI.

Who it's for: Greenfield projects where you're buying into their whole architecture. If you need deep agent-app state sync and generative UI, nothing else comes close.

Where it hurts: If all you need is a good chat interface, this is a flamethrower for a candle. More importantly: it's not just framework lock-in, it's architecture lock-in. You're adopting their agent execution model, state sync, action system — not just swapping in components. On brownfield projects with existing agent infrastructure, that means rethinking things you've already built.

Lock-in type: Architecture/runtime (the heaviest kind).

Vercel AI SDK + AI Elements — React, hooks + growing component layer — MIT

The AI SDK is everywhere: model-provider abstraction with useChat / useCompletion hooks. Not a UI library at its core, but Vercel has been expanding into actual components with AI Elements — composable React components on top of the SDK.

Worth mentioning separately: the Vercel AI Chatbot is the official open-source reference implementation built on this stack. Many teams use it as a starting point or benchmark for what a production chat UI looks like.

Who it's for: Anyone already in the Vercel ecosystem. AI Elements is worth evaluating alongside assistant-ui if you're on Next.js.

Where it hurts: The Vercel stack has gravitational pull. You start with useChat. Six months later you're on Vercel hosting. Each step made sense individually — the cumulative effect is ecosystem lock-in that's softer than CopilotKit's but real.

Lock-in type: Ecosystem.

TanStack AI — alpha, framework-agnostic hooks — MIT

TanStack — the team behind React Query, React Router, React Table — launched their AI toolkit. Framework-agnostic core, adapters for React, Solid, vanilla JS. Headless, type-safe.

Important context: this is alpha from a team with a strong track record of shipping production-grade, widely-adopted tools. That's different from "alpha from unknowns." If it matures the way React Query did, this will be a serious foundation layer.

Who it's for: Nobody in production yet. Watch this space.

Where it hurts: No pre-built UI components — hooks and utilities, not a chat interface. Vue and Angular adapters aren't there. Not ready for production today.

Google A2UI — declarative format for agent-generated UI

Agents send JSON describing which components to render; your frontend renders them from a trusted catalog. No executable code from the agent — no XSS nightmares. Framework-agnostic by design. Ships initial renderers for Lit, Angular, Flutter.

Who it's for: Teams building agent-generated dynamic UIs. The CopilotKit integration is worth watching, and this is one of the more interesting directions for generative UI / RSC-style patterns outside the React ecosystem.

Where it hurts: It's an infrastructure layer, not a component library. Not something you'd drop into a project and ship today.

Deep Chat ⭐ ~3.3k — Web Component, framework-agnostic — MIT

The one that made me sit up. A single Web Component for AI chat — framework-agnostic, built-in connections to OpenAI, HuggingFace, Cohere, Azure, Stability AI, AssemblyAI out of the box. Ships with speech-to-text, text-to-speech, file uploads, image handling.

Time-to-working-chat: under 10 minutes. No backend glue required to get started.

Who it's for: Prototypes, internal tools, non-React projects, or anywhere chat is a feature rather than the core experience. Best option when you need something working fast that doesn't care about your frontend framework.

Where it hurts: One component with configuration options, not a composable system. When you need to restructure layout, inject custom UI between messages, or add domain-specific controls — you're working within what the property API can express. Same tradeoff as any "convention over composition" approach: faster start, less flexibility when requirements diverge from defaults.

Lock-in type: API-surface.

Chainlit ⭐ ~11.4k — Python-first, full-stack

The go-to for Python developers who wanted a chat UI without touching JavaScript. Write your agent in Python, get a polished web UI with reasoning steps, file uploads, markdown.

Caveat: The original team stepped back from active development in May 2025. Community maintainers have picked it up. Worth verifying current project status before building on it.

One more thing: "Chat UI" is becoming "Agent UI"

Streaming is solved. Every library handles it well now — it's no longer a differentiator.

What's not solved is composition for agent-specific UI patterns: approval flows, reasoning traces, tool execution displays, cost transparency. These are becoming table stakes, not features. Libraries that only solve the messaging problem will feel incomplete within a year.

Generative UI (agents that emit UI, not just text) is the next frontier — watch A2UI + CopilotKit here, and the RSC patterns in the Vercel ecosystem.

Loquix — what I built, and why you probably shouldn't use it yet

Repeat disclosure: this is my library. Everything below is me describing my own work. The same "where it hurts" standard I applied above applies here too.

None of the options above fit my specific situation: a product where the customer's frontend framework isn't fixed, and I wanted composable building blocks rather than a monolithic widget or agent runtime.

So I built Loquix — a Web Components library on Lit, specifically for AI chat interfaces. (npm install @loquix/core)

The approach

35 individual Web Components that compose like this:

<loquix-chat-container>
  <loquix-chat-header slot="header">
    <loquix-model-selector slot="actions" />
  </loquix-chat-header>
  <loquix-message-list>
    <loquix-message-item role="assistant">
      <loquix-message-content streaming />
      <loquix-message-actions>
        <loquix-action-copy />
        <loquix-action-feedback />
      </loquix-message-actions>
    </loquix-message-item>
  </loquix-message-list>
  <loquix-chat-composer>
    <loquix-prompt-input />
    <loquix-drop-zone />
  </loquix-chat-composer>
</loquix-chat-container>

Verbose, yes. But when your designer says "move feedback above the message" — you move the component. No prop drilling, no checking if feedbackPosition is a valid prop value.

Backend integration is a type-only interface with no runtime dependency on any specific provider:

interface AgentProvider {
  send(messages: Message[], options?: SendOptions): Promise<{
    stream: ReadableStream<string>;
  }>;
}

Works in React, Vue, Svelte, Angular, vanilla JS. @loquix/react ships with proper wrappers for React's synthetic event system. Vue/Svelte dedicated packages are planned, not shipped.

Lock-in type: Platform (Web Components/Shadow DOM model, Lit if you extend components deeply) — just at the browser standards level rather than the library level.

Where it hurts — same standard as above

No production deployments. I can't point you to a production app using Loquix. That's a significant unknown that none of the other libraries in this review share.

Small community. No Stack Overflow answers. You'll be reading source code.

Incomplete roadmap. Reasoning traces, citations, cost estimates — Phase 4 and 5 — still in development. If you need those today, build them yourself or wait.

Lit learning curve. Consuming is easy. Deep customization requires understanding Lit's reactive model and Shadow DOM. React developers find this counterintuitive at first.

No built-in provider integrations. Deep Chat connects to OpenAI in 10 minutes. assistant-ui integrates with Vercel AI SDK out of the box. Loquix gives you a TypeScript interface and says "implement it." Better for experienced teams; more friction for everyone else — the same critique I'd apply to any library that takes this approach.

Concrete example where assistant-ui wins: chat UI integrating with Vercel AI SDK's useChat, rendering generative UI streamed from server, thread persistence, all in Next.js. With assistant-ui: well-documented, battle-tested. With Loquix: you'd be wiring streaming yourself, no RSC integration (Web Components and React Server Components don't mix naturally), and you'd be the first person to try this combination in production. Hard to justify.

If your situation is specifically "multi-framework team that wants composable components and is willing to be an early adopter" — evaluate it. Otherwise, the options above are more pragmatic.

The decision table

Situation	Recommendation	Maturity
React + Next.js	assistant-ui	✅ Production-ready
Full agent framework, generative UI	CopilotKit	✅ Production-ready
Provider abstraction + React	Vercel AI SDK + AI Elements	✅ Production-ready
Quick prototype, non-React, embedded widget	Deep Chat	✅ Production-ready
Python-first backend	Chainlit	⚠️ Check project status
Multi-framework + composable, early adopter	Loquix	🚧 No production deployments
Agent-generated dynamic UI	A2UI + CopilotKit	👀 Watch this space

Greenfield vs. brownfield: heavier frameworks (CopilotKit, Vercel full stack) accelerate you on greenfield when you're choosing everything fresh. Thinner UI layers (assistant-ui, Deep Chat, Loquix) cause less friction on brownfield where the architecture already exists.

The days of spending weeks building chat UI from scratch are over. Pick a library, commit, and spend your engineering time on the thing that actually differentiates your product.

If I missed a library you've used in production, drop it in the comments.

Unless you enjoy writing auto-scroll logic at 2 AM. In which case, I have a useEffect cleanup function I'd like to sell you.