Qite.js – Frontend framework for people who hate React and love HTML • Hacker News Board

Re: Qite.js – Frontend framework for people who hate React and love HTML

#141

Post by [deleted] » Tue, Mar 24, 2026, 9:10 PM UTC

usrbinenv wrote: post #122

dmix wrote: post #107

Rails does this perfectly with Turbo and Stimulus, Turbo does HTML-over-the-wire via SSR-first, server responds with small updates/appends of HTML as need etc, and then you lightly use stimulus JS controllers for the small stuff where HTML/forms don't make sense. https://hotwired.dev/

While it's definitely possible to build similar website with Turbo and Stimulus it would absolute NOT be the same thing and the mechanics of it would be radically different. I would argue using SSR at all times (and, consequently, workarounds like Hotwire, which make it look like it's not SSR) is the same kind of sin as using React for SPAs for personal blogs (i.e. things, SPAs don't belong to).

[deleted]

Re: Qite.js – Frontend framework for people who hate React and love HTML

#142

Post by sureglymop » Tue, Mar 24, 2026, 9:10 PM UTC

applfanboysbgon wrote: post #17

hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely.…

This made me immediately think of the Elm architecture.

To an extent this is how react works internally. There is a function which takes state and produces UI. In order not to have to re-render the whole UI if only a small part of the state changes, there is a diffing algorithm and "virtual dom" that is diffed against. Maybe it doesn't work exactly like that anymore but that's the gist of it.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#143

Post by usrbinenv » Tue, Mar 24, 2026, 9:14 PM UTC

QubridAI wrote: post #139

[flagged]

Thank you. Since you had this positive reaction to which I very much relate, may I ask you what did you personally think was confusing in the docs that may still turn people away?

Re: Qite.js – Frontend framework for people who hate React and love HTML

#144

Post by usrbinenv » Tue, Mar 24, 2026, 9:22 PM UTC

jwlake wrote: post #140

The "isPresent()" in the example gives me alot of ick. It's confusing why thats not actual javascript.

Yeah, I get the reaction. It's not JavaScript, it's simply a way to reference a matcher for the value, not match against literal value. You can totally use your custom matcher like this:

    total: (c,v) => v > 1000

See the docs: https://qitejs.qount25.dev/States/Field-Matchers.html

Re: Qite.js – Frontend framework for people who hate React and love HTML

#145

Post by usrbinenv » Tue, Mar 24, 2026, 9:23 PM UTC

jfengel wrote: post #33

eknkc wrote: post #18

I thought I hated React until I saw the samples on this page...

Any time I see code in quotes I get the heebie jeebies. Code in quotes can't even be syntax checked until run time.

What you probably saw isn't code in quotes, but simply matchers like `price: "isPresent()"`. The () is there to signal it's a matcher, not a value. If this matcher doesn't exist, you'll get an error. The reason I chose () to signal it's a matcher is to distinguish it from values. Maybe there's a better way to do it.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#146

Post by hungryhobbit » Tue, Mar 24, 2026, 9:26 PM UTC

ivanjermakov wrote: post #16

hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

I still believe immediate rendering is the only way for easy-to-reason-about UI building. And I believe this is why early React took off - a set of simple functions that take state and output page layout. Too bad DOM architecture is not compatible with direct immediate rendering. Shadow DOM or tree diffing shenanigans under the hood are needed.

Yes! I think there's a lot of armchair web developers in these comments who think they know better: they don't.

Meanwhile, those of us that were building web apps with JQuery and other tools prior to React know just how painful "web development without reactivity" actually was.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#147

Post by proc0 » Tue, Mar 24, 2026, 9:26 PM UTC

And we've come full circle, haha.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#148

Post by n0t3ths81 » Tue, Mar 24, 2026, 9:33 PM UTC

kitd wrote: post #89

voidUpdate wrote: post #64

At some point, someone is going to come out with a no-JS, no-NPM, no-SSR framework and we're just going to have invented HTML again

HTMZ? ;) https://leanrada.com/htmz/

[dead]

Re: Qite.js – Frontend framework for people who hate React and love HTML

#149

Post by usrbinenv » Tue, Mar 24, 2026, 9:34 PM UTC

bartwaardenburg wrote: post #2

The fields/flags state model is a nice idea, having structured values separate from boolean state is something I haven't seen in other frameworks. How does this compare to Alpine.js or htmx in practice? They're in a similar space (no build, SSR-first) but I'm curious what made you go with a new framework rather than building on top of those?

Alpine/htmx are great, but they're more "sprinkle behavior on HTML" tools. Qite is closer to a structured component system: explicit events, a state engine, and a consistent way to wire parts/fields/children together without ad-hoc glue.

You can build similar things with Alpine/htmx, but once things grow, you end up reinventing structure. Qite just bakes that in from the start.

Re: Qite.js – Frontend framework for people who hate React and love HTML

#150

Post by vlod » Tue, Mar 24, 2026, 9:43 PM UTC

neya wrote: post #46

hliyan wrote: post #14

I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That int…

Absolutely. Look at facebook today. Back in 2010, everything had just the right amount of interactivity. Because, separation of concerns existed at the language level - HTML for structure and CSS for presentation, JS for everything else. Then some bunch of geniuses decided it would be awesome to put everything together in the name of components. Today, you open facebook, the creators of React - normal drop-down with…

> React is the worst thing to happen to the Javascript ecosystem. The idea is good, but the execution is just piss poor. I mean look at Vue and Svelte, they managed to do it right.

As a previously big React dev I agree 100%. If anyone feels this way please spend some time on doing Sveltekit project (e.g. rewrite a personal React project).

It's a breath of fresh air.