This is both silly and somewhat off-topic, but on the subject of doing database work on the client side ... has anyone experimented with using non-rendered DOM as 'table' and CSS selectors as 'query language'?

I'm not talking about 'using the DOM to store data' in the traditional sense. The idea is rather (roughly) to store each database 'table' as a child of a hidden DocumentFragment, with 'rows' as its children, etc. Then we'd query this data using CSS selectors (or XPath).

For example, instead of

  SELECT * FROM Employees WHERE gender = 'male' AND age > 30

you'd have something like:

  customersTbl.querySelectorAll('row:has(cell-gender[value="male"]):has(cell-age[value > "30"])')

And instead of

  SELECT * FROM Employees WHERE gender = 'male' OR age > 30

you'd have something like:

  employeesTbl.querySelectorAll('row:has(cell-gender[value="male"], cell-age[value > "30"])')

You can even have (truly) structured cells! Instead of

  SELECT * FROM Employees WHERE name->>'first_name' = 'John'

you can have:

  employeesTbl.querySelectorAll('row:has(cell-name:has(cell-first_name[value="John"]))')

And for querying array-like structures, instead of:

  SELECT * FROM employees WHERE skills::jsonb ? 'JavaScript';

you can have:

  employeesTbl.querySelectorAll('row:has(cell-skills > cell-skill[value="JavaScript"])')

I can certainly imagine the performance to be horrible, but having never tried out the idea (and having too meager a mental model of DOM performance to reason from) I can also imagine it being surprisingly decent for smaller datasets. Who knows? :-)

Edit: silly me indeed to think CSS attribute selectors already can do numeric comparisons! See here: https://github.com/w3c/csswg-drafts/issues/354