Qite.js (Explained by Ducks)
Duck sees webpage.
Duck says: why page ugly and stupid?
Other duck says: because modern frontend made of 84 layers of sadness.
Then Qite.js waddles in — it's basically: "What if JavaScript framework, but not insane?"
HTML is already pretty good, quack
Big duck says: "Why invent fake HTML inside JavaScript inside build step inside Vite inside npm explosion?"
Qite says:
- Just use actual DOM.
- Actual HTML.
- Real page.
- Touch grass.
So instead of pretending the browser does not exist, Qite works with it:
<div data-component="Greeting">
<span data-field="message">Hello, duck.</span>
</div>
Browser already understands this. Qite uses this, instead of declaring war on it.
Components, but not React-brained
Small duck points at thing on page: "That box there. Is it a component?"
Yes.
Qite lets you define components from normal DOM structure and attach behavior to them. So duck clicks dropdown. Dropdown knows it is dropdown. No spiritual ceremony required.
<div data-component="Dropdown">
<button data-part="toggle">Open</button>
<menu data-part="menu" hidden>
<li>Profile</li>
<li>Settings</li>
<li>Log out</li>
</menu>
</div>
Duck makes it work with:
export default class DropdownComponent extends BaseComponent {
constructor(tree_node) {
super(tree_node);
this.events.add([
"click", "#toggle", () => this.toggleMenu()
]);
}
toggleMenu() {
let tgl = this.part("toggle");
if (tgl.textContent === "Open") {
this.ui.show("#menu");
tgl.textContent = "Close"
} else {
this.ui.hide("#menu");
tgl.textContent = "Open";
}
}
}
That is the basic duck idea: markup first, behavior attached after.
DOM-first
A lot of frameworks say: "Real UI is fake tree in memory. Browser is just output device."
Qite says: "No, idiot. Browser already has the UI." So Qite thinks in:
- elements
- attributes
- fields
- children
- actual page structure
Duck can inspect page and understand what is happening. Huge win bigly.
When duck inspects the page, duck sees the actual structure:
<div data-component="Notification" data-type="success">
<div data-field="subject">Saved</div>
<div data-field="message">Your settings were updated.</div>
</div>
Not a hallucination. Not an invisible philosophy object. The actual thing.
State, but understandable by birds
In many frameworks: "State update caused rerender caused effect caused stale closure caused therapy."
With Qite, Duck says:
- When this field has value X, show this.
- When loading, disable button.
- When dialog open, display overlay.
This is state rules. Clear. Declarative. No duck sacrifices.
<form data-component="SearchBox">
<input data-field="query" />
<button data-component="Button" data-roles="submit">Search</button>
<div data-part="spinner" hidden>Loading...</div>
</form>
Then duck writes:
static states = [
[
{ fields: { loading: true } }, [ "#spinner" ],
{ fields: { loading: false } }, [ ">submit" ]
]
];
When loading is true, spinner appears, button stops being pokable. Very duck in spirit.
Ajax without 900 abstractions
Duck presses button. Request goes out. HTML or JSON comes back. Page updates.
Duck happy.
Qite never acts like network requests are a branch of theoretical physics. It treats them like: "send thing, get thing, update thing." Correct duck mindset.
let response = await Ajax.post("/messages", {
body: { text: "quack" }
}).ready();
console.log(response.json);
No epic quest. No sacred fetch wrapper monastery. Just request, response, done.
Duck says: "Thank you".
Strictness: duck-proofing
Some components expect:
- certain fields
- certain child parts
- certain roles
- maybe a certain parent
Duck tries to use this component:
export default class ConfirmDialogComponent extends BaseComponent {
static strict = {
parts: ["title", "body"],
children: [{ roles: "yes" }, { roles: "no" }]
};
}
If markup is wrong, Qite complains.
So duck forgets the "yes" button in confirmation dialog. Qite says: "No. Bad duck. Dialog malformed."
This is good because otherwise duck debugs nonsense for 2 hours.
Now duck write correct HTML:
<div data-component="ConfirmDialog">
<div data-part="title">Delete file?</div>
<div data-part="body">This cannot be undone.</div>
<button data-role="yes">Yes</button>
<button data-role="no">No</button>
</div>
If duck removes the "no" button, Qite can warn immediately instead of letting chaos take over quitely.
No build-step religion
Important duck principle: if webpage needs six daemons, seventeen plugins, and a lunar alignment to run, it is bad.
But Qite says "Can we just write JavaScript and ship it?" That's strong duck energy. Is spiritually healthy.
Basic page be like:
<!doctype html>
<html>
<head>
<script type="module" src="/app.js"></script>
</head>
<body>
<div data-component="Dropdown">
<button data-part="toggle">Open</button>
<menu hidden>
<li>One</li>
<li>Two</li>
</menu>
</div>
</body>
</html>
Then basic JavaScript is:
import Qite from "./src/qiteinit.js";
import DropdownComponent from "./src/components/dropdown/dropdown_component.js";
import "./src/qite.js";
That is a webpage. It runs. The duck lives.
Why ducks like it
Because ducks hate:
- build errors
- JSX hallucinations
- hydration mysteries
- "why is this rerendering"
- npm civil war
Ducks like:
- page exists
- component found
- click works
- state visible
- rules clear
- less crap
Final duck summary
Qite.js is like a frontend framework made by a duck who got tired of humans making web development embarrassing.
It says:
- use the DOM
- keep components simple
- make state readable
- make markup matter
- avoid unnecessary machinery
- stop pretending every button is a NASA launch
- enjoy SSR, don't overdo SPAs
So duck opens page. Duck sees structure. Duck understands structure. Duck changes structure. Page works.
Duck ascends.