Does qnot do everything RAQB does?

Nearly. Field types, structs, list groups with counts, functions on both sides, field references, custom operators, locks, read-only modes, switch cases and every RAQB export format are covered and tested. Not carried over: custom conjunctions (XOR, NOR), paged "load more" for async lists, validateValue returning a fixed value, and slider marks.

Can I keep my saved RAQB trees?

Yes. With format: raqb the store's value / onChange read and write RAQB's JSON tree (QbUtils.getTree output), including rule_group list groups, functions mapped to RAQB's basic functions, and locks.

Do I still need Immutable.js?

No. qnot keeps the query as plain JSON, structurally shared, so unchanged parts keep their identity between edits. There is no Immutable.js and no Redux.

What about my antd or Fluent widgets?

RAQB ships widget packages for Ant Design, MUI, Bootstrap and Fluent. qnot ships builders for coss ui, shadcn/ui and MUI, plus a headless one to restyle. For Ant Design or Fluent you build the controls from the hooks; the headless kit shows how small that file is.

compare

qnot vs react-awesome-query-builder

react-awesome-query-builder is one of the most complete React query builders, and qnot was built to match it feature for feature. The differences: qnot runs outside React, keeps the query as plain JSON, adds undo and in-JS evaluation, and is a fraction of the size. It also reads and writes RAQB trees.

Switching

@react-awesome-query-builder/ui 6.6 · MIT

licenseqnot: MITreact-awesome-query-builder: MIT

first render, 1,000 rulesqnot: 131 msreact-awesome-query-builder: 598 ms

keystroke, 1,000 rulesqnot: 0.5 msreact-awesome-query-builder: 7.8 ms

JS, gzippedqnot: 25.2 KBreact-awesome-query-builder: 194 KB

Feature by feature.

What each library does out of the box, from its docs, its package contents and our own harness. Where it says no, an add-on or your own code may still get you there.

Features of qnot and react-awesome-query-builder
feature	qnot	react-awesome-query-builder
License	MIT	MIT
UI frameworks	React, Vue, Svelte, Solid and plain DOM (qnot ahead)	React
Widget sets	coss ui, shadcn/ui, MUI and headless builders as source	Ant Design, MUI, Bootstrap, Fluent and vanilla widget packages (react-awesome-query-builder ahead)
State	Plain JSON, normalized store with per-node subscriptions	Immutable.js tree; JSON through QbUtils.getTree
Field types	text, number, boolean, date, time, datetime, enum, multi-enum, tree options, struct, list	The same set
Functions and field references	On either side of a rule, nestable	On either side of a rule, nestable
List groups and counts	some / all / none / count	some / all / none / count
Custom conjunctions	AND, OR, NOT only (NOR is NOT + OR)	Configurable, e.g. XOR and NOR (react-awesome-query-builder ahead)
Async options	search(query, signal), custom values	asyncFetch with paged "load more" (react-awesome-query-builder ahead)
Undo and redo	Built into the store (qnot ahead)	No
Evaluate in JS	compile() / matches() (qnot ahead)	No
Export	SQL (5 dialects, bound params), MongoDB, JsonLogic, Elasticsearch, SpEL, text	SQL, MongoDB, JsonLogic, Elasticsearch, SpEL, query string
Import	SQL WHERE, MongoDB, JsonLogic, SpEL, RAQB tree	SQL, JsonLogic, SpEL, tree
Add a rule at 1,000 rules	0.8 ms (qnot ahead)	101 ms

Measured at 1,000 rules.

The same tree in both, production builds, headless Chromium. The largest gaps are adding a rule (101 ms against 0.8 ms) and size: RAQB is 194 KB of gzipped JavaScript without React, qnot 25.2 KB, both counting their SQL export.

qnot and react-awesome-query-builder at 1,000 rules
library	first render	keystroke	add a rule	memory	js, gzipped
qnot0.1@qnot/react	130.7ms	0.5ms	0.8ms	13.6MB	25.2KB
react-awesome-query-builder6.6@react-awesome-query-builder/ui	598.2ms	7.8ms	101ms	37.7MB	194KB

Run of 2026-10-19: Apple M5, Chromium 156 via Playwright 1.64, production builds, no CPU throttling. Medians of fresh pages (5 to 9 per size); the tree is 10 fields in groups of 10 rules. JS is gzipped and excludes React for React libraries (jQuery is included). Lower is better. react-awesome-query-builder takes 4.6× as long to render. The harness, its method and every size.

When react-awesome-query-builder is the better choice.

An honest list. If one of these is you, react-awesome-query-builder may serve you better.

You use Ant Design or Fluent. RAQB's widget packages give you a builder in your kit with no UI code of your own.
You need XOR or NOR conjunctions, paged "load more" async lists, validateValue that rewrites values, or slider marks. qnot has none of these.
You have a large, working RAQB config and no performance problem. The migration is mostly mechanical, but it is still work.
You want a longer track record. RAQB has been used in production for years by many teams.

Switching.

Give the store format: raqb. Its value and onChange speak RAQB's JSON tree, so stored trees keep loading and keep being saved in the same shape.

Filters.tsx

'use client';
import '@qnot/core/styles.css';
import { defineFields, f } from '@qnot/core';
import { raqb, type RAQBGroup } from '@qnot/core/formats/raqb';
import { QueryBuilder } from '@qnot/react';
import { useState } from 'react';

const fields = defineFields({
  name: f.text(),
  age: f.number({ min: 0, integer: true }),
  address: f.struct({ city: f.text(), zip: f.text() }),
  orders: f.array({ status: f.enum(['paid', 'pending']), qty: f.number() }),
});

// tree: what QbUtils.getTree(immutableTree) gave you, stored as JSON.
export function Filters({ tree }: { tree: RAQBGroup }) {
  const [value, setValue] = useState(tree);
  return <QueryBuilder fields={fields} format={raqb} value={value} onChange={setValue} />;
}

The config becomes a schema: type: 'select' is f.enum(), !struct is f.struct(), !group is f.array(), asyncFetch is search, settings become store settings.

QbUtils.sqlFormat and friends map to encode with the matching codec. The migration guide has the full table, and the playground shows every RAQB feature on one schema.

Questions people ask

Does qnot do everything RAQB does?: Nearly. Field types, structs, list groups with counts, functions on both sides, field references, custom operators, locks, read-only modes, switch cases and every RAQB export format are covered and tested. Not carried over: custom conjunctions (XOR, NOR), paged "load more" for async lists, validateValue returning a fixed value, and slider marks.Migrating from RAQB
Can I keep my saved RAQB trees?: Yes. With format: raqb the store's value / onChange read and write RAQB's JSON tree (QbUtils.getTree output), including rule_group list groups, functions mapped to RAQB's basic functions, and locks.
Do I still need Immutable.js?: No. qnot keeps the query as plain JSON, structurally shared, so unchanged parts keep their identity between edits. There is no Immutable.js and no Redux.
What about my antd or Fluent widgets?: RAQB ships widget packages for Ant Design, MUI, Bootstrap and Fluent. qnot ships builders for coss ui, shadcn/ui and MUI, plus a headless one to restyle. For Ant Design or Fluent you build the controls from the hooks; the headless kit shows how small that file is.Headless builder