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

61–70 of 168 posts

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

#61

Post by ramesh31 »

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…

Give me state management vs. event bus management any day of the week. The former is fully testable and verifiable. You can even formally define your UI as a state machine. With events you are constantly chasing down race conditions and edge cases, and if your data lives seperately in components there is no clean way to share it horizontally.

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

#62

Post by tobyhinloopen »

yde_java wrote: post #26
tobyhinloopen wrote: post #23

Earlier quoted context omitted.

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?

View triggers an event -> Controller receives event, updating the model as it sees fit -> Controller calls render to update views

Model knows nothing about controller or views, so they're independently testable. Models and views are composed of a tree of entities (model) and components (views). Controller is the glue. Also, API calls are done by the controller.

So it is more of an Entity-Boundary-Control pattern.

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

#65

Post by codethief »

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…

> UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)

Is there really a difference? Angular uses RxJS in a pub-sub scheme. (At least it did when I last used it.)

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

#66

Post by codethief »

whstl wrote: post #28
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.…

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

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

"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)

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

#67

Post by scoopdewoop »

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 is immediate-mode graphics. Fine when you are already power-budgeted for 60 frames each second. UIs typically use retained-mode graphics, with persisting regions.

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

#68

Post by Izkata »

cluckindan wrote: post #49
whstl wrote: post #28

Earlier quoted context omitted.

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

>components should be simple and not store data in themselves. That is a ”controlled component” model which is bad for interactivity, especially text inputs. If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues. Without a rerender, it must now use a reactive binding to update the field value. If you don’t want to update state on every keypr…

I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.

Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.

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

#69

Post by cindyllm »

applfanboysbgon wrote: post #30
mpalmer wrote: post #24

Earlier quoted context omitted.

[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 wa…

[dead]

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

#70

Post by Jenk »

codethief wrote: post #66
whstl wrote: post #28

Earlier quoted context omitted.

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

> 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. "just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial…

Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
Post reply on HN