Live data from Hacker News

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

qitejs.qount25.dev

131–140 of 168 posts

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

#131

[flagged]

I've been building out a fairly complex app. I decided to avoid Next.js some I went with a simple Hono + Tanstack Router/query. With Vite 8, my build time is about ~0.8s. I've also go a much simpler Next.js app with a build time of 45s.

That stack is such a breath of fresh air. And so easy to deploy anywhere.

I do love the idea of a batteries included framework for the JS ecosystem, like the mythical Rails for node, but as long as we're gluing random stuff together... This is a really nice combo. I also love using Hono and React/Vite with TRPC.

I stopped working with Next a few years ago, so I can't comment very fairly on recent changes in the framework. However, it does appear as though it has become even more complex, and that was a significant art of what steered me away. The other part was simply a lack of cohesion with design decisions and direction. The middleware layer seemed like a poor design. Various opinions around things like default cache policies felt incorrect. I found myself battling their decisions too often, for too little benefit.

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

#132

> https://qitejs.qount25.dev/Ajax.html Oh my. If it works just like Ajax from >10-15 years ago, then I will be super happy. :D

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.

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

#133
post #11

Earlier quoted context omitted.

Why is that a bad argument? The author strongly dislikes React and so wrote an alternative that is radically more simple, which sounds like a perfectly sane argument.

Does the author dislike react? How about preact? Or maybe simply jsx? Or nextjs? There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.

"hate" is not even an argument. It is obviously for those who dislike React or put it in another way: do not like to or would rather not work with React.

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

#134
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'd argue that it was all downhill after we moved away from using HTML as the state representation. Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync. Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and conve…

State in HTML is a horrible mistake. Now everything has to be constantly serialized/deserialized into strings.

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

#135

> https://qitejs.qount25.dev/Ajax.html Oh my. If it works just like Ajax from >10-15 years ago, then I will be super happy. :D

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.

Fair enough. Even better!

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

#136

Earlier quoted context omitted.

I'd argue that it was all downhill after we moved away from using HTML as the state representation. Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync. Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and conve…

State in HTML is a horrible mistake. Now everything has to be constantly serialized/deserialized into strings.

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.

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

#137

I must have overlooked the site, but are there any working examples?

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:

https://code.qount25.dev/qite/qite-js/src/branch/master/src/...

https://code.qount25.dev/qite/qite-js/src/branch/master/test...

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

#138
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
Post reply on HN