Can qnot load the rules I saved from jQuery QueryBuilder?

Yes. Create the store with format: jqqb and initial set to your saved getRules() output. store.getValue() keeps returning the same { condition, rules } shape, so the server side doesn't change.

Do I need jQuery or Bootstrap?

No. @qnot/dom uses plain DOM APIs and ships a small stylesheet of its own. If the rest of your app uses Bootstrap, the builder sits next to it without conflict.

Can I switch one page at a time?

Yes. Both builders can live in the same app, and because qnot speaks the same JSON, a query saved by one page loads in the other.

Is jQuery QueryBuilder still a good choice?

For a jQuery app with modest queries, yes. It is mature, MIT licensed and its plugins cover SQL, MongoDB, drag and drop and NOT groups. It slows down on very large queries: about 0.9 s to render 1,000 rules in our run.

compare

qnot vs jQuery QueryBuilder

jQuery QueryBuilder has served jQuery apps well for more than a decade. qnot does the same job without jQuery or Bootstrap, adds typed values, undo and more export formats, and stays fast on large queries. It reads and writes the same JSON, so saved rules keep working.

Switching

jQuery-QueryBuilder 3.0 · MIT

licenseqnot: MITjQuery QueryBuilder: MIT

first render, 1,000 rulesqnot: 117 msjQuery QueryBuilder: 868 ms

keystroke, 1,000 rulesqnot: 0.4 msjQuery QueryBuilder: 10.1 ms

JS, gzippedqnot: 25.7 KBjQuery QueryBuilder: 68.9 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 jQuery QueryBuilder
feature	qnot	jQuery QueryBuilder
License	MIT	MIT
Depends on	@qnot/core only (qnot ahead)	jQuery, Bootstrap 5 and Bootstrap Icons (dependencies of 3.0)
Frameworks	Plain DOM, plus React, Vue, Svelte and Solid bindings on the same store (qnot ahead)	jQuery plugin
SQL	Export in five dialects with bound params; import of WHERE clauses	sql-support plugin: export and import
MongoDB	Export and import	mongodb-support plugin
Also exports	JsonLogic, Elasticsearch, SpEL, plain English (qnot ahead)	No other formats built in
Drag and drop	Built in	sortable plugin
NOT groups	Built in	not-group plugin
Undo and redo	Built into the store (qnot ahead)	Not included
Functions, list groups, field references	Yes (qnot ahead)	Not built in
TypeScript	Written in TypeScript; rule values typed by the schema (qnot ahead)	JavaScript, no bundled type definitions
First render, 1,000 rules	117 ms (qnot ahead)	868 ms

Measured at 1,000 rules.

jQuery QueryBuilder renders plain DOM, so the fair comparison is qnot's framework-free build, @qnot/dom; the React build is listed too. At 1,000 rules the first render takes 868 ms against 117 ms. Its sizes include jQuery and, for CSS, Bootstrap.

qnot and jQuery QueryBuilder at 1,000 rules
library	first render	keystroke	add a rule	memory	js, gzipped
qnot, no framework0.1@qnot/dom	117ms	0.4ms	0.7ms	4.8MB	25.7KB
qnot0.1@qnot/react	130.7ms	0.5ms	0.8ms	13.6MB	25.2KB
jQuery QueryBuilder3.0jQuery-QueryBuilder	868.4ms	10.1ms	3.5ms	2.2MB	68.9KB

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. jQuery QueryBuilder takes 7.4× as long to render. The harness, its method and every size.

When jQuery QueryBuilder is the better choice.

An honest list. If one of these is you, jQuery QueryBuilder may serve you better.

Your app is built on jQuery and Bootstrap. The plugin fits the way the rest of the page already works, and its look matches.
Your queries are small. At ten rules it renders in about 26 ms and a keystroke is a tenth of a millisecond. There is nothing to gain on speed.
Its plugins already do what you need. SQL and MongoDB import and export, sortable rules, NOT groups, unique filters and filter descriptions are all there, and it has years of use behind it.

Switching.

Create the store with format: jqqb. It loads the JSON that getRules() returned, and getValue() gives the same shape back.

filters.ts

import '@qnot/core/styles.css';
import { createQueryStore, defineFields, f } from '@qnot/core';
import { jqqb, type JQQBGroup } from '@qnot/core/formats/jqqb';
import { mountQueryBuilder } from '@qnot/dom';

declare const saved: JQQBGroup; // what $('#builder').queryBuilder('getRules') gave you
declare function save(rules: JQQBGroup): void;

// before: $('#builder').queryBuilder({ filters, rules: saved });
const fields = defineFields({
  name: f.text(),
  age: f.number({ integer: true }),
  status: f.enum(['active', 'pending', 'closed']),
});
const store = createQueryStore({ fields, format: jqqb, initial: saved });
mountQueryBuilder(document.getElementById('builder')!, store);

// getValue() is still { condition: 'AND', rules: [...] }, so your API doesn't change.
store.subscribe(() => save(store.getValue()));

Filters become a schema: type: 'integer' is f.number({ integer: true }), input: 'select' with values is f.enum(), a radio of yes / no is f.boolean().

Operators map by name: equal to eq, begins_with to startsWith, is_null to isNull. See the vanilla guide for mounting options.

Questions people ask

Can qnot load the rules I saved from jQuery QueryBuilder?: Yes. Create the store with format: jqqb and initial set to your saved getRules() output. store.getValue() keeps returning the same { condition, rules } shape, so the server side doesn't change.
Do I need jQuery or Bootstrap?: No. @qnot/dom uses plain DOM APIs and ships a small stylesheet of its own. If the rest of your app uses Bootstrap, the builder sits next to it without conflict.
Can I switch one page at a time?: Yes. Both builders can live in the same app, and because qnot speaks the same JSON, a query saved by one page loads in the other.
Is jQuery QueryBuilder still a good choice?: For a jQuery app with modest queries, yes. It is mature, MIT licensed and its plugins cover SQL, MongoDB, drag and drop and NOT groups. It slows down on very large queries: about 0.9 s to render 1,000 rules in our run.