Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

qitejs.qount25.dev

Post reply on HN
Print view View original

11–20 of 168 posts

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

#11

Post by bestest »

austin-cheney wrote: post #10
febusravenga wrote: post #5

"If you hate react" feels like very bad argument in engineering. Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.

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.

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

#12

Post by ale »

Build steps are realistically speaking inevitable because of minification, tree-shaking, etc. which is not even a big deal these days with tools like esbuild. For a "true" DOM-first component reactive system just use Web Components and any Signals library out there and you're good.

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

#14

Post by hliyan »

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 introduced state management. It was all downhill from there (starting with two way data binding, Flux architecture, Redux, state vs. props, sagas, prop drilling, hooks, context API, stateful components vs. stateless components, immutability, shallow copy vs. deep copy, so on and so forth).

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

#15

Post by tobr »

bestest wrote: post #11
austin-cheney wrote: post #10

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.

Your argument that it’s a shallow argument is itself a shallow argument. ”I hate x” is not a technical argument anyway, it’s an emotional assessment.

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

#16

Post by ivanjermakov »

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.

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

#17

Post by applfanboysbgon »

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. The mental model is so easy to work with. There is a sleep-management routine to save on CPU usage when idle, and dirty logic to avoid re-drawing static content constantly. I feel like the world would save 90% of its GUI development time if it didn't do whatever the fuck reactive UIs are doing.

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

#19

Post by hliyan »

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.…

That reminded me of another complexity: virtual DOM diff.
Post reply on HN