FAQ

This page might help you better understand if Qite is something you might want to use without diving deeper into the documentation and details.

Is this just jQuery with classes?

No. Qite is structured around a component hierarchy. Each component is bound to a specific DOM node and participates in a tree. Events flow through that tree, states are declarative and state is re-evaluated when fields or flags on a component change. Fields and flags are also synchronized with the DOM.

You are not going to be manually querying the entire document and mutating random nodes — instead you'll be working inside a defined component boundary and hierarchy.

In short: Qite manipulates the DOM directly, but in a structured and predictable way.

How is this different from React, Vue or Svelte?

Qite does not maintain a virtual DOM. It does not re-render components, it never compile templates and there's no such term in Qite (except for the HTML-native template elements, which are used to instantiate additional components not loaded with the page). Qite does not require any kind of bundler.

The DOM remains the source of truth. When something changes, the DOM is updated immediately and there is no diffing phase and no render cycle abstraction. Instead of render functions and component re-evaluation, Qite uses a declarative state engine and explicit events.

Is direct DOM manipulation slow?

No. Modern browsers are heavily optimized for DOM operations. Virtual DOM frameworks still end up touching the real DOM — they just simulate it first and then reconcile. Qite, on the other hand, skips the simulation layer.

In practice, updating exactly what needs to change is fast and predictable. You'll probably feel how fast Qite is compared to React on two levels: rendering, but also its load time.

Can I use this in a large application?

Yes. Qite scales through hierarchy: components form trees, parents coordinate logic, while states remain declarative. Child components have roles to help organize communication. All this works naturally with server-side rendering, but you can also build a full SPA if that fits your architecture.

Does Qite include routing?

No. Routing is intentionally left out. In most applications, server-side routing is simpler and more reliable. If you need client-side routing, you can add it, but this is an anti-pattern, which hijacks browsers and isn't very reliable. A sane recommendation is to use SSR where it makes sense, then make some pages of your app behave more like an SPA with Qite.

Does this replace CSS frameworks?

No. Qite does not try to replace CSS or styling systems. It relies on standard CSS for layout, appearance and transitions in those few standard components it provides out of the box, but also plays nice with hide/show transitions and animations you may define in your CSS for standard and custom components you create. You can use plain CSS or any CSS-framework you prefer.

Why no npm?

You can use npm if you want to add something you need, but it is not required. Qite is a single repository. It is recommended that you add it as a git submodule or even copy it as a standard way of adding it into your project. There is no mandatory build pipeline and no dependency chain.

Is it production ready?

Yes. Qite is self-contained, small, and does not depend on complex tooling. Its simplicity is intentional.

Do I need a separate state management library?

No. Qite already provides fields, flags and a declarative state engine. In most applications, that is enough to model UI state cleanly. If you truly need global shared state, you can implement it, however Qite does not require an additional state management layer to function properly.

Does Qite work with TypeScript?

Yes. Qite is written as plain ES modules (JavaScript), but you can use TypeScript, to write your own components and there's nothing in Qite that prevents that. The real question is why would you? Qite philosophy is "no build" and less ceremony and TypeScript definitely introduces both.

If you write your unit-tests and follow Qite philosophy and structure, you should be able to ship complex apps with or without TypeScript.

Is this based on Web Components?

No. Initially, at early stages of development, Qite tried to support Web Components, but for various technical and ergonomic reasons it was ultimately decided not to use them.

Qite does not require custom elements and does not depend on the Web Components standard. It attaches behavior to regular DOM nodes using data-component. If you use Web Components elsewhere in your project, Qite can coexist with them, but it simply doesn't rely on them.

How do I test components?

Components in Qite are plain JavaScript classes. They can be instantiated and tested directly. The Qite repository itself has extensive unit tests. You can look into the test/ directory for concrete examples of how components, states, events and other parts of the framework are tested.

If you are writing custom components, the tests in that directory are the best reference for structuring your own tests. Qite has strong test coverage and treats tests as part of its public contract.

What should or should not be a component?

A component should represent a meaningful UI boundary.

Good candidates:

• A form.
• A dialog.
• A reusable widget.
• A complex interactive section.
• A container for other components.

Not everything needs to be a component. Static markup does not, but it can instead be component field or component part. A single button with no behavior does not, but might be.

Components are useful when there is behavior, state or coordination involved. If a piece of UI has no logic, it can remain plain HTML. Use components where structure and behavior benefit from being encapsulated. Do not turn every <div> into one.