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

21–30 of 168 posts

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

#21

Post by mpalmer »

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…

Why do you list all of these design patterns as though you have to hold them all in your head at the same time? As though each one made the ecosystem successively worse?

    UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)
That's not so much a lack of statefulness as it is making zero effort to lift your application's data model out of platform-specific UI concerns.

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

#22

Post by croes »

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

UI is mostly static. Rendering everything at framerate per second is a huge waste of time and energy.

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

#23

Post by tobyhinloopen »

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 use Preact without reactivity. That way we can have familiar components that look like React (including strong typing, Typescript / TSX), server-side rendering and still have explicit render calls using an MVC pattern.

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

#24

Post by mpalmer »

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

[flagged]

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

#25

Post by corstian »

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.

[dead]

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

#26

Post by yde_java »

tobyhinloopen wrote: post #23
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 use Preact without reactivity. That way we can have familiar components that look like React (including strong typing, Typescript / TSX), server-side rendering and still have explicit render calls using an MVC pattern.

How and when do your components update in such an architecture?

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

#27

Post by xgulfie »

ale wrote: post #12

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.

But build steps suck

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

#28

Post by whstl »

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

> The master Render() function draws all of the graphics according to the current state

What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".

React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.

This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.

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

#29

Post by _heimdall »

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'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 convention, usually declaratively.

If I had to do it all again though, DOM would still be the source of truth and any custom components in JS would always be working with DOM directly. Custom elements are a great fit for that approach if you stick to using them for basic lifecycle hooks, events, and attribute getters/setters.

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

#30

Post by applfanboysbgon »

mpalmer wrote: post #24
applfanboysbgon wrote: post #17

Earlier quoted context omitted.

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

[flagged]

Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo.

[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.

Post reply on HN