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.
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.
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:
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?
Btw, looking back at the index page, I think I might have made the initial example a little bit too much (because realistically, you don't often get components that complex). If you guys want a simpler saner example, the one the second page looks nicer: https://qitejs.qount25.dev/Explained-by-ducks.html
Yeah, several apps have been built with it, but they're not public (or not public yet). Also, Qite.js has a number of prebuilt-components. I haven't gotten around documenting them, but you can find working example here:
It's a bit more nuanced than that. State in Qite is held both in HTML and in JS Component. The html serialization is sort of consequence of changing a field (like when you want to update textarea content, for example). You can completely ignore it or you can also use it for CSS, for example. Another usecase is when user interacts with the pages, changes text in said textarea and it also automatically updates the JS Component field. Finally, there are also flags, which aren't stored in DOM. I'd like to point out this architecture isn't random, it came from building apps and realizing how everything interacts.
It works better than "just like" in the sense that it also takes care of things like CSRF, POST/GET params, request/response types etc for basically free.
As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.
> As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process
And yet, plenty of people all around the world are able to get traction for their products without mentioning the hate of another.
> I didn't build Qite because I hate React,
I get that React being the most popular front-end framework means it's going to get it's fair share of criticism, but it's become pathetic the degree to which people have made hating it their personality. Even going so far as to market their own frameworks in terms of their personal feelings towards it.
Nobody is saying humans aren't emotional, you're trying to deflect from being unable to disconnect your emotions from another library.
React got popular not because of its amazing time-tested ideas (everyone knows they re-engineer everything once every couple years!), but, strictly speaking, because at the time it was released there wasn't any kind of serious SPA or partially-SPA framework for the web and also because JavaScript sucked a lot more at the time (no classes!). Qite is perfectly suitable for complex UIs thanks to its state functionality, you can build pretty complex functionality and UI and not sacrifice user's CPU in the process.
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.
reply